confusing the old MAT variable with the new GlobalType one. This caused
us to promote the @disp global pointer into:
@disp.body = internal global double*** undef
instead of:
@disp.body = internal global [3 x double**] undef
llvm-svn: 97285
for alignment into the LSDA. If the TType base offset is emitted, then put the
padding there. Otherwise, put it in the call site table length. There will be no
conflict between the two sites when placing the padding in one place.
llvm-svn: 97277
o Parallel addition and subtraction, signed/unsigned
o Miscellaneous operations: QADD, QDADD, QSUB, QDSUB
o Unsigned sum of absolute differences [and accumulate]: USAD8, USADA8
o Signed/Unsigned saturate: SSAT, SSAT16, USAT, USAT16
o Signed multiply accumulate long (halfwords): SMLAL<x><y>
o Signed multiply accumulate/subtract [long] (dual): SMLAD[x], SMLALD[X], SMLSD[X], SMLSLD[X]
o Signed dual multiply add/subtract [long]: SMUAD[X], SMUSD[X]
llvm-svn: 97276
This is possible because F8RC is a subclass of F4RC. We keep FMRSD around so
fextend has a pattern.
Also allow folding of memory operands on FMRSD.
llvm-svn: 97275
The PowerPC floating point registers can represent both f32 and f64 via the
two register classes F4RC and F8RC. F8RC is considered a subclass of F4RC to
allow cross-class coalescing. This coalescing only affects whether registers
are spilled as f32 or f64.
Spill slots must be accessed with load/store instructions corresponding to the
class of the spilled register. PPCInstrInfo::foldMemoryOperandImpl was looking
at the instruction opcode which is wrong.
X86 has similar floating point register classes, but doesn't try to fold
memory operands, so there is no problem there.
llvm-svn: 97262
object construction. There is no provision to change them when the
code for a function generated.
So we have to change these names while printing assembly.
llvm-svn: 97213
the alignment requirement, if it no longer makes the TType base offset overflow
into extra bytes, then we need to pad to those bytes ourselves.
llvm-svn: 97196
will eliminate the need for padding in the "Call site table length". E.g., if
we have this:
GCC_except_table1:
Lexception1:
.byte 0xff ## @LPStart Encoding = omit
.byte 0x9b ## @TType Encoding = indirect pcrel sdata4
.byte 0x7f ## @TType base offset
.byte 0x03 ## Call site Encoding = udata4
.byte 0x89 ## Call site table length
with padding of 1. We want to emit the padding like this:
GCC_except_table1:
Lexception1:
.byte 0xff ## @LPStart Encoding = omit
.byte 0x9b ## @TType Encoding = indirect pcrel sdata4
.byte 0xff ## @TType base offset
.space 1,0 ## Padding
.byte 0x03 ## Call site Encoding = udata4
.byte 0x89 ## Call site table length
and not with padding on the "Call site table length" entry.
llvm-svn: 97183
section with TextAlignFillValue and calls EmitCodeAlignment() instead of
calling EmitValueToAlignment(). This allows x86 assembly code to be aligned
with optimal nops.
llvm-svn: 97158
terms of store and load, which means bitcasting between scalar
integer and vector has endian-specific results, which undermines
this whole approach.
llvm-svn: 97137
keep track of instructions that return void) per-function. This fixes PR5278.
This breaks backwards compatibility with the metadata format. That's okay
because we haven't released the metadata bitcode yet.
llvm-svn: 97132
which branch on undef to branch on a boolean constant for the edge
exiting the loop. This helps ScalarEvolution compute trip counts for
loops.
Teach ScalarEvolution to recognize single-value PHIs, when safe, and
ForgetSymbolicName to forget such single-value PHI nodes as apprpriate
in ForgetSymbolicName.
llvm-svn: 97126
format is not parsable, even if the module is legal. To get parsable output,
dump the module instead of the function or smaller, since metadata kind are
attached to the module (not the context).
llvm-svn: 97124
Bill Wendling