LLVM with the emscripten fastcomp javascript backend https://git.amat.us/emscripten-fastcomp/atom/lib/Target/PowerPC/MCTargetDesc?h=master 2013-05-14T18:35:11Z 2013-05-14T18:35:11Z Bill Wendling isanbard@gmail.com 2013-05-14T18:35:11Z urn:sha1:b1ecefd0b589689cf90b5346678989b997be1de7 ------------------------------------------------------------------------ r181450 | uweigand | 2013-05-08 10:50:07 -0700 (Wed, 08 May 2013) | 16 lines [PowerPC] Fix regression in generating @ha/@l relocs The patch I committed as revision 167864 introduced a regression that causes LLVM to no longer generate appropriate relocs for @ha/@l symbol references (but fail an assertion instead). This is fixed here by re-enabling support for the VK_PPC_GAS_HA16/ VK_PPC_GAS_LO16 variant kinds (and their Darwin variants) in PPCELFObjectWriter.cpp. Tested by running projects/test-suite in -m32 mode with the integrated assembler forced on. A standalone test case will be committed shortly as well. ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_33@181816 91177308-0d34-0410-b5e6-96231b3b80d8 2013-04-26T15:38:30Z Ulrich Weigand ulrich.weigand@de.ibm.com 2013-04-26T15:38:30Z urn:sha1:8ade90930863acf94fbb2ccd91acefcf114c1f3e When testing the asm parser, I ran into an error when using a conditional branch to an external symbol (this doesn't occur in compiler-generated code) due to missing support in PPCELFObjectWriter::getRelocTypeInner. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180605 91177308-0d34-0410-b5e6-96231b3b80d8 2013-04-20T05:16:26Z Hal Finkel hfinkel@anl.gov 2013-04-20T05:16:26Z urn:sha1:abe64dc6f7363c7e6170568e382fb06d81d62f51 The getSwappedPredicate function can be used in other places (such as in improvements to the PPCCTRLoops pass). Instead of trapping it as a static function in PPCInstrInfo, move it into PPCPredicates with other predicate-related things. No functionality change intended. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179926 91177308-0d34-0410-b5e6-96231b3b80d8 2013-03-26T20:08:20Z Hal Finkel hfinkel@anl.gov 2013-03-26T20:08:20Z urn:sha1:aa6047d23d8ed55abd8545f5cbe82cd13cbd756a As pointed out by Jakob, we don't need to maintain a separate register-numbering table. Instead we should let TableGen generate the table for us from the information (already present) in PPCRegisterInfo.td. TRI->getEncodingValue is now used to access register-encoding values. No functionality change intended. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178067 91177308-0d34-0410-b5e6-96231b3b80d8 2013-03-26T14:17:42Z Benjamin Kramer benny.kra@googlemail.com 2013-03-26T14:17:42Z urn:sha1:d6f5a581ab968a2618b0c5a8472ea2ab37797916 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178025 91177308-0d34-0410-b5e6-96231b3b80d8 2013-03-26T10:56:47Z Ulrich Weigand ulrich.weigand@de.ibm.com 2013-03-26T10:56:47Z urn:sha1:65e90c036472380bba160c349412f37128608e1c MCTargetDesc/PPCMCCodeEmitter.cpp current has code like: if (isSVR4ABI() && is64BitMode()) Fixups.push_back(MCFixup::Create(0, MO.getExpr(), (MCFixupKind)PPC::fixup_ppc_toc16)); else Fixups.push_back(MCFixup::Create(0, MO.getExpr(), (MCFixupKind)PPC::fixup_ppc_lo16)); This is a problem for the asm parser, since it requires knowledge of the ABI / 64-bit mode to be set up. However, more fundamentally, at this point we shouldn't make such distinctions anyway; in an assembler file, it always ought to be possible to e.g. generate TOC relocations even when the main ABI is one that doesn't use TOC. Fortunately, this is actually completely unnecessary; that code was added to decide whether to generate TOC relocations, but that information is in fact already encoded in the VariantKind of the underlying symbol. This commit therefore merges those fixup types into one, and then decides which relocation to use based on the VariantKind. No changes in generated code. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178007 91177308-0d34-0410-b5e6-96231b3b80d8 2013-03-26T10:53:27Z Ulrich Weigand ulrich.weigand@de.ibm.com 2013-03-26T10:53:27Z urn:sha1:3b2552933642c19ce5e8836d82c26c562910e239 The BLR pattern cannot be recognized by the asm parser in its current form. This complexity is due to an apparent attempt to enable conditional BLR variants. However, none of those can ever be generated by current code; the pattern is only ever created using the default "pred" operand. To simplify the pattern and allow it to be recognized by the parser, this commit removes those attempts at conditional BLR support. When we later come back to actually add real conditional BLR, this should probably be done via a fully generic conditional branch pattern. No change in generated code. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178002 91177308-0d34-0410-b5e6-96231b3b80d8 2013-03-23T22:06:07Z Hal Finkel hfinkel@anl.gov 2013-03-23T22:06:07Z urn:sha1:526d6c451bf7cbffdb6976f551c42607680c1e3a In order for the new ZERO register to be used with MC, etc. we need to specify its register number (0). Thanks to Kai for reporting the problem! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177833 91177308-0d34-0410-b5e6-96231b3b80d8 2013-03-22T15:24:13Z Ulrich Weigand ulrich.weigand@de.ibm.com 2013-03-22T15:24:13Z urn:sha1:86765fbe170198e7bb40fd8499d1354f4c786f60 We currently have a duplicated set of call instruction patterns depending on the ABI to be followed (Darwin vs. Linux). This is a bit odd; while the different ABIs will result in different instruction sequences, the actual instructions themselves ought to be independent of the ABI. And in fact it turns out that the only nontrivial difference between the two sets of patterns is that in the PPC64 Linux ABI, the instruction used for indirect calls is marked to take X11 as extra input register (which is indeed used only with that ABI to hold an incoming environment pointer for nested functions). However, this does not need to be hard-coded at the .td pattern level; instead, the C++ code expanding calls can simply add that use, just like it adds uses for argument registers anyway. No change in generated code expected. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177735 91177308-0d34-0410-b5e6-96231b3b80d8 2013-03-17T12:40:42Z Sylvestre Ledru sylvestre@debian.org 2013-03-17T12:40:42Z urn:sha1:53856be683113838cc112331adca3717d4a520cc git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177234 91177308-0d34-0410-b5e6-96231b3b80d8