| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
brace)
llvm-svn: 185768
|
|
|
|
|
|
|
|
|
|
|
| |
Obviously the personality function should be emitted as language handler
instead of the hard coded _GCC_specific_handler. The language specific
data must be placed after the unwind information therefore it must not
be emitted into a separate section.
Reviewed by Charles Davis and Nico Rieck.
llvm-svn: 185761
|
|
|
|
|
|
|
|
|
|
|
|
| |
ReduceLoadWidth unconditionally drops extensions from loads. Limit it to the
case when all of the bits the extension would otherwise produce are dropped by
the shrink. It would be possible to shrink the load in more cases by merging
the extensions, but this isn't trivial and a very rare case. I left a TODO for
that case.
Fixes PR16551.
llvm-svn: 185755
|
|
|
|
|
|
|
|
| |
This prevents the emission of DAG-generated vreg definitions after a
tail call be dropping them entirely (on the grounds that nothing could
use them anyway, and they interfere with O0 CodeGen).
llvm-svn: 185754
|
|
|
|
| |
llvm-svn: 185753
|
|
|
|
|
|
| |
No functional change intended.
llvm-svn: 185733
|
|
|
|
| |
llvm-svn: 185731
|
|
|
|
|
|
|
|
|
|
|
| |
The stack coloring pass has code to delete stores and loads that become
trivially dead after coloring. Extend it to cope with single instructions
that copy from one frame index to another.
The testcase happens to show an example of this kicking in at the moment.
It did occur in Real Code too though.
llvm-svn: 185705
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The stack coloring pass renumbered frame indexes with a loop of the form:
for each frame index FI
for each instruction I that uses FI
for each use of FI in I
rename FI to FI'
This caused problems if an instruction used two frame indexes F0 and F1
and if F0 was renamed to F1 and F1 to F2. The first time we visited the
instruction we changed F0 to F1, then we changed both F1s to F2.
In other words, the problem was that SSRefs recorded which instructions
used an FI, but not which MachineOperands and MachineMemOperands within
that instruction used it.
This is easily fixed for MachineOperands by walking the instructions
once and processing each operand in turn. There's already a loop to
do that for dead store elimination, so it seemed more efficient to
fuse the two at the block level.
MachineMemOperands are more tricky because they can be shared between
instructions. The patch handles them by making SSRefs an array of
MachineMemOperands rather than an array of MachineInstrs. We might end
up processing the same MachineMemOperand twice, but that's OK because
we always know from the SSRefs index what the original frame index was.
llvm-svn: 185703
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SystemZ wants normal register scavenging slots, as close to the stack or
frame pointer as possible. The only reason it was using custom code was
because PrologEpilogInserter assumed an x86-like layout, where the frame
pointer is at the opposite end of the frame from the stack pointer.
This meant that when frame pointer elimination was disabled,
the slots ended up being as close as possible to the incoming
stack pointer, which is the opposite of what we want on SystemZ.
This patch adds a new knob to say which layout is used and converts
SystemZ to use target-independent scavenging slots. It's one of the pieces
needed to support frame-to-frame MVCs, where two slots might be required.
The ABI requires us to allocate 160 bytes for calls, so one approach
would be to use that area as temporary spill space instead. It would need
some surgery to make sure that the slot isn't live across a call though.
I stuck to the "isFPCloseToIncomingSP - ..." style comment on the
"do what the surrounding code does" principle. The FP case is already
covered by several Systemz/frame-* tests, which fail without the
PrologueEpilogueInserter change, so no new ones are needed.
No behavioural change intended.
llvm-svn: 185696
|
|
|
|
| |
llvm-svn: 185689
|
|
|
|
|
|
|
|
|
| |
r179494 switched to using the object file info to retrieve the default text
section for some MC streamers. It is possible that initializing an MC
streamer can request sections before the object file info is initialized
when the AutoInitSections flag is set on the streamer.
llvm-svn: 185670
|
|
|
|
|
|
| |
These exception-related opcodes are not used any longer.
llvm-svn: 185625
|
|
|
|
| |
llvm-svn: 185618
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Stop using the ISD::EXCEPTIONADDR and ISD::EHSELECTION when lowering
landing pad arguments. These nodes were previously legalized into
CopyFromReg nodes, but that never worked properly because the
CopyFromReg node weren't guaranteed to be scheduled at the top of the
basic block.
This meant the exception pointer and selector registers could be
clobbered before being copied to a virtual register.
This patch copies the two physical registers to virtual registers at
the beginning of the basic block, and lowers the landingpad instruction
directly to two CopyFromReg nodes reading the *virtual* registers. This
is safe because virtual registers don't get clobbered.
A future patch will remove the ISD::EXCEPTIONADDR and ISD::EHSELECTION
nodes.
llvm-svn: 185617
|
|
|
|
|
|
|
|
|
|
| |
Compute the insertion point from the end of the basic block instead of
skipping labels from the front.
This caused failures in landing pads when live-in copies where inserted
before instruction selection.
llvm-svn: 185616
|
|
|
|
|
|
| |
This will soon be tested by exception handling working at all.
llvm-svn: 185615
|
|
|
|
|
|
|
| |
Revert "Simplify landing pad lowering."
Revert "Remove the EXCEPTIONADDR, EHSELECTION, and LSDAADDR ISD opcodes."
llvm-svn: 185600
|
|
|
|
|
|
| |
These exception-related opcodes are not used any longer.
llvm-svn: 185596
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Stop using the ISD::EXCEPTIONADDR and ISD::EHSELECTION when lowering
landing pad arguments. These nodes were previously legalized into
CopyFromReg nodes, but that never worked properly because the
CopyFromReg node weren't guaranteed to be scheduled at the top of the
basic block.
This meant the exception pointer and selector registers could be
clobbered before being copied to a virtual register.
This patch copies the two physical registers to virtual registers at
the beginning of the basic block, and lowers the landingpad instruction
directly to two CopyFromReg nodes reading the *virtual* registers. This
is safe because virtual registers don't get clobbered.
A future patch will remove the ISD::EXCEPTIONADDR and ISD::EHSELECTION
nodes.
llvm-svn: 185595
|
|
|
|
|
|
|
| |
This function adds a live-in physical register to an MBB and ensures
that it is copied to a virtual register immediately.
llvm-svn: 185594
|
|
|
|
| |
llvm-svn: 185589
|
|
|
|
|
|
| |
for them and update all uses.
llvm-svn: 185588
|
|
|
|
| |
llvm-svn: 185586
|
|
|
|
|
|
| |
(and for consistency).
llvm-svn: 185585
|
|
|
|
| |
llvm-svn: 185573
|
|
|
|
| |
llvm-svn: 185523
|
|
|
|
| |
llvm-svn: 185520
|
|
|
|
|
|
| |
specifying the vector size.
llvm-svn: 185514
|
|
|
|
|
|
| |
specifying vector size.
llvm-svn: 185513
|
|
|
|
|
|
| |
avoid specifying the vector size unnecessarily.
llvm-svn: 185512
|
|
|
|
|
|
| |
specifying the vector size.
llvm-svn: 185509
|
|
|
|
|
|
| |
size doesn't have to repeated when creating iterators for the DenseMap.
llvm-svn: 185508
|
|
|
|
|
|
| |
having to specify the vector size in multiple places.
llvm-svn: 185507
|
|
|
|
|
|
| |
respecifying the small vector size.
llvm-svn: 185505
|
|
|
|
|
|
| |
specifying the vector size.
llvm-svn: 185504
|
|
|
|
|
|
|
| |
avoid adding information for the debug_inlined section when it isn't
going to be emitted anyhow.
llvm-svn: 185500
|
|
|
|
| |
llvm-svn: 185498
|
|
|
|
| |
llvm-svn: 185497
|
|
|
|
|
|
| |
grep.
llvm-svn: 185496
|
|
|
|
| |
llvm-svn: 185495
|
|
|
|
| |
llvm-svn: 185492
|
|
|
|
|
|
| |
true, so remove the return value and propagate accordingly.
llvm-svn: 185490
|
|
|
|
|
|
|
|
| |
Correctly handles ref_addr depending on the Dwarf version. Emit Dwarf with
version from module flag.
TODO: turn on/off features depending on the Dwarf version.
llvm-svn: 185484
|
|
|
|
| |
llvm-svn: 185480
|
|
|
|
|
|
|
|
|
|
|
| |
This allows getDebugThreadLocalSymbol to return a generic MCExpr
instead of just a MCSymbolRefExpr.
This is in preparation for supporting debug info for TLS variables
on PowerPC, where we need to describe the variable location using
a more complex expression than just MCSymbolRefExpr.
llvm-svn: 185460
|
|
|
|
|
|
|
|
|
|
|
| |
This changes the AddrPool infrastructure to enable it to hold
generic MCExpr expressions, not just MCSymbolRefExpr.
This is in preparation for supporting debug info for TLS variables
on PowerPC, where we need to describe the variable location using
a more complex expression than just MCSymbolRefExpr.
llvm-svn: 185459
|
|
|
|
|
|
|
|
|
|
|
|
| |
This partially reverts r185202 and restores DIELabel to hold plain
MCSymbol references. Instead, we add a new subclass DIEExpr of
DIEValue that can hold generic MCExpr references.
This is in preparation for supporting debug info for TLS variables
on PowerPC, where we need to describe the variable location using
a more complex expression than just MCSymbolRefExpr.
llvm-svn: 185458
|
|
|
|
|
|
|
|
|
|
|
| |
"Remove floating point computations form SpillPlacement.cpp."
These commits caused test failures in lencod on clang-native-arm-lnt.
I suspect these changes are only exposing an existing issue, but
reverting anyway to keep the bots passing while we investigate.
llvm-svn: 185447
|
|
|
|
|
|
|
|
| |
This is dead code since PIC16 was removed in 2010. The result was an odd mix,
where some parts would carefully pass it along and others would assert it was
zero (most of the object streamer for example).
llvm-svn: 185436
|