Zhongxing and I discussed by email.
Main changes:
- Removed SymIntConstraintVal and SymIntConstraint
- Added SymExpr as a parent class to SymbolData, SymSymExpr, SymIntExpr
- Added nonloc::SymExprVal to wrap SymExpr
- SymbolRef is now just a typedef of 'const SymbolData*'
- Bunch of minor code cleanups in how some methods were invoked (no functionality change)
This changes are part of a long-term plan to have full symbolic expression
trees. This will be useful for lazily evaluating complicated expressions.
llvm-svn: 67731
%a = ...
%b = and i32 %a, 2
%c = srl i32 %b, 1
%d = br i32 %c,
into
%a = ...
%b = and %a, 2
%c = X86ISD::CMP %b, 0
%d = X86ISD::BRCOND %c ...
This applies only when the AND constant value has one bit set and the SRL
constant is equal to the log2 of the AND constant. The back-end is smart enough
to convert the result into a TEST/JMP sequence.
llvm-svn: 67728
specializations can be treated as a template. Finally, we can parse
and process the first implementation of Fibonacci I wrote!
Note that this code does not handle all of the cases where
injected-class-names can be treated as templates. In particular,
there's an ambiguity case that we should be able to handle (but
can't), e.g.,
template <class T> struct Base { };
template <class T> struct Derived : Base<int>, Base<char> {
typename Derived::Base b; // error: ambiguous
typename Derived::Base<double> d; // OK
};
llvm-svn: 67720
templates, including in-class initializers. For example:
template<typename T, T Divisor>
class X {
public:
static const T value = 10 / Divisor;
};
instantiated with, e.g.,
X<int, 5>::value
to get the value '2'.
llvm-svn: 67715
register classes. Before, MVT::Other would be returned anytime a reg was
in multiple register classes. Now, MVT::Other is only returned if the types
for those register classes differ.
llvm-svn: 67714
the declarations of member classes are instantiated when the owning
class template is instantiated. The definitions of such member classes
are instantiated when a complete type is required.
This change also introduces the injected-class-name into a class
template specialization.
llvm-svn: 67707
terminated with an EOF token. The condition it is trying to check for is
handled by this code above.
// Empty arguments are standard in C99 and supported as an extension in
// other modes.
if (ArgTokens.empty() && !Features.C99)
Diag(Tok, diag::ext_empty_fnmacro_arg);
llvm-svn: 67705
stoppoint nodes around until Legalize; doing this
imposed an ordering on a sequence of loads that
came from different lines, interfering with scheduling.
llvm-svn: 67692
- This is really gross, but its the easiest way to match gcc. Once we
are confident in the driver, we can try and push these translations
down into tools.
- No test cases for this yet, it's hard to see the effects of these
translations before the gcc tool argument translation is pulled
over.
- Interaction with "unused argument" warning hasn't been worked out
yet.
- <rdar://problem/6717359> [driver] implement toolchain specific
argument translation.
"It's horrible in here."
llvm-svn: 67683
call, we should treat "i64 zext" as the start of a constant expr, but
"i64 0 zext" as an argument with an obsolete attribute on it (this form
is already tested by test/Assembler/2007-07-30-AutoUpgradeZextSext.ll).
Make the autoupgrade logic more discerning to avoid treating "i64 zext"
as an old-style attribute, causing us to reject a valid constant expr.
This fixes PR3876.
llvm-svn: 67682
Chris Lattner