http://llvm.org https://git.amat.us/llvm/atom/lib/Target/PowerPC/MCTargetDesc?h=stable 2013-03-26T20:08:20Z 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 2013-02-25T16:44:35Z Bill Schmidt wschmidt@linux.vnet.ibm.com 2013-02-25T16:44:35Z urn:sha1:fc7695a653323071ec141aee994e4188592ad1f5 Report and fix due to Kai Nacke. Testcase update by me. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@176029 91177308-0d34-0410-b5e6-96231b3b80d8 2013-02-21T00:05:29Z Bill Schmidt wschmidt@linux.vnet.ibm.com 2013-02-21T00:05:29Z urn:sha1:06ab2c828a5605abec36eb0d6749940fa6eb7391 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175693 91177308-0d34-0410-b5e6-96231b3b80d8 2013-01-23T17:12:15Z Eli Bendersky eliben@google.com 2013-01-23T17:12:15Z urn:sha1:e807d1ea1e05fea895ba90dd4da8c91026ba1f29 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173275 91177308-0d34-0410-b5e6-96231b3b80d8