llvm-6502/lib/CodeGen
Duncan Sands 6590b0457c There is an impedance matching problem between LLVM and
gcc exception handling: if an exception unwinds through
an invoke, then execution must branch to the invoke's
unwind target.  We previously tried to enforce this by
appending a cleanup action to every selector, however
this does not always work correctly due to an optimization
in the C++ unwinding runtime: if only cleanups would be
run while unwinding an exception, then the program just
terminates without actually executing the cleanups, as
invoke semantics would require.  I was hoping this
wouldn't be a problem, but in fact it turns out to be the
cause of all the remaining failures in the LLVM testsuite
(these also fail with -enable-correct-eh-support, so turning
on -enable-eh didn't make things worse!).  Instead we need
to append a full-blown catch-all to the end of each
selector.  The correct way of doing this depends on the
personality function, i.e. it is language dependent, so
can only be done by gcc.  Thus this patch which generalizes
the eh.selector intrinsic so that it can handle all possible
kinds of action table entries (before it didn't accomodate
cleanups): now 0 indicates a cleanup, and filters have to be
specified using the number of type infos plus one rather than
the number of type infos.  Related gcc patches will cause
Ada to pass a cleanup (0) to force the selector to always
fire, while C++ will use a C++ catch-all (null).


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@41484 91177308-0d34-0410-b5e6-96231b3b80d8
2007-08-27 15:47:50 +00:00
..
SelectionDAG There is an impedance matching problem between LLVM and 2007-08-27 15:47:50 +00:00
AsmPrinter.cpp move this check. ppc outputs .no_dead_strip properly 2007-08-22 19:33:11 +00:00
BranchFolding.cpp More explicit keywords. 2007-08-02 21:21:54 +00:00
DwarfWriter.cpp Add explicit keywords and remove spurious trailing semicolons. 2007-08-27 14:50:10 +00:00
ELFWriter.cpp
ELFWriter.h
IfConversion.cpp
IntrinsicLowering.cpp Fix a regression compiling 2005-05-11-Popcount-ffs-fls with the CBE, 2007-08-06 16:36:18 +00:00
LiveInterval.cpp Kill info update bugs. 2007-08-14 01:56:58 +00:00
LiveIntervalAnalysis.cpp Fix some kill info update bugs; add hidden option -disable-rematerialization to turn off remat for debugging. 2007-08-16 07:24:22 +00:00
LiveVariables.cpp Bugs: missing partial uses and redundant partial defs. 2007-08-01 20:18:21 +00:00
LLVMTargetMachine.cpp Move subreg lowering pass to be right after regalloc, per feedback. 2007-07-27 07:36:14 +00:00
LowerSubregs.cpp Move isSubRegOf into MRegisterInfo. Fix a missed move elimination in LowerSubregs and add more debugging output there. 2007-08-10 21:11:55 +00:00
MachineBasicBlock.cpp
MachineFunction.cpp
MachineInstr.cpp
MachineModuleInfo.cpp There is an impedance matching problem between LLVM and 2007-08-27 15:47:50 +00:00
MachinePassRegistry.cpp
MachOWriter.cpp
MachOWriter.h
Makefile
Passes.cpp
PHIElimination.cpp
PhysRegTracker.h Add explicit keywords and remove spurious trailing semicolons. 2007-08-27 14:50:10 +00:00
PostRASchedulerList.cpp
PrologEpilogInserter.cpp
README.txt
RegAllocBigBlock.cpp
RegAllocLinearScan.cpp Re-implement trivial rematerialization. This allows def MIs whose live intervals that are coalesced to be rematerialized. 2007-08-13 23:45:17 +00:00
RegAllocLocal.cpp
RegAllocSimple.cpp
RegisterScavenging.cpp
SimpleRegisterCoalescing.cpp Fix some kill info update bugs; add hidden option -disable-rematerialization to turn off remat for debugging. 2007-08-16 07:24:22 +00:00
TwoAddressInstructionPass.cpp
UnreachableBlockElim.cpp
VirtRegMap.cpp If the source of a move is in spill slot, the reload may be folded to essentially a load from stack slot. It's ok to mark the stack slot value as available for reuse. But it should not be clobbered since the destination of the move is live. 2007-08-15 20:20:34 +00:00
VirtRegMap.h Re-implement trivial rematerialization. This allows def MIs whose live intervals that are coalesced to be rematerialized. 2007-08-13 23:45:17 +00:00

//===---------------------------------------------------------------------===//

Common register allocation / spilling problem:

        mul lr, r4, lr
        str lr, [sp, #+52]
        ldr lr, [r1, #+32]
        sxth r3, r3
        ldr r4, [sp, #+52]
        mla r4, r3, lr, r4

can be:

        mul lr, r4, lr
        mov r4, lr
        str lr, [sp, #+52]
        ldr lr, [r1, #+32]
        sxth r3, r3
        mla r4, r3, lr, r4

and then "merge" mul and mov:

        mul r4, r4, lr
        str lr, [sp, #+52]
        ldr lr, [r1, #+32]
        sxth r3, r3
        mla r4, r3, lr, r4

It also increase the likelyhood the store may become dead.

//===---------------------------------------------------------------------===//

I think we should have a "hasSideEffects" flag (which is automatically set for
stuff that "isLoad" "isCall" etc), and the remat pass should eventually be able
to remat any instruction that has no side effects, if it can handle it and if
profitable.

For now, I'd suggest having the remat stuff work like this:

1. I need to spill/reload this thing.
2. Check to see if it has side effects.
3. Check to see if it is simple enough: e.g. it only has one register
destination and no register input.
4. If so, clone the instruction, do the xform, etc.

Advantages of this are:

1. the .td file describes the behavior of the instructions, not the way the
   algorithm should work.
2. as remat gets smarter in the future, we shouldn't have to be changing the .td
   files.
3. it is easier to explain what the flag means in the .td file, because you
   don't have to pull in the explanation of how the current remat algo works.

Some potential added complexities:

1. Some instructions have to be glued to it's predecessor or successor. All of
   the PC relative instructions and condition code setting instruction. We could
   mark them as hasSideEffects, but that's not quite right. PC relative loads
   from constantpools can be remat'ed, for example. But it requires more than
   just cloning the instruction. Some instructions can be remat'ed but it
   expands to more than one instruction. But allocator will have to make a
   decision.

4. As stated in 3, not as simple as cloning in some cases. The target will have
   to decide how to remat it. For example, an ARM 2-piece constant generation
   instruction is remat'ed as a load from constantpool.

//===---------------------------------------------------------------------===//

bb27 ...
        ...
        %reg1037 = ADDri %reg1039, 1
        %reg1038 = ADDrs %reg1032, %reg1039, %NOREG, 10
    Successors according to CFG: 0x8b03bf0 (#5)

bb76 (0x8b03bf0, LLVM BB @0x8b032d0, ID#5):
    Predecessors according to CFG: 0x8b0c5f0 (#3) 0x8b0a7c0 (#4)
        %reg1039 = PHI %reg1070, mbb<bb76.outer,0x8b0c5f0>, %reg1037, mbb<bb27,0x8b0a7c0>

Note ADDri is not a two-address instruction. However, its result %reg1037 is an
operand of the PHI node in bb76 and its operand %reg1039 is the result of the
PHI node. We should treat it as a two-address code and make sure the ADDri is
scheduled after any node that reads %reg1039.

//===---------------------------------------------------------------------===//

Use local info (i.e. register scavenger) to assign it a free register to allow
reuse:
	ldr r3, [sp, #+4]
	add r3, r3, #3
	ldr r2, [sp, #+8]
	add r2, r2, #2
	ldr r1, [sp, #+4]  <==
	add r1, r1, #1
	ldr r0, [sp, #+4]
	add r0, r0, #2

//===---------------------------------------------------------------------===//

LLVM aggressively lift CSE out of loop. Sometimes this can be negative side-
effects:

R1 = X + 4
R2 = X + 7
R3 = X + 15

loop:
load [i + R1]
...
load [i + R2]
...
load [i + R3]

Suppose there is high register pressure, R1, R2, R3, can be spilled. We need
to implement proper re-materialization to handle this:

R1 = X + 4
R2 = X + 7
R3 = X + 15

loop:
R1 = X + 4  @ re-materialized
load [i + R1]
...
R2 = X + 7 @ re-materialized
load [i + R2]
...
R3 = X + 15 @ re-materialized
load [i + R3]

Furthermore, with re-association, we can enable sharing:

R1 = X + 4
R2 = X + 7
R3 = X + 15

loop:
T = i + X
load [T + 4]
...
load [T + 7]
...
load [T + 15]
//===---------------------------------------------------------------------===//