summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/PowerPC/MCTargetDesc
Commit message (Collapse)AuthorAgeFilesLines
...
* This patch implements medium code model support for 64-bit PowerPC.Bill Schmidt2012-11-271-1/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The default for 64-bit PowerPC is small code model, in which TOC entries must be addressable using a 16-bit offset from the TOC pointer. Additionally, only TOC entries are addressed via the TOC pointer. With medium code model, TOC entries and data sections can all be addressed via the TOC pointer using a 32-bit offset. Cooperation with the linker allows 16-bit offsets to be used when these are sufficient, reducing the number of extra instructions that need to be executed. Medium code model also does not generate explicit TOC entries in ".section toc" for variables that are wholly internal to the compilation unit. Consider a load of an external 4-byte integer. With small code model, the compiler generates: ld 3, .LC1@toc(2) lwz 4, 0(3) .section .toc,"aw",@progbits .LC1: .tc ei[TC],ei With medium model, it instead generates: addis 3, 2, .LC1@toc@ha ld 3, .LC1@toc@l(3) lwz 4, 0(3) .section .toc,"aw",@progbits .LC1: .tc ei[TC],ei Here .LC1@toc@ha is a relocation requesting the upper 16 bits of the 32-bit offset of ei's TOC entry from the TOC base pointer. Similarly, .LC1@toc@l is a relocation requesting the lower 16 bits. Note that if the linker determines that ei's TOC entry is within a 16-bit offset of the TOC base pointer, it will replace the "addis" with a "nop", and replace the "ld" with the identical "ld" instruction from the small code model example. Consider next a load of a function-scope static integer. For small code model, the compiler generates: ld 3, .LC1@toc(2) lwz 4, 0(3) .section .toc,"aw",@progbits .LC1: .tc test_fn_static.si[TC],test_fn_static.si .type test_fn_static.si,@object .local test_fn_static.si .comm test_fn_static.si,4,4 For medium code model, the compiler generates: addis 3, 2, test_fn_static.si@toc@ha addi 3, 3, test_fn_static.si@toc@l lwz 4, 0(3) .type test_fn_static.si,@object .local test_fn_static.si .comm test_fn_static.si,4,4 Again, the linker may replace the "addis" with a "nop", calculating only a 16-bit offset when this is sufficient. Note that it would be more efficient for the compiler to generate: addis 3, 2, test_fn_static.si@toc@ha lwz 4, test_fn_static.si@toc@l(3) The current patch does not perform this optimization yet. This will be addressed as a peephole optimization in a later patch. For the moment, the default code model for 64-bit PowerPC will remain the small code model. We plan to eventually change the default to medium code model, which matches current upstream GCC behavior. Note that the different code models are ABI-compatible, so code compiled with different models will be linked and execute correctly. I've tested the regression suite and the application/benchmark test suite in two ways: Once with the patch as submitted here, and once with additional logic to force medium code model as the default. The tests all compile cleanly, with one exception. The mandel-2 application test fails due to an unrelated ABI compatibility with passing complex numbers. It just so happens that small code model was incredibly lucky, in that temporary values in floating-point registers held the expected values needed by the external library routine that was called incorrectly. My current thought is to correct the ABI problems with _Complex before making medium code model the default, to avoid introducing this "regression." Here are a few comments on how the patch works, since the selection code can be difficult to follow: The existing logic for small code model defines three pseudo-instructions: LDtoc for most uses, LDtocJTI for jump table addresses, and LDtocCPT for constant pool addresses. These are expanded by SelectCodeCommon(). The pseudo-instruction approach doesn't work for medium code model, because we need to generate two instructions when we match the same pattern. Instead, new logic in PPCDAGToDAGISel::Select() intercepts the TOC_ENTRY node for medium code model, and generates an ADDIStocHA followed by either a LDtocL or an ADDItocL. These new node types correspond naturally to the sequences described above. The addis/ld sequence is generated for the following cases: * Jump table addresses * Function addresses * External global variables * Tentative definitions of global variables (common linkage) The addis/addi sequence is generated for the following cases: * Constant pool entries * File-scope static global variables * Function-scope static variables Expanding to the two-instruction sequences at select time exposes the instructions to subsequent optimization, particularly scheduling. The rest of the processing occurs at assembly time, in PPCAsmPrinter::EmitInstruction. Each of the instructions is converted to a "real" PowerPC instruction. When a TOC entry needs to be created, this is done here in the same manner as for the existing LDtoc, LDtocJTI, and LDtocCPT pseudo-instructions (I factored out a new routine to handle this). I had originally thought that if a TOC entry was needed for LDtocL or ADDItocL, it would already have been generated for the previous ADDIStocHA. However, at higher optimization levels, the ADDIStocHA may appear in a different block, which may be assembled textually following the block containing the LDtocL or ADDItocL. So it is necessary to include the possibility of creating a new TOC entry for those two instructions. Note that for LDtocL, we generate a new form of LD called LDrs. This allows specifying the @toc@l relocation for the offset field of the LD instruction (i.e., the offset is replaced by a SymbolLo relocation). When the peephole optimization described above is added, we will need to do similar things for all immediate-form load and store operations. The seven "mcm-n.ll" test cases are kept separate because otherwise the intermingling of various TOC entries and so forth makes the tests fragile and hard to understand. The above assumes use of an external assembler. For use of the integrated assembler, new relocations are added and used by PPCELFObjectWriter. Testing is done with "mcm-obj.ll", which tests for proper generation of the various relocations for the same sequences tested with the external assembler. llvm-svn: 168708
* PPC: Reinstate the fatal error when trying to emit a macho file.Benjamin Kramer2012-11-241-1/+3
| | | | llvm-svn: 168543
* PPC: Share applyFixup between ELF and Darwin.Benjamin Kramer2012-11-241-18/+14
| | | | llvm-svn: 168540
* Add (some) PowerPC TLS relocation types to ELF.h andUlrich Weigand2012-11-131-2/+18
| | | | | | | generate them from PPCELFObjectWriter::getRelocTypeInner as appropriate. llvm-svn: 167864
* This patch fixes the MC object emission of 'nop' for external function callsAdhemerval Zanella2012-10-252-3/+13
| | | | | | | | | | | | | | | | | | | | | | | and also fixes the R_PPC64_TOC16 and R_PPC64_TOC16_DS relocation offset. The 'nop' is needed so a restore TOC instruction (ld r2,40(r1)) can be placed by the linker to correct restore the TOC of previous function. Current code has two issues: it defines in PPCInstr64Bit.td file a LDinto_toc and LDtoc_restore as a DSForm_1 with DS_RA=0 where it should be DS=2 (the 8 bytes displacement of the TOC saving). It also wrongly emits a MC intruction using an uint32_t value while the PPC::BL8_NOP_ELF and PPC::BLA8_NOP_ELF are both uint64_t (because of the following 'nop'). This patch corrects the remaining ExecutionEngine using MCJIT: ExecutionEngine/2002-12-16-ArgTest.ll ExecutionEngine/2003-05-07-ArgumentTest.ll ExecutionEngine/2005-12-02-TailCallBug.ll ExecutionEngine/hello.ll ExecutionEngine/hello2.ll ExecutionEngine/test-call.ll llvm-svn: 166682
* Initial TOC support for PowerPC64 object creationAdhemerval Zanella2012-10-254-13/+112
| | | | | | | | | | | | | | This patch adds initial PPC64 TOC MC object creation using the small mcmodel (a single 64K TOC) adding the some TOC relocations (R_PPC64_TOC, R_PPC64_TOC16, and R_PPC64_TOC16DS). The addition of 'undefinedExplicitRelSym' hook on 'MCELFObjectTargetWriter' is meant to avoid the creation of an unreferenced ".TOC." symbol (used in the .odp creation) as well to set the R_PPC64_TOC relocation target as the temporary ".TOC." symbol. On PPC64 ABI, the R_PPC64_TOC relocation should not point to any symbol. llvm-svn: 166677
* PowerPC: Fix object creation with PPC::MTCRF8 instructionAdhemerval Zanella2012-10-081-1/+3
| | | | llvm-svn: 165411
* When creating MCAsmBackend pass the CPU string as well. In X86AsmBackendRoman Divacky2012-09-182-2/+2
| | | | | | | | | store this and use it to not emit long nops when the CPU is geode which doesnt support them. Fixes PR11212. llvm-svn: 164132
* Use LLVM_DELETED_FUNCTION in place of 'DO NOT IMPLEMENT' comments.Craig Topper2012-09-151-3/+3
| | | | llvm-svn: 163974
* Enable exceptions handling on PPC64 now that cr misaligned spillingRoman Divacky2012-09-121-2/+1
| | | | | | was fixed in r163713. llvm-svn: 163715
* MC: Overhaul handling of .lcommBenjamin Kramer2012-09-071-1/+0
| | | | | | | | | | | | | - Darwin lied about not supporting .lcomm and turned it into zerofill in the asm parser. Push the zerofill-conversion down into macho-specific code. - This makes the tri-state LCOMMType enum superfluous, there are no targets without .lcomm. - Do proper error reporting when trying to use .lcomm with alignment on a target that doesn't support it. - .comm and .lcomm alignment was parsed in bytes on COFF, should be power of 2. - Fixes PR13755 (.lcomm crashes on ELF). llvm-svn: 163395
* Revert r162034, r162035 and r162037.Roman Divacky2012-08-162-20/+1
| | | | llvm-svn: 162039
* Define and handle additional fixup kinds. By Adhemerval Zanella.Roman Divacky2012-08-162-1/+20
| | | | llvm-svn: 162037
* Allow MCCodeEmitter access to the target MCRegisterInfo.Jim Grosbach2012-05-152-0/+3
| | | | | | | | Add the MCRegisterInfo to the factories and constructors. Patch by Tom Stellard <Tom.Stellard@amd.com>. llvm-svn: 156828
* Make MCInstrInfo available to the MCInstPrinter. This will be used to remove ↵Craig Topper2012-04-021-1/+2
| | | | | | getInstructionName and the static data it contains since the same tables are already in MCInstrInfo. llvm-svn: 153860
* Prune some includes and forward declarations.Craig Topper2012-03-261-0/+1
| | | | llvm-svn: 153429
* Reorder includes in Target backends to following coding standards. Remove ↵Craig Topper2012-03-171-1/+1
| | | | | | some superfluous forward declarations. llvm-svn: 152997
* Make MCRegisterInfo available to the the MCInstPrinter.Jim Grosbach2012-03-051-1/+2
| | | | | | | Used to allow context sensitive printing of super-register or sub-register references. llvm-svn: 152043
* Emacs-tag and some comment fix for all ARM, CellSPU, Hexagon, MBlaze, ↵Jia Liu2012-02-184-4/+4
| | | | | | MSP430, PPC, PTX, Sparc, X86, XCore. llvm-svn: 150878
* Convert assert(0) to llvm_unreachableCraig Topper2012-02-071-4/+3
| | | | llvm-svn: 149961
* Convert assert(0) to llvm_unreachableCraig Topper2012-02-051-0/+1
| | | | llvm-svn: 149814
* Widen the instruction encoder that TblGen emits to a 64 bits, which should ↵Owen Anderson2012-01-241-1/+1
| | | | | | accomodate every target I can think of offhand. llvm-svn: 148833
* Tidy up. 80 columns.Jim Grosbach2012-01-181-13/+13
| | | | llvm-svn: 148401
* Tidy up. MCAsmBackend naming conventions.Jim Grosbach2012-01-181-7/+7
| | | | llvm-svn: 148400
* Fix an incomplete refactoring of the ppc backend. Thanks to rdivacky for ↵Rafael Espindola2011-12-222-15/+3
| | | | | | | | reporting it. It does need some some tests... llvm-svn: 147154
* Fix cmake.Rafael Espindola2011-12-221-0/+1
| | | | llvm-svn: 147126
* Move PPC bits to lib/Target/PowerPC.Rafael Espindola2011-12-222-1/+112
| | | | llvm-svn: 147124
* Reduce the exposure of Triple::OSType in the ELF object writer. This willRafael Espindola2011-12-211-7/+8
| | | | | | | avoid including ADT/Triple.h in many places when the target specific bits are moved. llvm-svn: 147059
* Unweaken vtables as per ↵David Blaikie2011-12-202-2/+10
| | | | | | http://llvm.org/docs/CodingStandards.html#ll_virtual_anch llvm-svn: 146960
* LLVMBuild: Remove trailing newline, which irked me.Daniel Dunbar2011-12-121-1/+0
| | | | llvm-svn: 146409
* MipsAsmBackend.cpp, PPCAsmBackend.cpp: Fix -Asserts build to appease msvc.NAKAMURA Takumi2011-12-061-0/+1
| | | | llvm-svn: 145894
* Move target-specific logic out of generic MCAssembler.Jim Grosbach2011-12-061-0/+9
| | | | | | | | Whether a fixup needs relaxation for the associated instruction is a target-specific function, as the FIXME indicated. Create a hook for that and use it. llvm-svn: 145881
* build/CMake: Finish removal of add_llvm_library_dependencies.Daniel Dunbar2011-11-291-7/+0
| | | | llvm-svn: 145420
* Sink codegen optimization level into MCCodeGenInfo along side relocation modelEvan Cheng2011-11-161-2/+3
| | | | | | | and code model. This eliminates the need to pass OptLevel flag all over the place and makes it possible for any codegen pass to use this information. llvm-svn: 144788
* build: Add initial cut at LLVMBuild.txt files.Daniel Dunbar2011-11-031-0/+24
| | | | llvm-svn: 143634
* Refactor instprinter and mcdisassembler to take a SubtargetInfo. Add -mattr= ↵James Molloy2011-09-071-1/+2
| | | | | | handling to llvm-mc. Reviewed by Owen Anderson. llvm-svn: 139237
* Don't drop alignment info on local common symbols.Benjamin Kramer2011-09-011-1/+1
| | | | | | | | | | | - On COFF the .lcomm directive has an alignment argument. - On ELF we fall back to .local + .comm Based on a patch by NAKAMURA Takumi. Fixes PR9337, PR9483 and PR10128. llvm-svn: 138976
* Move TargetRegistry and TargetSelect from Target to Support where they belong.Evan Cheng2011-08-242-2/+2
| | | | | | These are strictly utilities for registering targets and components. llvm-svn: 138450
* Some refactoring so TargetRegistry.h no longer has to include any filesEvan Cheng2011-08-231-0/+1
| | | | | | from MC. llvm-svn: 138367
* Remove trailing semicolon.Roman Divacky2011-08-021-1/+1
| | | | llvm-svn: 136690
* Sketch out PowerPC ELF writer. This is enough to get clang -integrated-asRoman Divacky2011-08-022-2/+71
| | | | | | to compile a working hello world on FreeBSD/PPC32. llvm-svn: 136689
* Set endianess and pointer size for PPC Linux. Bug noticed by Roman Divacky.Evan Cheng2011-08-011-0/+4
| | | | llvm-svn: 136639
* Rewrite the CMake build to use explicit dependencies between libraries,Chandler Carruth2011-07-291-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | specified in the same file that the library itself is created. This is more idiomatic for CMake builds, and also allows us to correctly specify dependencies that are missed due to bugs in the GenLibDeps perl script, or change from compiler to compiler. On Linux, this returns CMake to a place where it can relably rebuild several targets of LLVM. I have tried not to change the dependencies from the ones in the current auto-generated file. The only places I've really diverged are in places where I was seeing link failures, and added a dependency. The goal of this patch is not to start changing the dependencies, merely to move them into the correct location, and an explicit form that we can control and change when necessary. This also removes a serialization point in the build because we don't have to scan all the libraries before we begin building various tools. We no longer have a step of the build that regenerates a file inside the source tree. A few other associated cleanups fall out of this. This isn't really finished yet though. After talking to dgregor he urged switching to a single CMake macro to construct libraries with both sources and dependencies in the arguments. Migrating from the two macros to that style will be a follow-up patch. Also, llvm-config is still generated with GenLibDeps.pl, which means it still has slightly buggy dependencies. The internal CMake 'llvm-config-like' macro uses the correct explicitly specified dependencies however. A future patch will switch llvm-config generation (when using CMake) to be based on these deps as well. This may well break Windows. I'm getting a machine set up now to dig into any failures there. If anyone can chime in with problems they see or ideas of how to solve them for Windows, much appreciated. llvm-svn: 136433
* Explicitly declare a library dependency of LLVM*Desc toOscar Fuentes2011-07-281-0/+2
| | | | | | | | | | | | | | | | | | | LLVM*AsmPrinter. GenLibDeps.pl fails to detect vtable references. As this is the only referenced symbol from LLVM*Desc to LLVM*AsmPrinter on optimized builds, the algorithm that creates the list of libraries to be linked into tools doesn't know about the dependency and sometimes places the libraries on the wrong order, yielding error messages like this: ../../lib/libLLVMARMDesc.a(ARMMCTargetDesc.cpp.o): In function `llvm::ARMInstPrinter::ARMInstPrinter(llvm::MCAsmInfo const&)': ARMMCTargetDesc.cpp:(.text._ZN4llvm14ARMInstPrinterC1ERKNS_9MCAsmInfoE [llvm::ARMInstPrinter::ARMInstPrinter(llvm::MCAsmInfo const&)]+0x2a): undefined reference to `vtable for llvm::ARMInstPrinter' llvm-svn: 136328
* Rename createCodeEmitter to createMCCodeEmitter; createObjectStreamer to ↵Evan Cheng2011-07-261-5/+5
| | | | | | createMCObjectStreamer. llvm-svn: 136031
* Rename TargetAsmParser to MCTargetAsmParser and TargetAsmLexer to ↵Evan Cheng2011-07-263-0/+69
| | | | | | MCTargetAsmLexer; rename createAsmLexer to createMCAsmLexer and createAsmParser to createMCAsmParser. llvm-svn: 136027
* Clean up a pile of hacks in our CMake build relating to TableGen.Chandler Carruth2011-07-261-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 136023
* Rename TargetAsmBackend to MCAsmBackend; rename createAsmBackend to ↵Evan Cheng2011-07-253-14/+11
| | | | | | createMCAsmBackend. llvm-svn: 136010
* Separate MCInstPrinter registration from AsmPrinter registration.Evan Cheng2011-07-251-0/+11
| | | | llvm-svn: 135974
* Code clean up.Evan Cheng2011-07-251-1/+1
| | | | llvm-svn: 135954
OpenPOWER on IntegriCloud