This is the beginning of purely symbolic subregister indices, but we need a bit
of jiggling before the explicit numeric indices can be completely removed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104492 91177308-0d34-0410-b5e6-96231b3b80d8
addw $0xFFFF, %ax
should match the same as
addw $-1, %ax
but we used to match it to the longer encoding.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104453 91177308-0d34-0410-b5e6-96231b3b80d8
copying VFP subregs. This exposed a bunch of dead code in the *spill-q.ll
tests, so I tweaked those tests to keep that code from being optimized away.
Radar 7872877.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104415 91177308-0d34-0410-b5e6-96231b3b80d8
that are aliases of the specified register.
- Rename modifiesRegister to definesRegister since it's looking a def of the
specific register or one of its super-registers. It's not looking for def of a
sub-register or alias that could change the specified register.
- Added modifiesRegister to look for defs of aliases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104377 91177308-0d34-0410-b5e6-96231b3b80d8
pass after isel instead of being interlaced with it, we can
trust that all the code for a function has been isel'd before
it is run.
The practical impact of this is that we can scan for machine
instr phis instead of doing a fuzzy match on the LLVM BB for
phi nodes. Doing the fuzzy match required knowing when isel
would produce an fp reg stack phi which was gross. It was
also wrong in cases where select got lowered to a branch
tree because cmovs aren't available (PR6828).
Just do the scan on machine phis which is simpler, faster
and more correct. This fixes PR6828.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104333 91177308-0d34-0410-b5e6-96231b3b80d8
isn't ideal if we want to be able to use another object file format.
Add a createObjectStreamer() factory method so that the correct object
file streamer can be instantiated for a given target triple.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104318 91177308-0d34-0410-b5e6-96231b3b80d8
registers. Currently it is not so marked, which leads to
VCMPEQ instructions that feed into it getting deleted.
If it is so marked, local RA complains about this sequence:
vreg = MCRF CR0
MFCR <kill of whatever preg got assigned to vreg>
All current uses of this instruction are only interested in
one of the 8 CR registers, so redefine MFCR to be a normal
unary instruction with a CR input (which is emitted only as
a comment). That avoids all problems. 7739628.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104238 91177308-0d34-0410-b5e6-96231b3b80d8
prefix byte problem as in r104062.
- As a total hack to keep the TAILCALL markers in the output, which some tests depend on, this invents a new TAILJMP_1 instruction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104120 91177308-0d34-0410-b5e6-96231b3b80d8
opcodes into a helper function. This fixes a few places in the code
which were not properly selecting the 8-bit-immediate opcodes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104091 91177308-0d34-0410-b5e6-96231b3b80d8
The register use operands (e.g. the first argument is passed in a
register) is currently being modeled as a normal register use,
instead of correctly being an implicit use. This causes the operand
to get propagated onto the mcinst, which was causing the encoder to
emit a rex prefix byte, which generates an invalid call.
This fixes rdar://7998435
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104062 91177308-0d34-0410-b5e6-96231b3b80d8
too large limit.
The function would return immediately when finding an addrmode 3/5 instruction.
It needs to keep scanning in case there is an addrmode 6 instruction which drops
the limit to 0.
A test case is very difficult to produce because it will only fail when the
scavenger is used.
rdar://problem/7894847
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103995 91177308-0d34-0410-b5e6-96231b3b80d8
- Change the logic DisableFramePointerElim() to check for the
-disable-non-leaf-fp-elim before -disable-fp-elim.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103990 91177308-0d34-0410-b5e6-96231b3b80d8
- Of questionable utility, since in general anything which wants to do this should probably be within a target specific hook, which can rely on the sections being of the appropriate type. However, it can be useful for short term hacks.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103980 91177308-0d34-0410-b5e6-96231b3b80d8
<1xi64> -> i64 to work in MMX registers on hosts where -no-sse
is the default (not mine). The right thing is
to accept this and make i64->f64 conversions go through memory,
but I don't have time right now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103914 91177308-0d34-0410-b5e6-96231b3b80d8
(This worked as of about 6 months ago and I didn't track down
exactly what broke it; I think this fix is appropriate.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103911 91177308-0d34-0410-b5e6-96231b3b80d8
The implementation in LegalizeIntegerTypes to handle this as
sint64->float + appropriate power of 2 is subject to double rounding,
considered incorrect by numerics people. Use this implementation only
when it is safe. This leads to using library calls in some cases
that produced inline code before, but it's correct now.
(EVTToAPFloatSemantics belongs somewhere else, any suggestions?)
Add a correctly rounding (though not particularly fast) conversion
that uses X87 80-bit computations for x86-32.
7885399, 5901940. This shows up in gcc.c-torture/execute/ieee/rbug.c
in the gcc testsuite on some platforms.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103883 91177308-0d34-0410-b5e6-96231b3b80d8
allow target to override it in order to map register classes to illegal
but synthesizable types. e.g. v4i64, v8i64 for ARM / NEON.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103854 91177308-0d34-0410-b5e6-96231b3b80d8
instructions.
e.g.
%reg1026<def> = VLDMQ %reg1025<kill>, 260, pred:14, pred:%reg0
%reg1027<def> = EXTRACT_SUBREG %reg1026, 6
%reg1028<def> = EXTRACT_SUBREG %reg1026<kill>, 5
...
%reg1029<def> = REG_SEQUENCE %reg1028<kill>, 5, %reg1027<kill>, 6, %reg1028, 7, %reg1027, 8, %reg1028, 9, %reg1027, 10, %reg1030<kill>, 11, %reg1032<kill>, 12
After REG_SEQUENCE is eliminated, we are left with:
%reg1026<def> = VLDMQ %reg1025<kill>, 260, pred:14, pred:%reg0
%reg1029:6<def> = EXTRACT_SUBREG %reg1026, 6
%reg1029:5<def> = EXTRACT_SUBREG %reg1026<kill>, 5
The regular coalescer will not be able to coalesce reg1026 and reg1029 because it doesn't
know how to combine sub-register indices 5 and 6. Now 2-address pass will consult the
target whether sub-registers 5 and 6 of reg1026 can be combined to into a larger
sub-register (or combined to be reg1026 itself as is the case here). If it is possible,
it will be able to replace references of reg1026 with reg1029 + the larger sub-register
index.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103835 91177308-0d34-0410-b5e6-96231b3b80d8
replace the check with the appropriate predicate. Modify the testcase to reflect
the correct code. (It should be saving callee-saved registers on the stack
allocated by the calling fuction.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103829 91177308-0d34-0410-b5e6-96231b3b80d8
of "has calls". That's probably wrong, but it needs further
investigation. Revert to the original behavior until this is settled.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103824 91177308-0d34-0410-b5e6-96231b3b80d8
the variable actually tracks.
N.B., several back-ends are using "HasCalls" as being synonymous for something
that adjusts the stack. This isn't 100% correct and should be looked into.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103802 91177308-0d34-0410-b5e6-96231b3b80d8
used more than once. If ISel had put a kill flag on one of them,
it's not valid to transfer the kill flag to each new instance.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103799 91177308-0d34-0410-b5e6-96231b3b80d8
