Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
not be used for anything other than backwards compat constraint handling.
Add support for a new DisableEncoding property which contains a list of
registers that should not be encoded by the generated code emitter. Convert
the codeemitter generator to use this, fixing some PPC JIT regressions.
llvm-svn: 31769
that there were two input operands before the variable operand portion. This
*happened* to be true for all call instructions, which took a chain and a
destination, but was not true for the PPC BCTRL instruction, whose destination
is implicit.
Making this code more general allows elimination of the custom selection logic
for BCTRL.
llvm-svn: 31732
X86ISD::CMP, etc.) instead of SDNode names (add, x86cmp, etc). We now allow
multiple SDNodes to map to the same SelectionDAG node (e.g. store, indexed
store).
llvm-svn: 31575
chain operand to point to the load being folded. Now we relax this, traversing
up the chain, if it doesn't reach the load, then it's ok. We will create a
TokenFactor (of all the chain operands and the load's chain) to capture all
the control flow dependencies.
llvm-svn: 30897
The dag/inst combiners often 'simplify' the masked value based on whether
or not the bits are live or known zero/one. This is good and dandy, but
often causes special case patterns to fail, such as alpha's CMPBGE pattern,
which looks like "(set GPRC:$RC, (setuge (and GPRC:$RA, 255), (and GPRC:$RB, 255)))".
Here the pattern for (and X, 255) should match actual dags like (and X, 254) if
the dag combiner proved that the missing bits are already zero (one for 'or').
For CodeGen/Alpha/cmpbge.ll:test2 for example, this results in:
sll $16,1,$0
cmpbge $0,$17,$0
ret $31,($26),1
instead of:
sll $16,1,$0
and $0,254,$0
and $17,255,$1
cmpule $1,$0,$0
ret $31,($26),1
... and requires no target-specific code.
llvm-svn: 30871