Basically, using:
lea symbol(%rip), %rax
is not valid in -static mode, because the current RIP may not be
within 32-bits of "symbol" when an app is built partially pic and
partially static. The fix for this is to compile it to:
lea symbol, %rax
It would be better to codegen this as:
movq $symbol, %rax
but that will come next.
The hard part of fixing this bug was fixing abi-isel, which was actively
testing for the wrong behavior. Also, the RUN lines are completely impossible
to understand what they are testing. To help with this, convert the -static
x86-64 codegen tests to use filecheck. This is much more stable and makes it
more clear what the codegen is expected to be.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@75382 91177308-0d34-0410-b5e6-96231b3b80d8
Make llvm_unreachable take an optional string, thus moving the cerr<< out of
line.
LLVM_UNREACHABLE is now a simple wrapper that makes the message go away for
NDEBUG builds.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@75379 91177308-0d34-0410-b5e6-96231b3b80d8
is just a trivial wrapper around "ClassifyGlobalReference", which
stole a ton of logic from LowerGlobalAddress.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@75237 91177308-0d34-0410-b5e6-96231b3b80d8
MachineOperand is a reference to a stub, not a reference to the
global variable itself. Look no context needed!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@75233 91177308-0d34-0410-b5e6-96231b3b80d8
is modified. Otherwise, the unwinder will get confused. The old code (before I
started my hacking) did this. It dropped on the floor, because I wasn't aware of
this requirement.
On the plus side, if we use "alloca" in a function, we create frame pointers
even with -fomit-frame-pointer is enabled!
This is a Good Thing(tm)!!!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@75183 91177308-0d34-0410-b5e6-96231b3b80d8
registers based on dynamic conditions. For example, X86 EBP/RBP, when used as
frame register has to be spilled in the first fixed object. It should inform
PEI this so it doesn't get allocated another stack object. Also, it should not
be spilled as other callee-saved registers but rather its spilling and restoring
are being handled by emitPrologue and emitEpilogue. Avoid spilling it twice.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@75116 91177308-0d34-0410-b5e6-96231b3b80d8
make sure we're set to static codegen. Simplify the decision
tree of target->picstyle/picmode settings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@75094 91177308-0d34-0410-b5e6-96231b3b80d8
* remove some old code that was needed when we'd put ESP in the scale instead of
the base of some instructions.
* Fix a bug with the P modifier in inline asm that caused us to drop it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@75077 91177308-0d34-0410-b5e6-96231b3b80d8
DWARF requires frame moves be specified at specific times. If you have a
prologue like this:
__Z3fooi:
Leh_func_begin1:
LBB1_0: ## entry
pushl %ebp
Llabel1:
movl %esp, %ebp
Llabel2:
pushl %esi
Llabel3:
subl $20, %esp
call "L1$pb"
"L1$pb":
popl %esi
The "pushl %ebp" needs a table entry specifying the offset. The "movl %esp,
%ebp" makes %ebp the new stack frame register, so that needs to be specified in
DWARF. And "pushl %esi" saves the callee-saved %esi register, which also needs
to be specified in DWARF.
Before, all of this logic was in one method. This didn't work too well, because
as you can see there are multiple FDE line entries that need to be created.
This fix creates the "MachineMove" objects directly when they're needed; instead
of waiting until the end, and losing information.
There is some ugliness where we generate code like this:
LBB22_0: ## entry
pushl %ebp
Llabel280:
movl %esp, %ebp
Llabel281:
Llabel284:
pushl %ebp <----------
pushl %ebx
pushl %edi
pushl %esi
Llabel282:
subl $328, %esp
Notice the extra "pushl %ebp". If we generate a "machine move" instruction in
the FDE for that pushl, the linker may get very confused about what value %ebp
should have when exitting the function. I.e., it'll give it the value %esp
instead of the %ebp value from the first "pushl". Not to mention that, in this
case, %ebp isn't modified in the function (that's a separate bug). I put a small
hack in to get it to work. It might be the only solution, but should be
revisited once the above case is fixed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@75047 91177308-0d34-0410-b5e6-96231b3b80d8
U lib/Target/X86/X86RegisterInfo.cpp
U lib/Target/X86/X86RegisterInfo.h
Temporarily revert. This was causing an infinite loop in the linker on Leopard.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74970 91177308-0d34-0410-b5e6-96231b3b80d8
prologue like this:
__Z3fooi:
Leh_func_begin1:
LBB1_0: ## entry
pushl %ebp
Llabel1:
movl %esp, %ebp
Llabel2:
pushl %esi
Llabel3:
subl $20, %esp
call "L1$pb"
"L1$pb":
popl %esi
The "pushl %ebp" needs a table entry specifying the offset. The "movl %esp,
%ebp" makes %ebp the new stack frame register, so that needs to be specified in
DWARF. And "pushl %esi" saves the callee-saved %esi register, which also needs
to be specified in DWARF.
Before, all of this logic was in one method. This didn't work too well, because
as you can see there are multiple FDE line entries that need to be created.
This fix creates the "MachineMove" objects directly when they're needed; instead
of waiting until the end, and losing information.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74952 91177308-0d34-0410-b5e6-96231b3b80d8
With the SVR4 ABI on PowerPC, vector arguments for vararg calls are passed differently depending on whether they are a fixed or a variable argument. Variable vector arguments always go into memory, fixed vector arguments are put
into vector registers. If there are no free vector registers available, fixed vector arguments are put on the stack.
The NumFixedArgs attribute allows to decide for an argument in a vararg call whether it belongs to the fixed or variable portion of the parameter list.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74764 91177308-0d34-0410-b5e6-96231b3b80d8
- This more or less amounts to a revert of r65379. I'm curious to know what
happened that caused this variable to become unused.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74579 91177308-0d34-0410-b5e6-96231b3b80d8
have the alignment be calculated up front, and have the back-ends obey whatever
alignment is decided upon.
This allows for future work that would allow for precise no-op placement and the
like.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74564 91177308-0d34-0410-b5e6-96231b3b80d8
Avoid unnecessary duplication of operand 0 of X86::FpSET_ST0_80. This duplication would
cause one register to remain on the stack at the function return.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74534 91177308-0d34-0410-b5e6-96231b3b80d8
The register allocator, when it allocates a register to a virtual register defined by an implicit_def, can allocate any physical register without worrying about overlapping live ranges. It should mark all of operands of the said virtual register so later passes will do the right thing.
This is not the best solution. But it should be a lot less fragile to having the scavenger try to track what is defined by implicit_def.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74518 91177308-0d34-0410-b5e6-96231b3b80d8
Not sure I understand how the temp register gets used,
but this fixes a bug and introduces no regressions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74446 91177308-0d34-0410-b5e6-96231b3b80d8
fence-atomic-fence down to just the atomic op. This is possible thanks to
X86's relatively strong memory model, which guarantees that locked instructions
(which are used to implement atomics) are implicit fences.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74435 91177308-0d34-0410-b5e6-96231b3b80d8