2008-09-26 04:40:32 +00:00
|
|
|
set(LLVM_TARGET_DEFINITIONS PPC.td)
|
|
|
|
|
|
2011-11-04 19:04:23 +00:00
|
|
|
tablegen(LLVM PPCGenAsmWriter.inc -gen-asm-writer)
|
2013-05-03 19:49:39 +00:00
|
|
|
tablegen(LLVM PPCGenAsmMatcher.inc -gen-asm-matcher)
|
2013-12-19 16:13:01 +00:00
|
|
|
tablegen(LLVM PPCGenDisassemblerTables.inc -gen-disassembler)
|
2014-09-02 22:28:02 +00:00
|
|
|
tablegen(LLVM PPCGenMCCodeEmitter.inc -gen-emitter)
|
2011-11-04 19:04:23 +00:00
|
|
|
tablegen(LLVM PPCGenRegisterInfo.inc -gen-register-info)
|
|
|
|
|
tablegen(LLVM PPCGenInstrInfo.inc -gen-instr-info)
|
|
|
|
|
tablegen(LLVM PPCGenDAGISel.inc -gen-dag-isel)
|
2013-07-30 00:50:39 +00:00
|
|
|
tablegen(LLVM PPCGenFastISel.inc -gen-fast-isel)
|
2011-11-04 19:04:23 +00:00
|
|
|
tablegen(LLVM PPCGenCallingConv.inc -gen-callingconv)
|
|
|
|
|
tablegen(LLVM PPCGenSubtargetInfo.inc -gen-subtarget)
|
Clean up a pile of hacks in our CMake build relating to TableGen.
The first problem to fix is to stop creating synthetic *Table_gen
targets next to all of the LLVM libraries. These had no real effect as
CMake specifies that add_custom_command(OUTPUT ...) directives (what the
'tablegen(...)' stuff expands to) are implicitly added as dependencies
to all the rules in that CMakeLists.txt.
These synthetic rules started to cause problems as we started more and
more heavily using tablegen files from *subdirectories* of the one where
they were generated. Within those directories, the set of tablegen
outputs was still available and so these synthetic rules added them as
dependencies of those subdirectories. However, they were no longer
properly associated with the custom command to generate them. Most of
the time this "just worked" because something would get to the parent
directory first, and run tablegen there. Once run, the files existed and
the build proceeded happily. However, as more and more subdirectories
have started using this, the probability of this failing to happen has
increased. Recently with the MC refactorings, it became quite common for
me when touching a large enough number of targets.
To add insult to injury, several of the backends *tried* to fix this by
adding explicit dependencies back to the parent directory's tablegen
rules, but those dependencies didn't work as expected -- they weren't
forming a linear chain, they were adding another thread in the race.
This patch removes these synthetic rules completely, and adds a much
simpler function to declare explicitly that a collection of tablegen'ed
files are referenced by other libraries. From that, we can add explicit
dependencies from the smaller libraries (such as every architectures
Desc library) on this and correctly form a linear sequence. All of the
backends are updated to use it, sometimes replacing the existing attempt
at adding a dependency, sometimes adding a previously missing dependency
edge.
Please let me know if this causes any problems, but it fixes a rather
persistent and problematic source of build flakiness on our end.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136023 91177308-0d34-0410-b5e6-96231b3b80d8
2011-07-26 00:09:08 +00:00
|
|
|
add_public_tablegen_target(PowerPCCommonTableGen)
|
2008-09-26 04:40:32 +00:00
|
|
|
|
|
|
|
|
add_llvm_target(PowerPCCodeGen
|
2010-11-14 18:33:33 +00:00
|
|
|
PPCAsmPrinter.cpp
|
2008-09-26 04:40:32 +00:00
|
|
|
PPCBranchSelector.cpp
|
2012-06-08 15:38:21 +00:00
|
|
|
PPCCTRLoops.cpp
|
2008-09-26 04:40:32 +00:00
|
|
|
PPCHazardRecognizers.cpp
|
|
|
|
|
PPCInstrInfo.cpp
|
|
|
|
|
PPCISelDAGToDAG.cpp
|
|
|
|
|
PPCISelLowering.cpp
|
2015-02-01 22:58:46 +00:00
|
|
|
PPCEarlyReturn.cpp
|
2013-07-30 00:50:39 +00:00
|
|
|
PPCFastISel.cpp
|
2011-01-10 12:39:23 +00:00
|
|
|
PPCFrameLowering.cpp
|
2010-11-14 19:53:02 +00:00
|
|
|
PPCMCInstLower.cpp
|
2011-12-20 08:42:11 +00:00
|
|
|
PPCMachineFunctionInfo.cpp
|
2008-09-26 04:40:32 +00:00
|
|
|
PPCRegisterInfo.cpp
|
|
|
|
|
PPCSubtarget.cpp
|
|
|
|
|
PPCTargetMachine.cpp
|
2013-05-13 19:34:37 +00:00
|
|
|
PPCTargetObjectFile.cpp
|
2013-01-25 23:05:59 +00:00
|
|
|
PPCTargetTransformInfo.cpp
|
2010-04-16 23:04:22 +00:00
|
|
|
PPCSelectionDAGInfo.cpp
|
[PowerPC] Yet another approach to __tls_get_addr
This patch is a third attempt to properly handle the local-dynamic and
global-dynamic TLS models.
In my original implementation, calls to __tls_get_addr were hidden
from view until the asm-printer phase, at which point the underlying
branch-and-link instruction was created with proper relocations. This
mostly worked well, but I used some repellent techniques to ensure
that the TLS_GET_ADDR nodes at the SD and MI levels correctly received
input from GPR3 and produced output into GPR3. This proved to work
badly in the presence of multiple TLS variable accesses, with the
copies to and from GPR3 being scheduled incorrectly and generally
creating havoc.
In r221703, I addressed that problem by representing the calls to
__tls_get_addr as true calls during instruction lowering. This had
the advantage of removing all of the bad hacks and relying on the
existing call machinery to properly glue the copies in place. It
looked like this was going to be the right way to go.
However, as a side effect of the recent discovery of problems with
linker optimizations for TLS, we discovered cases of suboptimal code
generation with this strategy. The problem comes when tls_get_addr is
called for the same address, and there is a resulting CSE
opportunity. It turns out that in such cases MachineCSE will common
the addis/addi instructions that set up the input value to
tls_get_addr, but will not common the calls themselves. MachineCSE
does not have any machinery to common idempotent calls. This is
perfectly sensible, since presumably this would be done at the IR
level, and introducing calls in the back end isn't commonplace. In
any case, we end up with two calls to __tls_get_addr when one would
suffice, and that isn't good.
I presumed that the original design would have allowed commoning of
the machine-specific nodes that hid the __tls_get_addr calls, so as
suggested by Ulrich Weigand, I went back to that design and cleaned it
up so that the copies were properly held together by glue
nodes. However, it turned out that this didn't work either...the
presence of copies to physical registers kept the machine-specific
nodes from being commoned also.
All of which leads to the design presented here. This is a return to
the original design, except that no attempt is made to introduce
copies to and from GPR3 during instruction lowering. Virtual registers
are used until prior to register allocation. At that point, a special
pass is run that identifies the machine-specific nodes that hide the
tls_get_addr calls and introduces the copies to and from GPR3 around
them. The register allocator then coalesces these copies away. With
this design, MachineCSE succeeds in commoning tls_get_addr calls where
possible, and we get nice optimal code generation (better than GCC at
the moment, which does not common these calls).
One additional problem must be dealt with: After introducing the
mentions of the physical register GPR3, the aggressive anti-dependence
breaker sees opportunities to improve scheduling by selecting a
different register instead. Flags must be used on the instruction
descriptions to tell the anti-dependence breaker to keep its hands in
its pockets.
One thing missing from the original design was recording a definition
of the link register on the GET_TLS_ADDR nodes. Doing this was found
to be insufficient to force a stack frame to be created, which led to
looping behavior because two different LR values were stored at the
same address. This appears to have been an oversight in
PPCFrameLowering::determineFrameLayout(), which is repaired here.
Because MustSaveLR() returns true for calls to builtin_return_address,
this changed the expected behavior of
test/CodeGen/PowerPC/retaddr2.ll, which now stacks a frame but
formerly did not. I've fixed the test case to reflect this.
There are existing TLS tests to catch regressions; the checks in
test/CodeGen/PowerPC/tls-store2.ll proved to be too restrictive in the
face of instruction scheduling with these changes, so I fixed that
up.
I've added a new test case based on the PrettyStackTrace module that
demonstrated the original problem. This checks that we get correct
code generation and that CSE of the calls to __get_tls_addr has taken
place.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227976 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-03 16:16:01 +00:00
|
|
|
PPCTLSDynamicCall.cpp
|
2015-02-01 22:01:29 +00:00
|
|
|
PPCVSXCopy.cpp
|
2015-02-01 21:51:22 +00:00
|
|
|
PPCVSXFMAMutate.cpp
|
2008-09-26 04:40:32 +00:00
|
|
|
)
|
2011-02-20 02:55:27 +00:00
|
|
|
|
2013-05-03 19:49:39 +00:00
|
|
|
add_subdirectory(AsmParser)
|
2013-12-19 16:13:01 +00:00
|
|
|
add_subdirectory(Disassembler)
|
2011-02-20 02:55:27 +00:00
|
|
|
add_subdirectory(InstPrinter)
|
|
|
|
|
add_subdirectory(TargetInfo)
|
2011-07-14 20:59:42 +00:00
|
|
|
add_subdirectory(MCTargetDesc)
|
