In this case it is essential that the kill is real because the spiller will
decide to omit a spill if it thinks there is a later kill.
llvm-svn: 106751
when the condition is constant. This optimization shouldn't be
necessary, because codegen shouldn't be able to find dead control
paths that the IR-level optimizer can't find. And it's undesirable,
because it encourages bugpoint to leave "br i1 false" branches
in its output. And it wasn't updating the CFG.
I updated all the tests I could, but some tests are too reduced
and I wasn't able to meaningfully preserve them.
llvm-svn: 106748
CoalescerPair can determine if a copy can be coalesced, and which register gets
merged away. The old logic in SimpleRegisterCoalescing had evolved into
something a bit too convoluted.
llvm-svn: 106701
void t(int *cp0, int *cp1, int *dp, int fmd) {
int c0, c1, d0, d1, d2, d3;
c0 = (*cp0++ & 0xffff) | ((*cp1++ << 16) & 0xffff0000);
c1 = (*cp0++ & 0xffff) | ((*cp1++ << 16) & 0xffff0000);
/* ... */
}
It code gens into something pretty bad. But with this change (analogous to the
X86 back-end), it will use ldm and generate few instructions.
llvm-svn: 106693
having a library both as bitcode and native code. We want to use the
bitcode first, but if codegen produces new undefined references we have to use
the native code to satisfy those references.
Gold has no notion of bitcode and native search directories, so instead it has
an API where the plugin can instruct it to look for the libraries it is passing
to it. This patch uses that API.
llvm-svn: 106674
Given the pattern below as an example:
list<dag> Pattern = [(set RC:$dst, (v4f32 (shufp:src3 RC:$src1,
(mem_frag addr:$src2))))];
The right reference resolving should lead to:
list<dag> Pattern = [(set VR128:$dst, (v4f32 (shufp:src3 VR128:$src1,
(mem_frag addr:$src2))))];
But was yielding:
list<dag> Pattern = [(set VR128:$dst, (v4f32 (shufp VR128:$src1,
(mem_frag addr:$src2))))];
Fix this by passing the right name when creating a new DagInit node.
llvm-svn: 106670
branch turns out to be ARM-to-Thumb or vice versa
the linker cannot resolve this. 8120438.
If this optimization is going to be useful we probably
need a compiler flag "assume callees are same architecture"
or something like that.
llvm-svn: 106662
