summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
...
* [CodeGen] Print "%vreg0" as "%0" in both MIR and debug outputFrancis Visoiu Mistrih2017-11-309-85/+85
| | | | | | | | | | | | | | | | | As part of the unification of the debug format and the MIR format, avoid printing "vreg" for virtual registers (which is one of the current MIR possibilities). Basically: * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E "s/%vreg([0-9]+)/%\1/g" * grep -nr '%vreg' . and fix if needed * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E "s/ vreg([0-9]+)/ %\1/g" * grep -nr 'vreg[0-9]\+' . and fix if needed Differential Revision: https://reviews.llvm.org/D40420 llvm-svn: 319427
* [MC] Function stack size section.Sean Eveson2017-11-301-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Original RFC: http://lists.llvm.org/pipermail/llvm-dev/2017-August/117028.html I wasn't sure who to put as reviewers, so please add/remove people as appropriate. This change adds a '.stack-size' section containing metadata on function stack sizes to output ELF files behind the new -stack-size-section flag. The section contains pairs of function symbol references (8 byte) and stack sizes (unsigned LEB128). The contents of this section can be used to measure changes to stack sizes between different versions of the compiler or a source base. The advantage of having a section is that we can extract this information when examining binaries that we didn't build, and it allows users and tools easy access to that information just by referencing the binary. There is a follow up change to add an option to clang. Thanks. Reviewers: hfinkel, MatzeB Reviewed By: MatzeB Subscribers: thegameg, asb, llvm-commits Differential Revision: https://reviews.llvm.org/D39788 llvm-svn: 319423
* [DAGCombine] Refactor ReduceLoadWidthSam Parker2017-11-301-50/+33
| | | | | | | | | | visitAND attempts to narrow the width of extending loads that are then masked off. ReduceLoadWidth already exists for a similar purpose and handles shifts, so I've moved the code to handle AND nodes there. Differential Revision: https://reviews.llvm.org/D39595 llvm-svn: 319421
* Support generic lowering of vector bswapSerge Guelton2017-11-301-10/+10
| | | | llvm-svn: 319419
* [SelectionDAG][X86] Teach promotion legalization for fp_to_sint/fp_to_uint ↵Craig Topper2017-11-291-3/+11
| | | | | | | | | | | | to insert an assertsext/assertzext based on the original type If we put in an assertsext/zext here, we're able to generate better truncate code using pack on pre-avx512 targets. Similar is already done during type legalization. This is the equivalent for op legalization Differential Revision: https://reviews.llvm.org/D40591 llvm-svn: 319368
* [CGP] Enable complex addr modeSerguei Katkov2017-11-291-1/+1
| | | | | | Enable complex addr modes after two critical fixes: rL319109 and rL319292 llvm-svn: 319302
* [CGP] Fix common type handling in optimizeMemoryInstSerguei Katkov2017-11-291-6/+10
| | | | | | | | | | | | | | | | | If common type is different we should bail out due to we will not be able to create a select or Phi of these values. Basically it is done in ExtAddrMode::compare however it does not work if we handle the null first and then two values of different types. so add a check in initializeMap as well. The check in ExtAddrMode::compare is used as earlier bail out. Reviewers: reames, john.brawn Reviewed By: john.brawn Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D40479 llvm-svn: 319292
* DAG: Add nuw when splitting loads and storesMatt Arsenault2017-11-296-58/+29
| | | | | | | | | | | The object can't straddle the address space wrap around, so I think it's OK to assume any offsets added to the base object pointer can't overflow. Similar logic already appears to be applied in SelectionDAGBuilder when lowering aggregate returns. llvm-svn: 319272
* [X86] Mark ISD::FP_TO_UINT v16i8/v16i16 as Promote under AVX512 instead of ↵Craig Topper2017-11-281-2/+2
| | | | | | | | | | legal. Fix infinite loop in op legalization when promotion requires 2 steps. Previously we had an isel pattern to add the truncate. Instead use Promote to add the truncate to the DAG before isel. The Promote legalization code had to be updated to prevent an infinite loop if promotion took multiple steps because it wasn't remembering the previously tried value. llvm-svn: 319259
* [SelectionDAG] Make sorting predicate stronger to remove non-deterministic ↵Mandeep Singh Grang2017-11-281-4/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | ordering Summary: Recommitting this with the correct sorting predicate. The Low field of Clusters is a ConstantInt and cannot be directly compared. So we needed to invoke slt (signed less than) to compare correctly. This fixes failures in the following tests uncovered by D39245: LLVM :: CodeGen/ARM/ifcvt3.ll LLVM :: CodeGen/ARM/switch-minsize.ll LLVM :: CodeGen/X86/switch.ll LLVM :: CodeGen/X86/switch-bt.ll LLVM :: CodeGen/X86/switch-density.ll Reviewers: hans, fhahn Reviewed By: hans Subscribers: aemerson, llvm-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D40541 llvm-svn: 319210
* [CodeGen] Fix doxygen \file comment styleFrancis Visoiu Mistrih2017-11-281-1/+1
| | | | llvm-svn: 319207
* [CodeGen] Fix doxygenFrancis Visoiu Mistrih2017-11-281-2/+1
| | | | llvm-svn: 319206
* [mir] Print/Parse both MOLoad and MOStore when they occur together.Daniel Sanders2017-11-282-6/+18
| | | | | | | | | | | | | | | | | | Summary: They're not always mutually exclusive. read-modify-write atomics are both at the same time. One example of this is the SWP instructions on AArch64. Another example is GlobalISel's G_ATOMICRMW_* generic instructions which will be added in a later patch. Reviewers: arphaman, aemerson Reviewed By: aemerson Subscribers: aemerson, javed.absar, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D40157 llvm-svn: 319202
* [CodeView] Refactor / Rewrite TypeSerializer and TypeTableBuilder.Zachary Turner2017-11-281-45/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The motivation behind this patch is that future directions require us to be able to compute the hash value of records independently of actually using them for de-duplication. The current structure of TypeSerializer / TypeTableBuilder being a single entry point that takes an unserialized type record, and then hashes and de-duplicates it is not flexible enough to allow this. At the same time, the existing TypeSerializer is already extremely complex for this very reason -- it tries to be too many things. In addition to serializing, hashing, and de-duplicating, ti also supports splitting up field list records and adding continuations. All of this functionality crammed into this one class makes it very complicated to work with and hard to maintain. To solve all of these problems, I've re-written everything from scratch and split the functionality into separate pieces that can easily be reused. The end result is that one class TypeSerializer is turned into 3 new classes SimpleTypeSerializer, ContinuationRecordBuilder, and TypeTableBuilder, each of which in isolation is simple and straightforward. A quick summary of these new classes and their responsibilities are: - SimpleTypeSerializer : Turns a non-FieldList leaf type into a series of bytes. Does not do any hashing. Every time you call it, it will re-serialize and return bytes again. The same instance can be re-used over and over to avoid re-allocations, and in exchange for this optimization the bytes returned by the serializer only live until the caller attempts to serialize a new record. - ContinuationRecordBuilder : Turns a FieldList-like record into a series of fragments. Does not do any hashing. Like SimpleTypeSerializer, returns references to privately owned bytes, so the storage is invalidated as soon as the caller tries to re-use the instance. Works equally well for LF_FIELDLIST as it does for LF_METHODLIST, solving a long-standing theoretical limitation of the previous implementation. - TypeTableBuilder : Accepts sequences of bytes that the user has already serialized, and inserts them by de-duplicating with a hash table. For the sake of convenience and efficiency, this class internally stores a SimpleTypeSerializer so that it can accept unserialized records. The same is not true of ContinuationRecordBuilder. The user is required to create their own instance of ContinuationRecordBuilder. Differential Revision: https://reviews.llvm.org/D40518 llvm-svn: 319198
* [CodeGen] Separate MachineOperand implementation from MachineInstrFrancis Visoiu Mistrih2017-11-283-701/+752
| | | | | | | | Move the implementation to its own file. Differential Revision: https://reviews.llvm.org/D40419 llvm-svn: 319194
* [CodeGen] Cleanup MachineOperandFrancis Visoiu Mistrih2017-11-281-24/+0
| | | | | | | | * clang-format * move doxygen from the implementation to headers * remove duplicate doxygen llvm-svn: 319193
* [CodeGen] Print register names in lowercase in both MIR and debug outputFrancis Visoiu Mistrih2017-11-2814-55/+57
| | | | | | | | | | | As part of the unification of the debug format and the MIR format, always print registers as lowercase. * Only debug printing is affected. It now follows MIR. Differential Revision: https://reviews.llvm.org/D40417 llvm-svn: 319187
* DAG: Legalize truncstores to illegal int typesMatt Arsenault2017-11-281-6/+16
| | | | | | | Truncate to a legal int type, and produce a new truncstore from a narrower type. llvm-svn: 319185
* Use getStoreSize() in various places instead of 'BitSize >> 3'.Jonas Paulsson2017-11-285-15/+15
| | | | | | | | | | | | | | | | | | This is needed for cases when the memory access is not as big as the width of the data type. For instance, storing i1 (1 bit) would be done in a byte (8 bits). Using 'BitSize >> 3' (or '/ 8') would e.g. give the memory access of an i1 a size of 0, which for instance makes alias analysis return NoAlias even when it shouldn't. There are no tests as this was done as a follow-up to the bugfix for the case where this was discovered (r318824). This handles more similar cases. Review: Björn Petterson https://reviews.llvm.org/D40339 llvm-svn: 319173
* [CodeGen] Rename functions PrintReg* to printReg*Francis Visoiu Mistrih2017-11-2838-151/+151
| | | | | | | | | | | LLVM Coding Standards: Function names should be verb phrases (as they represent actions), and command-like function should be imperative. The name should be camel case, and start with a lower case letter (e.g. openFile() or isFoo()). Differential Revision: https://reviews.llvm.org/D40416 llvm-svn: 319168
* [COFF] Implement constructor prioritiesMartin Storsjo2017-11-281-8/+29
| | | | | | | | | | | The priorities in the section name suffixes are zero padded, allowing the linker to just do a lexical sort. Add zero padding for .ctors sections in ELF as well. Differential Revision: https://reviews.llvm.org/D40407 llvm-svn: 319150
* [DAGCombine] Disable finding better chains for stores at O0Simon Dardis2017-11-281-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | Unoptimized IR can have linear sequences of stores to an array, where the initial GEP for the first store is formed from the pointer to the array, and the GEP for each store after the first is formed from the previous GEP with some offset in an inductive fashion. The (large) resulting DAG when analyzed by DAGCombine undergoes an excessive number of combines as each store node is examined every time its' offset node is combined with any child of the offset. One of the transformations is findBetterNeighborChains which assists MergeConsecutiveStores. The former relies on repeated chain walking to do its' work, however MergeConsecutiveStores is disabled at O0 which makes the transformation redundant. Any optimization level other than O0 would invoke InstCombine which would resolve the chain of GEPs into flat base + offset GEP for each store which does not exhibit the repeated examination of each store to the array. Disabling this optimization fixes an excessive compile time issue (30~ minutes for the test case provided) at O0. Reviewers: niravd, craig.topper, t.p.northover Differential Revision: https://reviews.llvm.org/D40193 llvm-svn: 319142
* MachineVerifier: Improve register operand checksMatthias Braun2017-11-281-78/+81
| | | | | | | | | | | | This fixes cases where we wouldn't perform various register operand checks just because we didn't happen to have a definition in the MCInstrDesc. This changes the code to only skip the tests that actually depend on the MCInstrDesc definition. This makes the machine verifier spot the problem from https://llvm.org/PR33071 after the pass that actually caused it. llvm-svn: 319141
* MachineVerifier: Improve PHI operand checkingMatthias Braun2017-11-281-28/+54
| | | | | | | | | | | | Additional checks for phi operands: - first operand should be a virtual register def. It should not be tied, implicit, internalread, earlyclobber or a read. - The other operands should be register/mbb operands next to each other - The register operands should not be implicit, internalread, earlyclobber, debug or tied. - We can perform most of the PHI checks even for unreachable blocks. llvm-svn: 319140
* [DAGCombiner] Don't combine aext(setcc) if the setcc is already using the ↵Craig Topper2017-11-271-8/+11
| | | | | | | | | | target's preferred result type. With AVX512 vXi1 types are legal so we shouldn't be extending them. This change is similar to existing code in the zext(setcc) combine. llvm-svn: 319120
* [DAGCombiner] Use EVT::changeVectorElementTypeToInteger() instead of ↵Craig Topper2017-11-271-4/+1
| | | | | | implementing manually. llvm-svn: 319119
* [SelectionDAG] Add a debug message when vector_shuffle nodes are created.Craig Topper2017-11-271-1/+3
| | | | | | We print a debug message when most nodes are created, but getVectorShuffle was missing. llvm-svn: 319085
* [CGP] Fix handling of null pointer values in optimizeMemoryInstJohn Brawn2017-11-271-9/+7
| | | | | | | | | | | The current way that trivial addressing modes are detected incorrectly thinks that null pointers are non-trivial, leading to an infinite loop where we keep duplicating the same select. Fix this by aware of null when deciding if an addressing mode is trivial. Differential Revision: https://reviews.llvm.org/D40447 llvm-svn: 319019
* [SelectionDAG] Teach SplitVecRes_SETCC to call GetSplitVector if the ↵Craig Topper2017-11-271-3/+12
| | | | | | operands have already been split. llvm-svn: 319010
* [SelectionDAG] Fix function name in comment. NFCCraig Topper2017-11-271-2/+2
| | | | llvm-svn: 319009
* [SelectionDAG] Remove some dead code from vector scalaringCraig Topper2017-11-251-16/+1
| | | | | | | | | | | | | | | | | Summary: Currently ScalarizeVecRes_SETCC checks for the result type being a vector and jumps to ScalarizeVecRes_VSETCC. But if we're scalarizing a vector result, aren't we guaranteed to be looking at a vector type? This patch deletes the current ScalarizeVecRes_SETCC and renames ScalarizeVecRes_VSETCC to ScalarizeVecRes_SETCC. Reviewers: RKSimon, arsenm, eladcohen, zvi Reviewed By: RKSimon Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D40452 llvm-svn: 318982
* [CodeGenPrepare] Check that erased sunken address are not reusedSimon Dardis2017-11-241-5/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | CodeGenPrepare sinks address computations from one basic block to another and attempts to reuse address computations that have already been sunk. If the same address computation appears twice with the first instance as an operand of a load whose result is an operand to a simplifable select, CodeGenPrepare simplifies the select and recursively erases the now dead instructions. CodeGenPrepare then attempts to use the erased address computation for the second load. Fix this by erasing the cached address value if it has zero uses before looking for the address value in the sunken address map. This partially resolves PR35209. Thanks to Alexander Richardson for reporting the issue! This fixed version relands r318032 which was reverted in r318049 due to sanitizer buildbot failures. Reviewers: john.brawn Differential Revision: https://reviews.llvm.org/D39841 llvm-svn: 318956
* Make helpers static. NFC.Benjamin Kramer2017-11-241-4/+4
| | | | llvm-svn: 318953
* [CGP] Make optimizeMemoryInst able to combine more kinds of ExtAddrMode fieldsJohn Brawn2017-11-241-12/+94
| | | | | | | | | | | | | This patch extends the recent work in optimizeMemoryInst to make it able to combine more ExtAddrMode fields than just the BaseReg. This fixes some benchmark regressions introduced by r309397, where GVN PRE is hoisting a getelementptr such that it can no longer be combined into the addressing mode of the load or store that uses it. Differential Revision: https://reviews.llvm.org/D38133 llvm-svn: 318949
* [ARM GlobalISel] Support G_FDIV for s32 and s64Diana Picus2017-11-231-0/+4
| | | | | | | | | | | | TableGen already generates code for selecting a G_FDIV, so we only need to add a test. For the legalizer and reg bank select, we do the same thing as for the other floating point binary operations: either mark as legal if we have a FP unit or lower to a libcall, and map to the floating point registers. llvm-svn: 318915
* [ARM GlobalISel] Support G_FMUL for s32 and s64Diana Picus2017-11-231-0/+4
| | | | | | | | | | | TableGen already generates code for selecting a G_FMUL, so we only need to add a test for that part. For the legalizer and reg bank select, we do the same thing as the other floating point binary operators: either mark as legal if we have a FP unit or lower to a libcall, and map to the floating point registers. llvm-svn: 318910
* [NFC] CodeGen: Handle shift amount type in DAGTypeLegalizer::SplitIntegerYaxun Liu2017-11-231-5/+8
| | | | | | | | | | | | | | | | This patch reverts change to X86TargetLowering::getScalarShiftAmountTy in rL318727 and move the logic to DAGTypeLegalizer::SplitInteger. The reason is that getScalarShiftAmountTy returns a shift amount type that is suitable for common use cases in CodeGen. DAGTypeLegalizer::SplitInteger is a rare situation which requires a shift amount type larger than what getScalarShiftAmountTy. In this case, it is more reasonable to do special handling of shift amount type in DAGTypeLegalizer::SplitInteger only. If similar situations arises the logic may be moved to a separate function. Differential Revision: https://reviews.llvm.org/D40320 llvm-svn: 318890
* [DAGCombiner] Bugfix in isAlias().Jonas Paulsson2017-11-221-2/+2
| | | | | | | | | | | | | | | | | Since i1 is a legal type, this: NumBytes = Op1->getMemoryVT().getSizeInBits() >> 3; is wrong and should be instead NumBytes = Op0->getMemoryVT().getStoreSize(); There seems to be more places where this should be fixed outside DAGCombiner. Review: Hal Finkel https://bugs.llvm.org/show_bug.cgi?id=35366 llvm-svn: 318824
* [SelectionDAG] Add a isel matcher op to check the type of node results other ↵Craig Topper2017-11-221-0/+14
| | | | | | | | than result 0. I plan to use this to check the type of the mask result of masked gathers in the X86 backend. llvm-svn: 318820
* Revert "[CGP] Enable complex addr mode (2nd attempt)"Serguei Katkov2017-11-211-1/+1
| | | | | | Revert the patch rl318728 causing buildbot hangs-ups. llvm-svn: 318731
* [CGP] Enable complex addr mode (2nd attempt)Serguei Katkov2017-11-211-1/+1
| | | | | | | 2nd attempt to enable complex addr modes after fix of the crash by rL318638. llvm-svn: 318728
* [AMDGPU] Fix DAGTypeLegalizer::SplitInteger for shift amount typeYaxun Liu2017-11-211-3/+5
| | | | | | | | | | | | | | | DAGTypeLegalizer::SplitInteger uses default pointer size as shift amount constant type, which causes less performant ISA in amdgcn---amdgiz target since the default pointer type is i64 whereas the desired shift amount type is i32. This patch fixes that by using TLI.getScalarShiftAmountTy in DAGTypeLegalizer::SplitInteger. The X86 change is necessary since splitting i512 requires shifting amount of 256, which cannot be held by i8. Differential Revision: https://reviews.llvm.org/D40148 llvm-svn: 318727
* [SelectionDAG] When promoting the result of a VSELECT, make sure we promote ↵Craig Topper2017-11-201-3/+2
| | | | | | | | | | | | the condition to the SetCC type for the final result type not the original type. Normally this would be cleaned up by promoting the condition operand next. But in the attached case we promoted the result from v2i48 to v2i64 and the condition from v2i1 to v2i48. Then we tried to "promote" the v2i48 condition back to v2i1 because that's what the SetCC result type for v2i64 is on X86 with VLX. But promote is either a NOP or SIGN_EXTEND and this would need a truncation. With the change here we now get the SetCC type of v2i1 when we're handling the result promotion and the operand no longer needs to be promoted itself. Fixes PR35272. llvm-svn: 318706
* Revert "[SelectionDAG] Make sorting predicate stronger to remove ↵Mandeep Singh Grang2017-11-201-9/+4
| | | | | | | | | | non-deterministic ordering" This broke the bots. Reverting this until I can fix the failures. This reverts commit 5a3db2856d12a3c4b400f487d39f8f05989e79f0. llvm-svn: 318686
* Revert "Fix out-of-order stepping behavior in programs with sunk instructions."Paul Robinson2017-11-201-11/+0
| | | | | | | This reverts commit 30419e150cd940893a13b345e85f96053850208f. aka r318679. It caused "sanitizer-windows" bot to fail. llvm-svn: 318684
* [SelectionDAG] Make sorting predicate stronger to remove non-deterministic ↵Mandeep Singh Grang2017-11-201-4/+9
| | | | | | | | | | | | | | | | | | | | ordering Summary: This fixes failures in the following tests uncovered by D39245: LLVM :: CodeGen/ARM/ifcvt3.ll LLVM :: CodeGen/ARM/switch-minsize.ll LLVM :: CodeGen/X86/switch.ll Reviewers: hans, efriedma Reviewed By: hans Subscribers: fhahn, aemerson, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D39995 llvm-svn: 318680
* Fix out-of-order stepping behavior in programs with sunk instructions.Paul Robinson2017-11-201-0/+11
| | | | | | | | | | | | | | | | MachineSink attempts to place instructions near the basic blocks where they are needed. Once an instruction has been sunk, its location relative to other instructions is no longer consistent with the original source code. In order to ensure correct single-stepping and profiling, the debug location for sunk instructions is either merged with the insertion point or erased if the target successor block is empty. Patch by Matthew Voss! Differential Revision: https://reviews.llvm.org/D39933 llvm-svn: 318679
* [MachineCSE] Add new callback for is caller preserved or constant physregsTony Jiang2017-11-202-2/+9
| | | | | | | | | | | | | The instructions addis,addi, bl are used to calculate the address of TLS thread local variables. These TLS access code sequences are generated repeatedly every time the thread local variable is accessed. By communicating to Machine CSE that X2 is guaranteed to have the same value within the same function call (so called Caller Preserved Physical Register), the redundant TLS access code sequences are cleaned up. Differential Revision: https://reviews.llvm.org/D39173 llvm-svn: 318661
* [CGP] Fix the crash caused by enable of complex addr modeSerguei Katkov2017-11-201-9/+5
| | | | | | | | | | | | | We must collect all AddModes even if they are the same. This is due to Original value is different but we need all original values collected as they are used as anchors in common phi finding. Reviewers: john.brawn, reames Reviewed By: john.brawn Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D40166 llvm-svn: 318638
* [RegisterBankInfo] Relax the assert of having matching type sizes on default ↵Quentin Colombet2017-11-181-1/+5
| | | | | | | | | | | | | | | | | | mappings Instead of asserting that the type sizes are exactly equal, we check that the new size is big enough to contain the original type. We have to relax this constrain because, right now, we sometimes specify that things that are smaller than a storage type are legal instead of widening everything to the size of a storage type. E.g., we say that G_AND s16 is legal and we map that on GPR32. This is something we may revisit in the future (either by changing the legalization process or keeping track separately of the storage size and the size of the type), but let us reflect the reality of the situation for now. llvm-svn: 318587
OpenPOWER on IntegriCloud