doesn't split legal vector operands. This is necessary because the
type legalization (and therefore, vector splitting) code will be going
away soon.
llvm-svn: 72349
The DAGCombiner created a negative shiftamount, stored in an
unsigned variable. Later the optimizer eliminated the shift entirely as being
undefined.
Example: (srl (shl X, 56) 48). ShiftAmt is 4294967288.
Fix it by checking that the shiftamount is positive, and storing in a signed
variable.
llvm-svn: 72331
and it wasn't generating calls through @PLT for these functions.
hasLocalLinkage() is now false for available_externally,
I attempted to fix the inliner and dce to handle available_externally properly.
It passed make check.
llvm-svn: 72328
will allow simplifying LegalizeDAG to eliminate type legalization. (I
have a patch to do that, but it's not quite finished; I'll commit it
once it's finished and I've fixed any review comments for this patch.)
See the comment at the beginning of
lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp for more details on the
motivation for this patch.
llvm-svn: 72325
systems instead of attempting to promote them to a 64-bit SINT_TO_FP or
FP_TO_SINT. This is in preparation for removing the type legalization
code from LegalizeDAG: once type legalization is gone from LegalizeDAG,
it won't be able to handle the i64 operand/result correctly.
This isn't quite ideal, but I don't think any other operation for any
target ends up in this situation, so treating this case specially seems
reasonable.
llvm-svn: 72324
expressions. We are now missing template instantiation logic for only
three classes of expressions:
- Blocks-related expressions (BlockExpr, BlockDeclRefExpr)
- C++ default argument expressions
- Objective-C expressions
Additionally, our handling of DeclRefExpr is still quite poor, since
it cannot handle references to many kinds of declarations.
As part of this change, converted the TemplateExprInstantiator to use
iteration through all of the expressions via clang/AST/StmtNodes.def,
ensuring that we don't forget to add template instantiation logic for
any new expression node kinds.
llvm-svn: 72303
is true. Because of recent changes to llvm::SmallVector, using these iterators
when Exprs was empty would cause an assertion failure.
This fixes: PR 4245.
llvm-svn: 72286
expressions. This change introduces another AST node,
CXXUnresolvedMemberExpr, that captures member references (x->m, x.m)
when the base of the expression (the "x") is type-dependent, and we
therefore cannot resolve the member reference yet.
Note that our parsing of member references for C++ is still quite
poor, e.g., we don't handle x->Base::m or x->operator int.
llvm-svn: 72281
(T(*)(int[x+y]));
is an (invalid) paren expression, but "x+y" will be parsed as part of the (rejected) type-id,
so unnecessary Action calls are made for an unused (and possibly leaked) "x+y".
Use a different scheme, similar to parsing inline methods. The parenthesized tokens are cached,
the context that follows is determined (possibly by parsing a cast-expression),
and then we re-introduce the cached tokens into the token stream and parse them appropriately.
llvm-svn: 72279
Daniel Dunbar