v8i8 -> v8i32 on AVX machines. The codegen often scalarizes ANY_EXTEND nodes.
The DAGCombiner has two optimizations that can mitigate the problem. First,
if all of the operands of a BUILD_VECTOR node are extracted from an ZEXT/ANYEXT
nodes, then it is possible to create a new simplified BUILD_VECTOR which uses
UNDEFS/ZERO values to eliminate the scalar ZEXT/ANYEXT nodes.
Second, another dag combine optimization lowers BUILD_VECTOR into a shuffle
vector instruction.
In the case of zext v8i8->v8i32 on AVX, a value in an XMM register is to be
shuffled into a wide YMM register.
This patch modifes the second optimization and allows the creation of
shuffle vectors even when the newly generated vector and the original vector
from which we extract the values are of different types.
llvm-svn: 150340
Before this change we built the CFG such that it was only valid after code was
fully generated. During code generation itself, it was often incomplete. After
this change always maintain a valid CFG. This will later allow us to use the
SCEVExpander during code generation. This is the first step to get rid of the
independent blocks pass.
llvm-svn: 150339
to what's done for MachO and COFF. This allows advanced uses of the class to
be implemented outside the Object library. In particular, the DyldELFObject
subclass is now moved into its logical home - ExecutionEngine/RuntimeDyld.
This patch was reviewed by Michael Spencer.
llvm-svn: 150327
r149987 changed the way parsing happens inside an @implementation;
it aggregates the declarations inside and reports them together as a DeclGroup.
This had the side effect that function declarations were reported together with
their definition, while the rewriter expected for function declarations to be
reported immediately to the consumer and thus not have a body.
Fix this by having the rewriter actually check with isThisDeclarationADefinition()
to make sure the body comes from the current decl before rewriting it.
llvm-svn: 150325
instead of having a special-purpose function.
- ActOnCXXDirectInitializer, which was mostly duplication of
AddInitializerToDecl (leading e.g. to PR10620, which Eli fixed a few days
ago), is dropped completely.
- MultiInitializer, which was an ugly hack I added, is dropped again.
- We now have the infrastructure in place to distinguish between
int x = {1};
int x({1});
int x{1};
-- VarDecl now has getInitStyle(), which indicates which of the above was used.
-- CXXConstructExpr now has a flag to indicate that it represents list-
initialization, although this is not yet used.
- InstantiateInitializer was renamed to SubstInitializer and simplified.
- ActOnParenOrParenListExpr has been replaced by ActOnParenListExpr, which
always produces a ParenListExpr. Placed that so far failed to convert that
back to a ParenExpr containing comma operators have been fixed. I'm pretty
sure I could have made a crashing test case before this.
The end result is a (I hope) considerably cleaner design of initializers.
More importantly, the fact that I can now distinguish between the various
initialization kinds means that I can get the tricky generalized initializer
test cases Johannes Schaub supplied to work. (This is not yet done.)
This commit passed self-host, with the resulting compiler passing the tests. I
hope it doesn't break more complicated code. It's a pretty big change, but one
that I feel is necessary.
llvm-svn: 150318
memory.
(As per one test case, the existing checker thought that this could
cause a lot of false positives - not sure if that's valid, to be
verified.)
llvm-svn: 150313
cv-unqualified type. This is essential in order to allow move-only objects of
const-qualified types to be copy-initialized via a converting constructor.
llvm-svn: 150309
This requires some gymnastics to make it available for C code. Remove the names
from the disassembler tables, making them relocation free.
llvm-svn: 150303
Module flags are key-value pairs associated with the module. They include a
'behavior' value, indicating how module flags react when mergine two
files. Normally, it's just the union of the two module flags. But if two module
flags have the same key, then the resulting flags are dictated by the behaviors.
Allowable behaviors are:
Error
Emits an error if two values disagree.
Warning
Emits a warning if two values disagree.
Require
Emits an error when the specified value is not present
or doesn't have the specified value. It is an error for
two (or more) llvm.module.flags with the same ID to have
the Require behavior but different values. There may be
multiple Require flags per ID.
Override
Uses the specified value if the two values disagree. It
is an error for two (or more) llvm.module.flags with the
same ID to have the Override behavior but different
values.
llvm-svn: 150300
In case the MachineScheduling pass I'm working on doesn't work well
for another target, they can completely override it. This also adds a
hook immediately after the RegAlloc pass to cleanup immediately after
vregs go away. We may want to fold it into the postRA hook later.
llvm-svn: 150298
Sebastian Redl