summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix a crash when emitting DIEs for variable-length arraysAdrian Prantl2018-02-063-33/+50
| | | | | | | | | | | | | VLAs may refer to a previous DIE to express the DW_AT_count of their type. Clang generates an artificial "vla_expr" variable for this. If this DIE hasn't been created yet LLVM asserts. This patch fixes this by sorting the local variables so that dependencies come before they are needed. It also replaces the linear scan in DWARFFile with a std::map, which can be faster. Differential Revision: https://reviews.llvm.org/D42940 llvm-svn: 324412
* [TargetLowering] use local variable to reduce duplication; NFCISanjay Patel2018-02-061-52/+32
| | | | llvm-svn: 324401
* [TargetLowering] use local variables to reduce duplication; NFCISanjay Patel2018-02-061-6/+6
| | | | llvm-svn: 324397
* [DAG, X86] Improve Dependency analysis when doing multi-nodeNirav Dave2018-02-061-215/+80
| | | | | | | | | | | | | | | | | | | | Instruction Selection Cleanup cycle/validity checks in ISel (IsLegalToFold, HandleMergeInputChains) and X86 (isFusableLoadOpStore). Now do a full search for cycles / dependencies pruning the search when topological property of NodeId allows. As part of this propogate the NodeId-based cutoffs to narrow hasPreprocessorHelper searches. Reviewers: craig.topper, bogner Subscribers: llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D41293 llvm-svn: 324359
* Fix unused variable warning in release mode. NFC.Alexander Ivchenko2018-02-061-0/+1
| | | | llvm-svn: 324330
* Revert "[MergeICmps] Enable the MergeICmps Pass by default."Clement Courbet2018-02-061-4/+5
| | | | | | | | Breaks clang-ppc64be-linux-multistage buildbot. This reverts commit 515bab711f308c2e8299c49dd8c84ea6a2e0b60e. llvm-svn: 324319
* [MergeICmps] Enable the MergeICmps Pass by default.Clement Courbet2018-02-061-5/+4
| | | | | | | | | | | | Summary: Now that PR33325 is fixed, this should always improve the generated code. Reviewers: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42793 llvm-svn: 324317
* [DAGCombiner] Pass the original load to ExtendSetCCUses not the turncate.Craig Topper2018-02-061-11/+12
| | | | | | | | | | | | | | | | | | | | | | | Summary: This method is trying to use the truncate node to find which SETCC operand should be replaced directly with the extended load. This used to work correctly because all uses of the original load were replaced by the truncate before this function was called. So this was used to effectively bypass the truncate and find the load under it. All but one of the callers now call this before the truncate has replaced the laod so the setcc doesn't yet use the truncate. To account for this we should pass the original load instead. I changed the order of that one caller to make this work there too. I don't have a test case because this is probably hidden by later DAG combines causing the extend and truncate to cancel out. I assume this way is a little more efficient and matches what was originally intended. Reviewers: RKSimon, spatel, niravd Reviewed By: niravd Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42878 llvm-svn: 324311
* [PEI][NFC] Move StackSize opt-remark code next to -warn-stack codeFrancis Visoiu Mistrih2018-02-051-7/+6
| | | | | | | This allows us to make sure we're always having the same sizes in both remarks and warnings. llvm-svn: 324283
* [SDAG] Legalize all CondCodes by inverting them and/or swapping operandsKrzysztof Parzyszek2018-02-051-12/+19
| | | | | | Differential Revision: https://reviews.llvm.org/D42788 llvm-svn: 324274
* [DAGCombiner] When folding fold (sext/zext (and/or/xor (sextload/zextload ↵Craig Topper2018-02-031-4/+6
| | | | | | | | | | | | | | | | | | | x), cst)) -> (and/or/xor (sextload/zextload x), (sext/zext cst)) make sure we check the legality of the full extended load. Summary: If the load is already an extended load we should be using the memory VT for the legality check, not just the VT of the current extension. I don't have a test case, just noticed it while investigating some load extension improvements. Reviewers: RKSimon, spatel, niravd Reviewed By: niravd Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42783 llvm-svn: 324181
* [SelectionDAG] Don't use simple VT in generic shuffle codeSimon Pilgrim2018-02-031-1/+1
| | | | | | | | Better to assume that any value type may be commuted, not just MVTs. No test case right now, but discovered while investigating possible shuffle combines. llvm-svn: 324179
* [GISel][NFC]: Move RegisterBankInfo::getSizeInBits into TargetRegisterInfo.Aditya Nandakumar2018-02-022-13/+27
| | | | llvm-svn: 324125
* [SelectionDAG] Consider endianness in scalarizeVectorStore().Jonas Paulsson2018-02-021-2/+5
| | | | | | | | | | | | When handling vectors with non byte-sized elements, reverse the order of the elements in the built integer if the target is Big-Endian. SystemZ tests updated. Review: Eli Friedman, Ulrich Weigand. https://reviews.llvm.org/D42786 llvm-svn: 324063
* [SelectionDAG] Add an assert in getNode() for EXTRACT_VECTOR_ELT.Jonas Paulsson2018-02-021-0/+4
| | | | | | | | When getNode() is called to create an EXTRACT_VECTOR_ELT, assert that the result VT is at least as wide as the vector element type. Review: Eli Friedman llvm-svn: 324061
* Fix debug spelling in ResetMachineFunction pass.Amara Emerson2018-02-021-2/+2
| | | | llvm-svn: 324048
* SplitKit: Fix liveness recomputation in some remat cases.Matthias Braun2018-02-022-11/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Example situation: ``` BB0: %0 = ... use %0 ; ... condjump BB1 jmp BB2 BB1: %0 = ... ; rematerialized def from above (from earlier split step) jmp BB2 BB2: ; ... use %0 ``` %0 will have a live interval with 3 value numbers (for the BB0, BB1 and BB2 parts). Now SplitKit tries and succeeds in rematerializing the value number in BB2 (This only works because it is a secondary split so SplitKit is can trace this back to a single original def). We need to recompute all live ranges affected by a value number that we rematerialize. The case that we missed before is that when the value that is rematerialized is at a join (Phi VNI) then we also have to recompute liveness for the predecessor VNIs. rdar://35699130 Differential Revision: https://reviews.llvm.org/D42667 llvm-svn: 324039
* [GlobalISel][Legalizer] Relax a legalization loop detecting assert.Amara Emerson2018-02-011-1/+3
| | | | | | | Legalizing vectors may keep the element type the same but change the number of elements, the assert didn't take this into account. llvm-svn: 324028
* [DAGCombiner] When folding (insert_subvector undef, (bitcast ↵Craig Topper2018-02-011-1/+3
| | | | | | | | | | | | (extract_subvector N1, Idx)), Idx) -> (bitcast N1) make sure that N1 has the same total size as the original output We were only checking the element count, but not the total width. This could cause illegal bitcasts to be created if for example the output was 512-bits, but N1 is 256 bits, and the extraction size was 128-bits. Fixes PR36199 Differential Revision: https://reviews.llvm.org/D42809 llvm-svn: 324002
* [GlobalISel] Fix assert failure when legalizing non-power-2 loads.Amara Emerson2018-02-011-3/+6
| | | | | | | Until we support extending loads properly we're going to fall back for these. We already handle stores in the same way, so this is just being consistent. llvm-svn: 324001
* [CodeView] Class record member counts should include base classes and ...Brock Wyma2018-02-011-0/+2
| | | | | | | | | Increment the field list member count for base classes and virtual base classes. Differential Revision: https://reviews.llvm.org/D41874 llvm-svn: 324000
* [MachineCopyPropagation] Extend pass to do COPY source forwardingGeoff Berry2018-02-012-1/+210
| | | | | | | | | | | | | | | | | | | | | | Summary: This change extends MachineCopyPropagation to do COPY source forwarding and adds an additional run of the pass to the default pass pipeline just after register allocation. This version of this patch uses the newly added MachineOperand::isRenamable bit to avoid forwarding registers is such a way as to violate constraints that aren't captured in the Machine IR (e.g. ABI or ISA constraints). This change is a continuation of the work started in D30751. Reviewers: qcolombet, javed.absar, MatzeB, jonpa, tstellar Subscribers: tpr, mgorny, mcrosier, nhaehnle, nemanjai, jyknight, hfinkel, arsenm, inouehrs, eraman, sdardis, guyblank, fedor.sergeev, aheejin, dschuff, jfb, myatsina, llvm-commits Differential Revision: https://reviews.llvm.org/D41835 llvm-svn: 323991
* [DAGCombiner] filter out denorm inputs when calculating sqrt estimate (PR34994)Sanjay Patel2018-02-011-10/+25
| | | | | | | | | | | | | | | | | | | | | | | As shown in the example in PR34994: https://bugs.llvm.org/show_bug.cgi?id=34994 ...we can return a very wrong answer (inf instead of 0.0) for square root when using a reciprocal square root estimate instruction. Here, I've conditionalized the filtering out of denorms based on the function having "denormal-fp-math"="ieee" in its attributes. The other options for this attribute are 'preserve-sign' and 'positive-zero'. So we don't generate this extra code by default with just '-ffast-math' (because then there's no denormal attribute string at all), but it works if you specify '-ffast-math -fdenormal-fp-math=ieee' from clang. As noted in the review, there may be other problems in clang that affect the results depending on platform (Linux x86 at least), but this should allow creating the desired codegen. Differential Revision: https://reviews.llvm.org/D42323 llvm-svn: 323981
* [SelectionDAG] Fix UpdateChains handling of TokenFactorsNirav Dave2018-02-011-1/+2
| | | | | | | | | | | | | | | | | | | Summary: In Instruction Selection UpdateChains replaces all matched Nodes' chain references including interior token factors and deletes them. This may allow nodes which depend on these interior nodes but are not part of the set of matched nodes to be left with a dangling dependence. Avoid this by doing the replacement for matched non-TokenFactor nodes. Fixes PR36164. Reviewers: jonpa, RKSimon, bogner Subscribers: llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D42754 llvm-svn: 323977
* [XRay][compiler-rt+llvm] Update XRay register stashing semanticsDean Michael Berris2018-02-012-0/+16
| | | | | | | | | | | | | | | | | | | | | | Summary: This change expands the amount of registers stashed by the entry and `__xray_CustomEvent` trampolines. We've found that since the `__xray_CustomEvent` trampoline calls can show up in situations where the scratch registers are being used, and since we don't typically want to affect the code-gen around the disabled `__xray_customevent(...)` intrinsic calls, that we need to save and restore the state of even the scratch registers in the handling of these custom events. Reviewers: pcc, pelikan, dblaikie, eizan, kpw, echristo, chandlerc Reviewed By: echristo Subscribers: chandlerc, echristo, hiraditya, davide, dblaikie, llvm-commits Differential Revision: https://reviews.llvm.org/D40894 llvm-svn: 323940
* DAG: Fix not truncating when promoting bswap/bitreverseMatt Arsenault2018-01-311-1/+2
| | | | | | | These need to convert back to the original type, like any other promotion. llvm-svn: 323932
* Followup on Proposal to move MIR physical register namespace to '$' sigil.Puyan Lotfi2018-01-312-10/+19
| | | | | | | | | | | | Discussed here: http://lists.llvm.org/pipermail/llvm-dev/2018-January/120320.html In preparation for adding support for named vregs we are changing the sigil for physical registers in MIR to '$' from '%'. This will prevent name clashes of named physical register with named vregs. llvm-svn: 323922
* [MachineOutliner] Freeze registers in new functionsGeoff Berry2018-01-311-0/+2
| | | | | | | | | | | | | | | Summary: Call MRI.freezeReservedRegs() on functions created during outlining so that calls to isReserved() by the verifier called after this pass won't assert. Reviewers: MatzeB, qcolombet, paquette Subscribers: mcrosier, javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D42749 llvm-svn: 323905
* [CodeGenPrepare] Improve source and dest alignments of memory intrinsics ↵Daniel Neilson2018-01-311-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | independently Summary: This change is part of step five in the series of changes to remove alignment argument from memcpy/memmove/memset in favour of alignment attributes. In particular, this changes the CodeGenPrepare pass to be more aggressive in improving the source and destination alignments of memcpy/memmove/memset by exploiting our new ability to record independent alignments for each argument. Steps: Step 1) Remove alignment parameter and create alignment parameter attributes for memcpy/memmove/memset. ( rL322965, rC322964, rL322963 ) Step 2) Expand the IRBuilder API to allow creation of memcpy/memmove with differing source and dest alignments. ( rL323597 ) Step 3) Update Clang to use the new IRBuilder API. ( rC323617 ) Step 4) Update Polly to use the new IRBuilder API. ( rL323618 ) Step 5) Update LLVM passes that create memcpy/memmove calls to use the new IRBuilder API, and those that use use MemIntrinsicInst::[get|set]Alignment() to use [get|set]DestAlignment() and [get|set]SourceAlignment() instead. ( rL323886 ) Step 6) Remove the single-alignment IRBuilder API for memcpy/memmove, and the MemIntrinsicInst::[get|set]Alignment() methods. Reference http://lists.llvm.org/pipermail/llvm-dev/2015-August/089384.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html llvm-svn: 323891
* [DWARF] Allow duplication of tails with CFI instructionsPetar Jovanovic2018-01-311-2/+16
| | | | | | | | | | | | | | | | | | This commit came as a result for revert of patch r317579 (originally committed as r317100). The patch made CFI instructions duplicable, because their existence in the epilogue block was affecting the Tail duplication pass. However, duplicating blocks with CFI instructions was an issue for compact unwind info on Darwin, which is why the patch was reverted. This patch allows duplicating tails with CFI instructions, though they are not duplicable, by copying them 'manually'. Patch by Djordje Kovacevic. Differential Revision: https://reviews.llvm.org/D40979 llvm-svn: 323883
* [DAG] Prevent NodeId pruning of TokenFactors in Instruction Selection.Nirav Dave2018-01-311-1/+3
| | | | | | | | | | | | | | | | | | Summary: Instruction Selection preserves relative orders of all nodes save TokenFactors which we treat specially. As a result Node Ids for TokenFactors may violate the topological ordering and should not be considered as valid pruning candidates in predecessor search. Fixes PR35316. Reviewers: RKSimon, hfinkel Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D42701 llvm-svn: 323880
* [MachineCombiner] Add check for optimal pattern order.Florian Hahn2018-01-311-16/+82
| | | | | | | | | | | | | | | | | | | | | | In D41587, @mssimpso discovered that the order of some patterns for AArch64 was sub-optimal. I thought a bit about how we could avoid that case in the future. I do not think there is a need for evaluating all patterns for now. But this patch adds an extra (expensive) check, that evaluates the latencies of all patterns, and ensures that the latency saved decreases for subsequent patterns. This catches the sub-optimal order fixed in D41587, but I am not entirely happy with the check, as it only applies to sub-optimal patterns seen while building with EXPENSIVE_CHECKS on. It did not discover any other sub-optimal pattern ordering. Reviewers: Gerolf, spatel, mssimpso Reviewed By: Gerolf, mssimpso Differential Revision: https://reviews.llvm.org/D41766 llvm-svn: 323873
* Take into account the cost of local intervals when selecting split candidate.Marina Yatsina2018-01-312-12/+86
| | | | | | | | | | | | | When selecting a split candidate for region splitting, the register allocator tries to predict which candidate will have the cheapest spill cost. Global splitting may cause the creation of local intervals, and they might spill. This patch makes RA take into account the spill cost of local split intervals in use blocks (we already take into account the spill cost in through blocks). A flag ("-condsider-local-interval-cost") controls weather we do this advanced cost calculation (it's on by default for X86 target, off for the rest). Differential Revision: https://reviews.llvm.org/D41585 Change-Id: Icccb8ad2dbf13124f5d97a18c67d95aa6be0d14d llvm-svn: 323870
* [ARM] Allow the scheduler to clone a node with glue to avoid a copy CPSR ↔ ↵Roger Ferrer Ibanez2018-01-311-4/+16
| | | | | | | | | | | | | | | | | | | | | | GPR. In Thumb 1, with the new ADDCARRY / SUBCARRY the scheduler may need to do copies CPSR ↔ GPR but not all Thumb1 targets implement them. The schedule can attempt, before attempting a copy, to clone the instructions but it does not currently do that for nodes with input glue. In this patch we introduce a target-hook to let the hook decide if a glued machinenode is still eligible for copying. In this case these are ARM::tADCS and ARM::tSBCS . As a follow-up of this change we should actually implement the copies for the Thumb1 targets that do implement them and restrict the hook to the targets that can't really do such copy as these clones are not ideal. This change fixes PR35836. Differential Revision: https://reviews.llvm.org/D42051 llvm-svn: 323857
* Revert r323559 due to EXPENSIVE_CHECKS regression.Eli Friedman2018-01-311-2/+2
| | | | | | | I have a fix for the issue (https://reviews.llvm.org/D42655) but it's taking a while to get reviewed, so reverting in the meantime. llvm-svn: 323841
* LLParser: add an argument for overriding data layout and do not check alloca ↵Yaxun Liu2018-01-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | addr space Sometimes users do not specify data layout in LLVM assembly and let llc set the data layout by target triple after loading the LLVM assembly. Currently the parser checks alloca address space no matter whether the LLVM assembly contains data layout definition, which causes false alarm since the default data layout does not contain the correct alloca address space. The parser also calls verifier to check debug info and updating invalid debug info. Currently there is no way to let the verifier to check debug info only. If the verifier finds non-debug-info issues the parser will fail. For llc, the fix is to remove the check of alloca addr space in the parser and disable updating debug info, and defer the updating of debug info and verification to be after setting data layout of the IR by target. For other llvm tools, since they do not override data layout by target but instead can override data layout by a command line option, an argument for overriding data layout is added to the parser. In cases where data layout overriding is necessary for the parser, the data layout can be provided by command line. Differential Revision: https://reviews.llvm.org/D41832 llvm-svn: 323826
* [GlobalISel] Bail out on calls to dllimported functionsMartin Storsjo2018-01-301-0/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D42568 llvm-svn: 323811
* CodeGen: support an extension to pass linker options on ELFSaleem Abdulrasool2018-01-301-1/+18
| | | | | | | | | | | | | | | | | | Introduce an extension to support passing linker options to the linker. These would be ignored by older linkers, but newer linkers which support this feature would be able to process the linker. Emit a special discarded section `.linker-option`. The content of this section is a pair of strings (key, value). The key is a type identifier for the parameter. This allows for an argument free parameter that will be processed by the linker with the value being the parameter. As an example, `lib` identifies a library to be linked against, traditionally the `-l` argument for Unix-based linkers with the parameter being the library name. Thanks to James Henderson, Cary Coutant, Rafael Espinolda, Sean Silva for the valuable discussion on the design of this feature. llvm-svn: 323783
* [mips] Fix incorrect sign extension for fpowi libcallSimon Dardis2018-01-301-5/+7
| | | | | | | | | | | | | | | | | PR36061 showed that during the expansion of ISD::FPOWI, that there was an incorrect zero extension of the integer argument which for MIPS64 would then give incorrect results. Address this with the existing mechanism for correcting sign extensions. This resolves PR36061. Thanks to James Cowgill for reporting the issue! Reviewers: atanasyan, hfinkel Differential Revision: https://reviews.llvm.org/D42537 llvm-svn: 323781
* [AccelTable] Move print methods to implementation. NFCJonas Devlieghere2018-01-301-0/+83
| | | | | | | This patch moves the implementation of the print methods from the header to the cpp file. llvm-svn: 323757
* Test commit.Brock Wyma2018-01-301-2/+2
| | | | | | As per the LLVM Developer Policy under "Obtainiing Commit Access". llvm-svn: 323754
* [ARM GlobalISel] Legalize G_SITOFP and G_UITOFPDiana Picus2018-01-301-0/+19
| | | | | | | | Legal if we have hardware support, libcall otherwise. Also add supporting code to the legalizer helper for libcalls. llvm-svn: 323730
* [ARM GlobalISel] Legalize G_FPTOSI and G_FPTOUIDiana Picus2018-01-301-0/+18
| | | | | | | | | Legal if we have hardware support for floating point, libcalls otherwise. Also add the necessary support for libcalls in the legalizer helper. llvm-svn: 323726
* [SelectionDAG]: Ignore "returned" in the presence of an implicit sret.Dan Gohman2018-01-301-2/+4
| | | | | | | | | | | | | | | | When a function return value can't be directly lowered, such as returning an i128 on WebAssembly, as indicated by the CanLowerReturn target hook, SelectionDAGBuilder can translate it to return the value through a hidden sret-like argument. If such a function has an argument with the "returned" attribute, the attribute can't be automatically lowered, because the function no longer has a normal return value. For now, just discard the "returned" attribute. This fixes PR36128. llvm-svn: 323715
* [RAFast] Don't dereference MBB::endQuentin Colombet2018-01-291-5/+6
| | | | | | | | | | | | | | | | When RAFast sees liveins in on a basic block, it uses that information to initialize the availability of the registers. The called method uses an instruction as one of its argument and in the liveins case, RAFast was dereferencing MBB::begin which can be MBB::end for empty basic block. Change the API of definePhysReg to use MachineBasicBlock::iterator instead of MachineInstr so that we don't dereference an invalid iterator while making the call. rdar://problem/36952401 llvm-svn: 323710
* LiveInterval: Print weight in print() function.Matthias Braun2018-01-291-0/+1
| | | | llvm-svn: 323702
* [ARM][GISel] PR35965 Constrain RegClasses of nested instructions built from ↵Daniel Sanders2018-01-291-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Dst Pattern Summary: Apparently, we missed on constraining register classes of VReg-operands of all the instructions built from a destination pattern but the root (top-level) one. The issue exposed itself while selecting G_FPTOSI for armv7: the corresponding pattern generates VTOSIZS wrapped into COPY_TO_REGCLASS, so top-level COPY_TO_REGCLASS gets properly constrained, while nested VTOSIZS (or rather its destination virtual register to be exact) does not. Fixing this by issuing GIR_ConstrainSelectedInstOperands for every nested GIR_BuildMI. https://bugs.llvm.org/show_bug.cgi?id=35965 rdar://problem/36886530 Patch by Roman Tereshin Reviewers: dsanders, qcolombet, rovka, bogner, aditya_nandakumar, volkan Reviewed By: dsanders, qcolombet, rovka Subscribers: aemerson, javed.absar, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D42565 llvm-svn: 323692
* [globalisel][legalizer] Change identity() to changeTo() to clarify that it ↵Daniel Sanders2018-01-291-1/+1
| | | | | | | | | | | | | changes things. NFC Prior to committing r323681, we decided to change pick() to identity() since it wasn't clear from the name what pick() did. However, identity() isn't a very good name either since it implies that no changes are made. For some reason, naming it changeTo() didn't occur to me until just after the commit. This should resolve the lack of clarity that pick() had while still implying that it changes the MIR. llvm-svn: 323689
* [CodeGen] Simplify conditional. NFCShoaib Meenai2018-01-291-1/+1
| | | | | | | | | | | Rafael pointed out that `hasInternalLinkage() || hasPrivateLinkage()` is equivalent to `hasLocalLinkage()` in post-commit review. I'm intentionally not updating the comment, partly because I like it being explicit, and partly because "global symbols with local linkage" sounds like an oxymoron. llvm-svn: 323688
* [globalisel][legalizer] Adapt LegalizerInfo to support inter-type ↵Daniel Sanders2018-01-294-6/+228
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | dependencies and other things. Summary: As discussed in D42244, we have difficulty describing the legality of some operations. We're not able to specify relationships between types. For example, declaring the following setAction({..., 0, s32}, Legal) setAction({..., 0, s64}, Legal) setAction({..., 1, s32}, Legal) setAction({..., 1, s64}, Legal) currently declares these type combinations as legal: {s32, s32} {s64, s32} {s32, s64} {s64, s64} but we currently have no means to say that, for example, {s64, s32} is not legal. Some operations such as G_INSERT/G_EXTRACT/G_MERGE_VALUES/ G_UNMERGE_VALUES have relationships between the types that are currently described incorrectly. Additionally, G_LOAD/G_STORE currently have no means to legalize non-atomics differently to atomics. The necessary information is in the MMO but we have no way to use this in the legalizer. Similarly, there is currently no way for the register type and the memory type to differ so there is no way to cleanly represent extending-load/truncating-store in a way that can't be broken by optimizers (resulting in illegal MIR). It's also difficult to control the legalization strategy. We've added support for legalizing non-power of 2 types but there's still some hardcoded assumptions about the strategy. The main one I've noticed is that type0 is always legalized before type1 which is not a good strategy for `type0 = G_EXTRACT type1, ...` if you need to widen the container. It will converge on the same result eventually but it will take a much longer route when legalizing type0 than if you legalize type1 first. Lastly, the definition of legality and the legalization strategy is kept separate which is not ideal. It's helpful to be able to look at a one piece of code and see both what is legal and the method the legalizer will use to make illegal MIR more legal. This patch adds a layer onto the LegalizerInfo (to be removed when all targets have been migrated) which resolves all these issues. Here are the rules for shift and division: for (unsigned BinOp : {G_LSHR, G_ASHR, G_SDIV, G_UDIV}) getActionDefinitions(BinOp) .legalFor({s32, s64}) // If type0 is s32/s64 then it's Legal .clampScalar(0, s32, s64) // If type0 is <s32 then WidenScalar to s32 // If type0 is >s64 then NarrowScalar to s64 .widenScalarToPow2(0) // Round type0 scalars up to powers of 2 .unsupported(); // Otherwise, it's unsupported This describes everything needed to both define legality and describe how to make illegal things legal. Here's an example of a complex rule: getActionDefinitions(G_INSERT) .unsupportedIf([=](const LegalityQuery &Query) { // If type0 is smaller than type1 then it's unsupported return Query.Types[0].getSizeInBits() <= Query.Types[1].getSizeInBits(); }) .legalIf([=](const LegalityQuery &Query) { // If type0 is s32/s64/p0 and type1 is a power of 2 other than 2 or 4 then it's legal // We don't need to worry about large type1's because unsupportedIf caught that. const LLT &Ty0 = Query.Types[0]; const LLT &Ty1 = Query.Types[1]; if (Ty0 != s32 && Ty0 != s64 && Ty0 != p0) return false; return isPowerOf2_32(Ty1.getSizeInBits()) && (Ty1.getSizeInBits() == 1 || Ty1.getSizeInBits() >= 8); }) .clampScalar(0, s32, s64) .widenScalarToPow2(0) .maxScalarIf(typeInSet(0, {s32}), 1, s16) // If type0 is s32 and type1 is bigger than s16 then NarrowScalar type1 to s16 .maxScalarIf(typeInSet(0, {s64}), 1, s32) // If type0 is s64 and type1 is bigger than s32 then NarrowScalar type1 to s32 .widenScalarToPow2(1) // Round type1 scalars up to powers of 2 .unsupported(); This uses a lambda to say that G_INSERT is unsupported when type0 is bigger than type1 (in practice, this would be a default rule for G_INSERT). It also uses one to describe the legal cases. This particular predicate is equivalent to: .legalFor({{s32, s1}, {s32, s8}, {s32, s16}, {s64, s1}, {s64, s8}, {s64, s16}, {s64, s32}}) In terms of performance, I saw a slight (~6%) performance improvement when AArch64 was around 30% ported but it's pretty much break even right now. I'm going to take a look at constexpr as a means to reduce the initialization cost. Future work: * Make it possible for opcodes to share rulesets. There's no need for G_LSHR/G_ASHR/G_SDIV/G_UDIV to have separate rule and ruleset objects. There's no technical barrier to this, it just hasn't been done yet. * Replace the type-index numbers with an enum to get .clampScalar(Type0, s32, s64) * Better names for things like .maxScalarIf() (clampMaxScalar?) and the vector rules. * Improve initialization cost using constexpr Possible future work: * It's possible to make these rulesets change the MIR directly instead of returning a description of how to change the MIR. This should remove a little overhead caused by parsing the description and routing to the right code, but the real motivation is that it removes the need for LegalizeAction::Custom. With Custom removed, there's no longer a requirement that Custom legalization change the opcode to something that's considered legal. Reviewers: ab, t.p.northover, qcolombet, rovka, aditya_nandakumar, volkan, reames, bogner Reviewed By: bogner Subscribers: hintonda, bogner, aemerson, mgorny, javed.absar, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D42251 llvm-svn: 323681
OpenPOWER on IntegriCloud