summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/SystemZ/MCTargetDesc
Commit message (Collapse)AuthorAgeFilesLines
* [SystemZ] Add all remaining instructionsUlrich Weigand2017-06-302-0/+8
| | | | | | | | | | | This adds all remaining instructions that were still missing, mostly privileged and semi-privileged system-level instructions. These are provided for use with the assembler and disassembler only. This brings the LLVM assembler / disassembler to parity with the GNU binutils tools. llvm-svn: 306876
* Remove redundant argument.Rafael Espindola2017-06-241-2/+2
| | | | llvm-svn: 306189
* ARM: move some logic from processFixupValue to applyFixup.Rafael Espindola2017-06-231-2/+5
| | | | | | | | | | | | processFixupValue is called on every relaxation iteration. applyFixup is only called once at the very end. applyFixup is then the correct place to do last minute changes and value checks. While here, do proper range checks again for fixup_arm_thumb_bl. We used to do it, but dropped because of thumb2. We now do it again, but use the thumb2 range. llvm-svn: 306177
* Use a MutableArrayRef. NFC.Rafael Espindola2017-06-211-4/+4
| | | | llvm-svn: 305968
* Move Object format code to lib/BinaryFormat.Zachary Turner2017-06-071-1/+1
| | | | | | | | | | | | This creates a new library called BinaryFormat that has all of the headers from llvm/Support containing structure and layout definitions for various types of binary formats like dwarf, coff, elf, etc as well as the code for identifying a file from its magic. Differential Revision: https://reviews.llvm.org/D33843 llvm-svn: 304864
* Sort the remaining #include lines in include/... and lib/....Chandler Carruth2017-06-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
* [SystemZ] Add decimal integer instructionsUlrich Weigand2017-05-101-0/+14
| | | | | | | This adds the set of decimal integer (BCD) instructions for assembler / disassembler use. llvm-svn: 302646
* Distinguish between code pointer size and DataLayout::getPointerSize() in ↵Konstantin Zhuravlyov2017-04-171-1/+1
| | | | | | DWARF info generation llvm-svn: 300463
* Add MCContext argument to MCAsmBackend::applyFixup for error reportingAlex Bradbury2017-04-051-2/+2
| | | | | | | | | | | | | | | | A number of backends (AArch64, MIPS, ARM) have been using MCContext::reportError to report issues such as out-of-range fixup values in their TgtAsmBackend. This is great, but because MCContext couldn't easily be threaded through to the adjustFixupValue helper function from its usual callsite (applyFixup), these backends ended up adding an MCContext* argument and adding another call to applyFixup to processFixupValue. Adding an MCContext parameter to applyFixup makes this unnecessary, and even better - applyFixup can take a reference to MCContext rather than a potentially null pointer. Differential Revision: https://reviews.llvm.org/D30264 llvm-svn: 299529
* [SystemZ] Fix some Clang-tidy modernize and Include What You Use warnings; ↵Eugene Zelenko2017-01-242-14/+26
| | | | | | other minor fixes (NFC). llvm-svn: 292983
* [SystemZ] Fix fallout from r288374Ulrich Weigand2016-12-011-1/+2
| | | | | | Avoid undefined behavior due to too-large shift count. llvm-svn: 288391
* [SystemZ] Fix applyFixup for 12-bit fixupsUlrich Weigand2016-12-011-1/+3
| | | | | | | | | Now that we have fixups that only fill parts of a byte, it turns out we have to mask off the bits outside the fixup area when applying them. Failing to do so caused invalid object code to be emitted for bprp with a negative 12-bit displacement. llvm-svn: 288374
* [SystemZ] Support execution hint instructionsUlrich Weigand2016-11-284-1/+29
| | | | | | | | | This adds assembler support for the instructions provided by the execution-hint facility (NIAI and BP(R)P). This required adding support for the new relocation types for 12-bit and 24-bit PC- relative offsets used by the BP(R)P instructions. llvm-svn: 288031
* Check that emitted instructions meet their predicates on all targets except ↵Daniel Sanders2016-11-191-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | ARM, Mips, and X86. Summary: * ARM is omitted from this patch because this check appears to expose bugs in this target. * Mips is omitted from this patch because this check either detects bugs or deliberate emission of instructions that don't satisfy their predicates. One deliberate use is the SYNC instruction where the version with an operand is correctly defined as requiring MIPS32 while the version without an operand is defined as an alias of 'SYNC 0' and requires MIPS2. * X86 is omitted from this patch because it doesn't use the tablegen-erated MCCodeEmitter infrastructure. Patches for ARM and Mips will follow. Depends on D25617 Reviewers: tstellarAMD, jmolloy Subscribers: wdng, jmolloy, aemerson, rengolin, arsenm, jyknight, nemanjai, nhaehnle, tstellarAMD, llvm-commits Differential Revision: https://reviews.llvm.org/D25618 llvm-svn: 287439
* [SystemZ] Model access registers as LLVM registersUlrich Weigand2016-11-082-0/+9
| | | | | | | | | | | | | Add the 16 access registers as LLVM registers. This allows removing a lot of special cases in the assembler and disassembler where we were handling access registers; this can all just use the generic register code now. Also add a bunch of instructions to operate on access registers, for assembler/disassembler use only. No change in code generation intended. llvm-svn: 286283
* [SystemZ] Fix encoding of MVCK and .insn ssUlrich Weigand2016-10-311-0/+14
| | | | | | | | | | | | | | | | | | | | LLVM currently treats the first operand of MVCK as if it were a regular base+index+displacement address. However, it is in fact a base+displacement combined with a length register field. While the two might look syntactically similar, there are two semantic differences: - %r0 is a valid length register, even though it cannot be used as an index register. - In an expression with just a single register like 0(%rX), the register is treated as base with normal addresses, while it is treated as the length register (with an empty base) for MVCK. Fixed by adding a new operand parser class BDRAddr and reworking the assembler parser to distinguish between address + length register operands and regular addresses. llvm-svn: 285574
* Move the global variables representing each Target behind accessor functionMehdi Amini2016-10-092-9/+9
| | | | | | | | This avoids "static initialization order fiasco" Differential Revision: https://reviews.llvm.org/D25412 llvm-svn: 283702
* MC] Provide an MCTargetOptions to implementors of MCAsmBackendCtorTy, NFCJoel Jones2016-07-252-2/+5
| | | | | | | | | | | | | | | Some targets, notably AArch64 for ILP32, have different relocation encodings based upon the ABI. This is an enabling change, so a future patch can use the ABIName from MCTargetOptions to chose which relocations to use. Tested using check-llvm. The corresponding change to clang is in: http://reviews.llvm.org/D16538 Patch by: Joel Jones Differential Revision: https://reviews.llvm.org/D16213 llvm-svn: 276654
* Fix branch relaxation in 16-bit mode.Nirav Dave2016-07-111-1/+2
| | | | | | | | | | | | | | | Thread through MCSubtargetInfo to relaxInstruction function allowing relaxation to generate jumps with 16-bit sized immediates in 16-bit mode. This fixes PR22097. Reviewers: dwmw2, tstellarAMD, craig.topper, jyknight Subscribers: jfb, arsenm, jyknight, llvm-commits, dsanders Differential Revision: http://reviews.llvm.org/D20830 llvm-svn: 275068
* Delete MCCodeGenInfo.Rafael Espindola2016-06-301-11/+5
| | | | | | | MC doesn't really care about CodeGen stuff, so this was just complicating target initialization. llvm-svn: 274258
* Delete Reloc::Default.Rafael Espindola2016-05-181-6/+0
| | | | | | | | | | | | Having an enum member named Default is quite confusing: Is it distinct from the others? This patch removes that member and instead uses Optional<Reloc> in places where we have a user input that still hasn't been maped to the default value, which is now clear has no be one of the remaining 3 options. llvm-svn: 269988
* Remove autoconf supportChris Bieneman2016-01-261-16/+0
| | | | | | | | | | | | | | | | Summary: This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html "I felt a great disturbance in the [build system], as if millions of [makefiles] suddenly cried out in terror and were suddenly silenced. I fear something [amazing] has happened." - Obi Wan Kenobi Reviewers: chandlerc, grosbach, bob.wilson, tstellarAMD, echristo, whitequark Subscribers: chfast, simoncook, emaste, jholewinski, tberghammer, jfb, danalbert, srhines, arsenm, dschuff, jyknight, dsanders, joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D16471 llvm-svn: 258861
* Convert a few assert failures into proper errors.Rafael Espindola2016-01-131-3/+4
| | | | | | Fixes PR25944. llvm-svn: 257697
* Avoid explicit relocation sorting most of the time.Rafael Espindola2015-12-171-16/+0
| | | | | | | | | | These days relocations are created and stored in a deterministic way. The order they are created is also suitable for the .o file, so we don't need an explicit sort. The last remaining exception is MIPS. llvm-svn: 255902
* Always sort by offset first. NFC.Rafael Espindola2015-12-171-3/+0
| | | | | | | Every target changing sortRelocs was first calling the parent implementation. Just run that first. llvm-svn: 255898
* [SystemZ] Sort relocs to avoid code corruption by linker optimizationUlrich Weigand2015-12-161-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The SystemZ linkers provide an optimization to transform a general- or local-dynamic TLS sequence into an initial-exec sequence if possible. Do do that, the compiler generates a function call to __tls_get_offset, which is a brasl instruction annotated with *two* relocations: - a R_390_PLT32DBL to install __tls_get_offset as branch target - a R_390_TLS_GDCALL / R_390_TLS_LDCALL to inform the linker that the TLS optimization should be performed if possible If the optimization is performed, the brasl is replaced by an ld load instruction. However, *both* relocs are processed independently by the linker. Therefore it is crucial that the R_390_PLT32DBL is processed *first* (installing the branch target for the brasl) and the R_390_TLS_GDCALL is processed *second* (replacing the whole brasl with an ld). If the relocs are swapped, the linker will first replace the brasl with an ld, and *then* install the __tls_get_offset branch target offset. Since ld has a different layout than brasl, this may even result in a completely different (or invalid) instruction; in any case, the resulting code is corrupted. Unfortunately, the way the MC common code sorts relocations causes these two to *always* end up the wrong way around, resulting in wrong code generation by the linker and crashes. This patch overrides the sortRelocs routine to detect this particular pair of relocs and enforce the required order. llvm-svn: 255787
* Untabify.NAKAMURA Takumi2015-09-221-1/+1
| | | | llvm-svn: 248264
* Revert r247692: Replace Triple with a new TargetTuple in MCTargetDesc/* and ↵Daniel Sanders2015-09-155-14/+12
| | | | | | | | related. NFC. Eric has replied and has demanded the patch be reverted. llvm-svn: 247702
* Re-commit r247683: Replace Triple with a new TargetTuple in MCTargetDesc/* ↵Daniel Sanders2015-09-155-12/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | and related. NFC. Summary: This is the first patch in the series to migrate Triple's (which are ambiguous) to TargetTuple's (which aren't). For the moment, TargetTuple simply passes all requests to the Triple object it holds. Once it has replaced Triple, it will start to implement the interface in a more suitable way. This change makes some changes to the public C++ API. In particular, InitMCSubtargetInfo(), createMCRelocationInfo(), and createMCSymbolizer() now take TargetTuples instead of Triples. The other public C++ API's have been left as-is for the moment to reduce patch size. This commit also contains a trivial patch to clang to account for the C++ API change. Thanks go to Pavel Labath for fixing LLDB for me. Reviewers: rengolin Subscribers: jyknight, dschuff, arsenm, rampitec, danalbert, srhines, javed.absar, dsanders, echristo, emaste, jholewinski, tberghammer, ted, jfb, llvm-commits, rengolin Differential Revision: http://reviews.llvm.org/D10969 llvm-svn: 247692
* Revert r247684 - Replace Triple with a new TargetTuple ...Daniel Sanders2015-09-155-14/+12
| | | | | | LLDB needs to be updated in the same commit. llvm-svn: 247686
* Replace Triple with a new TargetTuple in MCTargetDesc/* and related. NFC.Daniel Sanders2015-09-155-12/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is the first patch in the series to migrate Triple's (which are ambiguous) to TargetTuple's (which aren't). For the moment, TargetTuple simply passes all requests to the Triple object it holds. Once it has replaced Triple, it will start to implement the interface in a more suitable way. This change makes some changes to the public C++ API. In particular, InitMCSubtargetInfo(), createMCRelocationInfo(), and createMCSymbolizer() now take TargetTuples instead of Triples. The other public C++ API's have been left as-is for the moment to reduce patch size. This commit also contains a trivial patch to clang to account for the C++ API change. Reviewers: rengolin Subscribers: jyknight, dschuff, arsenm, rampitec, danalbert, srhines, javed.absar, dsanders, echristo, emaste, jholewinski, tberghammer, ted, jfb, llvm-commits, rengolin Differential Revision: http://reviews.llvm.org/D10969 llvm-svn: 247683
* MC: Remove MCSubtargetInfo() default constructorDuncan P. N. Exon Smith2015-07-101-3/+1
| | | | | | | | | | | | | | | | | | | | | Force all creators of `MCSubtargetInfo` to immediately initialize it, merging the default constructor and the initializer into an initializing constructor. Besides cleaning up the code a little, this makes it clear that the initializer is never called again later. Out-of-tree backends need a trivial change: instead of calling: auto *X = new MCSubtargetInfo(); InitXYZMCSubtargetInfo(X, ...); return X; they should call: return createXYZMCSubtargetInfoImpl(...); There's no real functionality change here. llvm-svn: 241957
* Change the last few internal StringRef triples into Triple objects.Daniel Sanders2015-07-061-2/+3
| | | | | | | | | | | | | | | | | | | | Summary: This concludes the patch series to eliminate StringRef forms of GNU triples from the internals of LLVM that began in r239036. At this point, the StringRef-form of GNU Triples should only be used in the public API (including IR serialization) and a couple objects that directly interact with the API (most notably the Module class). The next step is to replace these Triple objects with the TargetTuple object that will represent our authoratative/unambiguous internal equivalent to GNU Triples. Reviewers: rengolin Subscribers: llvm-commits, jholewinski, ted, rengolin Differential Revision: http://reviews.llvm.org/D10962 llvm-svn: 241472
* Replace string GNU Triples with llvm::Triple in MCSubtargetInfo and ↵Daniel Sanders2015-06-101-3/+2
| | | | | | | | | | | | | | | | | | create*MCSubtargetInfo(). NFC. Summary: This continues the patch series to eliminate StringRef forms of GNU triples from the internals of LLVM that began in r239036. Reviewers: rafael Reviewed By: rafael Subscribers: rafael, ted, jfb, llvm-commits, rengolin, jholewinski Differential Revision: http://reviews.llvm.org/D10311 llvm-svn: 239467
* Replace string GNU Triples with llvm::Triple in MCAsmBackend subclasses and ↵Daniel Sanders2015-06-102-3/+4
| | | | | | | | | | | | | | | | | | create*AsmBackend(). NFC. Summary: This continues the patch series to eliminate StringRef forms of GNU triples from the internals of LLVM that began in r239036. Reviewers: echristo, rafael Reviewed By: rafael Subscribers: rafael, llvm-commits, rengolin Differential Revision: http://reviews.llvm.org/D10243 llvm-svn: 239464
* MC: Clean up naming in MCObjectWriter. NFC.Jim Grosbach2015-06-041-1/+1
| | | | | | | | | | | | | | | | | | | | s/WriteObject/writeObject/ s/RecordRelocation/recordRelocation/ s/IsSymbolRefDifferenceFullyResolved/isSymbolRefDifferenceFullyResolved/ s/Write8/write8/ s/WriteLE16/writeLE16/ s/WriteLE32/writeLE32/ s/WriteLE64/writeLE64/ s/WriteBE16/writeBE16/ s/WriteBE32/writeBE32/ s/WriteBE64/writeBE64/ s/Write16/write16/ s/Write32/write32/ s/Write64/write64/ s/WriteZeroes/writeZeroes/ s/WriteBytes/writeBytes/ llvm-svn: 239108
* Replace string GNU Triples with llvm::Triple in MCAsmInfo subclasses and ↵Daniel Sanders2015-06-043-4/+4
| | | | | | | | | | | | | | | | | | | | create*AsmInfo(). NFC. Summary: This is the first of several patches to eliminate StringRef forms of GNU triples from the internals of LLVM. After this is complete, GNU triples will be replaced by a more authoratitive representation in the form of an LLVM TargetTuple. Reviewers: rengolin Reviewed By: rengolin Subscribers: ted, llvm-commits, rengolin, jholewinski Differential Revision: http://reviews.llvm.org/D10236 llvm-svn: 239036
* MC: Clean up MCExpr naming. NFC.Jim Grosbach2015-05-301-3/+3
| | | | llvm-svn: 238634
* Remove 3 includes from MCInstrDesc.h and explicitly include them where neededPete Cooper2015-05-152-0/+3
| | | | llvm-svn: 237481
* MC: MCCodeGenInfo naming update. NFC.Jim Grosbach2015-05-151-1/+1
| | | | | | s/InitMCCodeGenInfo/initMCCodeGenInfo/ llvm-svn: 237471
* MC: Update MCCodeEmitter naming. NFC.Jim Grosbach2015-05-151-2/+2
| | | | | | s/EncodeInstruction/encodeInstruction/ llvm-svn: 237469
* MC: Update MCFixup naming. NFC.Jim Grosbach2015-05-151-2/+2
| | | | | | s/MCFixup::Create/MCFixup::create/ llvm-svn: 237468
* [SystemZ] Add CodeGen support for v4f32Ulrich Weigand2015-05-051-0/+5
| | | | | | | | | | | | | | | | The architecture doesn't really have any native v4f32 operations except v4f32->v2f64 and v2f64->v4f32 conversions, with only half of the v4f32 elements being used. Even so, using vector registers for <4 x float> and scalarising individual operations is much better than generating completely scalar code, since there's much less register pressure. It's also more efficient to do v4f32 comparisons by extending to 2 v2f64s, comparing those, then packing the result. This particularly helps with llvmpipe. Based on a patch by Richard Sandiford. llvm-svn: 236523
* [SystemZ] Add z13 vector facility and MC supportUlrich Weigand2015-05-053-2/+55
| | | | | | | | | | | | | | | | | | | | | This patch adds support for the z13 processor type and its vector facility, and adds MC support for all new instructions provided by that facilily. Apart from defining the new instructions, the main changes are: - Adding VR128, VR64 and VR32 register classes. - Making FP64 a subclass of VR64 and FP32 a subclass of VR32. - Adding a D(V,B) addressing mode for scatter/gather operations - Adding 1-, 2-, and 3-bit immediate operands for some 4-bit fields. Until now all immediate operands have been the same width as the underlying field (hence the assert->return change in decode[SU]ImmOperand). In addition, sys::getHostCPUName is extended to detect running natively on a z13 machine. Based on a patch by Richard Sandiford. llvm-svn: 236520
* Use raw_pwrite_stream in the object writer/streamer.Rafael Espindola2015-04-143-3/+4
| | | | | | The ELF object writer will take advantage of that in the next commit. llvm-svn: 234950
* Use 'override/final' instead of 'virtual' for overridden methodsAlexander Kornienko2015-04-112-2/+2
| | | | | | | | | | | | | | The patch is generated using clang-tidy misc-use-override check. This command was used: tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py \ -checks='-*,misc-use-override' -header-filter='llvm|clang' \ -j=32 -fix -format http://reviews.llvm.org/D8925 llvm-svn: 234679
* Replace the MCSubtargetInfo parameter with a Triple when creatingEric Christopher2015-03-311-3/+3
| | | | | | | an MCInstPrinter. Update all callers and use where we wanted a Triple previously. llvm-svn: 233648
* Remove unused Target argument from MCInstPrinter ctor functions.Eric Christopher2015-03-301-2/+1
| | | | llvm-svn: 233607
* Add a default implementation of createObjectStreamer.Rafael Espindola2015-03-181-10/+0
| | | | | | | This removes duplicated code from backends that don't need to do anything fancy. llvm-svn: 232658
* Pass in a "const Triple &T" instead of a raw StringRef.Rafael Espindola2015-03-161-4/+3
| | | | llvm-svn: 232429
OpenPOWER on IntegriCloud