summaryrefslogtreecommitdiffstats
path: root/llvm/test/CodeGen/RISCV
Commit message (Collapse)AuthorAgeFilesLines
* [RISCV] Re-organise calling convention testsAlex Bradbury2019-02-193-213/+633
| | | | | | | | Re-organise calling convention tests to prepare for ilp32f and ilp32d hard float ABI tests. It's also clear that we need to introduce similar tests for lp64. llvm-svn: 354323
* [RISCV][NFC] Add RV64I CHECK lines to inline-asm.ll testAlex Bradbury2019-02-141-0/+31
| | | | llvm-svn: 354028
* [LegalizeTypes] Expand FNEG to bitwise op for IEEE FP typesAna Pazos2019-02-111-0/+105
| | | | | | | | | | | | | | | | | Summary: Except for custom floating point types x86_fp80 and ppc_fp128, expand Y = FNEG(X) to Y = X ^ sign mask to avoid library call. Using bitwise operation can improve code size and performance. Reviewers: efriedma Reviewed By: efriedma Subscribers: efriedma, kpn, arsenm, eli.friedman, javed.absar, rbar, johnrusso, simoncook, sabuasal, niosHD, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, asb, llvm-commits Differential Revision: https://reviews.llvm.org/D57875 llvm-svn: 353757
* [RISCV] Implement RV64D codegenAlex Bradbury2019-02-0111-0/+1483
| | | | | | | | | | | | This patch: * Adds necessary RV64D codegen patterns * Modifies CC_RISCV so it will properly handle f64 types (with soft float ABI) Note that in general there is no reason to try to select fcvt.w[u].d rather than fcvt.l[u].d for i32 conversions because fptosi/fptoui produce poison if the input won't fit into the target type. Differential Revision: https://reviews.llvm.org/D53237 llvm-svn: 352833
* [SelectionDAG] Support promotion of the FPOWI integer operandAlex Bradbury2019-02-011-0/+218
| | | | | | | | | | | | | | For targets where i32 is not a legal type (e.g. 64-bit RISC-V), LegalizeIntegerTypes must promote the integer operand of ISD::FPOWI. As this is a signed value, this should be sign-extended. This patch enables all tests in test/CodeGen/RISCVfloat-intrinsics.ll for RV64, as prior to this patch that file couldn't be compiled for RV64 due to an assertion when performing codegen for fpowi. Differential Revision: https://reviews.llvm.org/D54574 llvm-svn: 352832
* [RISCV] Add RV64F codegen supportAlex Bradbury2019-01-3110-0/+1336
| | | | | | | | | | | | | This requires a little extra work due tothe fact i32 is not a legal type. When call lowering happens post-legalisation (e.g. when an intrinsic was inserted during legalisation). A bitcast from f32 to i32 can't be introduced. This is similar to the challenges with RV32D. To handle this, we introduce target-specific DAG nodes that perform bitcast+anyext for f32->i64 and trunc+bitcast for i64->f32. Differential Revision: https://reviews.llvm.org/D53235 llvm-svn: 352807
* [RISCV] Add target DAG combine for bitcast fabs/fneg on RV32FDAlex Bradbury2019-01-253-39/+33
| | | | | | | | | | | | | DAGCombiner::visitBITCAST will perform: fold (bitconvert (fneg x)) -> (xor (bitconvert x), signbit) fold (bitconvert (fabs x)) -> (and (bitconvert x), (not signbit)) As shown in double-bitmanip-dagcombines.ll, this can be advantageous. But RV32FD doesn't use bitcast directly (as i64 isn't a legal type), and instead uses RISCVISD::SplitF64. This patch adds an equivalent DAG combine for SplitF64. llvm-svn: 352247
* [RISCV] Add another potential combine to {double,float}-bitmanip-dagcombines.llAlex Bradbury2019-01-252-1/+103
| | | | | | | | (fcopysign a, (fneg b)) will be expanded to bitwise operations by DAGTypeLegalizer::SoftenFloatRes_FCOPYSIGN if the floating point type isn't legal. Arguably it might be worth doing a combine even if it is legal. llvm-svn: 352240
* Reapply: [RISCV] Set isAsCheapAsAMove for ADDI, ORI, XORI, LUIAna Pazos2019-01-259-2139/+1584
| | | | | | This reapplies commit r352010 with RISC-V test fixes. llvm-svn: 352237
* [RISCV][NFC] s/f32/f64 in double-arith.llAlex Bradbury2019-01-251-11/+11
| | | | | | | The intrinsic names erroneously used the .f32 variant. As the return and argument types were still double the intrinsics calls worked properly. llvm-svn: 352211
* [RISCV] Add tests to demonstrate bitcasted fneg/fabs dagcombinesAlex Bradbury2019-01-253-25/+162
| | | | | | | | | This target-independent code won't trigger for cases such as RV32FD where custom SelectionDAG nodes are generated. These new tests demonstrate such cases. Additionally, float-arith.ll was updated so that fneg.s, fsgnjn.s, and fabs.s selection patterns are actually exercised. llvm-svn: 352199
* [RISCV] Custom-legalise i32 SDIV/UDIV/UREM on RV64MAlex Bradbury2019-01-251-16/+16
| | | | | | | | | | | | | | Follow the same custom legalisation strategy as used in D57085 for variable-length shifts (see that patch summary for more discussion). Although we may lose out on some late-stage DAG combines, I think this custom legalisation strategy is ultimately easier to reason about. There are some codegen changes in rv64m-exhaustive-w-insts.ll but they are all neutral in terms of the number of instructions. Differential Revision: https://reviews.llvm.org/D57096 llvm-svn: 352171
* [RISCV] Custom-legalise 32-bit variable shifts on RV64Alex Bradbury2019-01-253-268/+261
| | | | | | | | | | | | | | | | | | | | | | | | | The previous DAG combiner-based approach had an issue with infinite loops between the target-dependent and target-independent combiner logic (see PR40333). Although this was worked around in rL351806, the combiner-based approach is still potentially brittle and can fail to select the 32-bit shift variant when profitable to do so, as demonstrated in the pr40333.ll test case. This patch instead introduces target-specific SelectionDAG nodes for SHLW/SRLW/SRAW and custom-lowers variable i32 shifts to them. pr40333.ll is a good example of how this approach can improve codegen. This adds DAG combine that does SimplifyDemandedBits on the operands (only lower 32-bits of first operand and lower 5 bits of second operand are read). This seems better than implementing SimplifyDemandedBitsForTargetNode as there is no guarantee that would be called (and it's not for e.g. the anyext return test cases). Also implements ComputeNumSignBitsForTargetNode. There are codegen changes in atomic-rmw.ll and atomic-cmpxchg.ll but the new instruction sequences are semantically equivalent. Differential Revision: https://reviews.llvm.org/D57085 llvm-svn: 352169
* [RISCV] Quick fix for PR40333Alex Bradbury2019-01-221-0/+27
| | | | | | | | | | | | | | Avoid the infinite loop caused by the target DAG combine converting ANYEXT to SIGNEXT and the target-independent DAG combine logic converting back to ANYEXT. Do this by not adding the new node to the worklist. Committing directly as this definitely doesn't make the problem any worse, and I intend to follow-up with a patch that avoids this custom combiner logic altogether and just lowers the i32 operations to a target-specific SelectionDAG node. This should be easier to reason about and improve codegen quality in some cases (though may miss out on some later DAG combines). llvm-svn: 351806
* [RISCV] Add codegen support for RV64AAlex Bradbury2019-01-173-0/+3911
| | | | | | | | | | | | | | | | | | | | | In order to support codegen RV64A, this patch: * Introduces masked atomics intrinsics for atomicrmw operations and cmpxchg that use the i64 type. These are ultimately lowered to masked operations using lr.w/sc.w, but we need to use these alternate intrinsics for RV64 because i32 is not legal * Modifies RISCVExpandPseudoInsts.cpp to handle PseudoAtomicLoadNand64 and PseudoCmpXchg64 * Modifies the AtomicExpandPass hooks in RISCVTargetLowering to sext/trunc as needed for RV64 and to select the i64 intrinsic IDs when necessary * Adds appropriate patterns to RISCVInstrInfoA.td * Updates test/CodeGen/RISCV/atomic-*.ll to show RV64A support This ends up being a fairly mechanical change, as the logic for RV32A is effectively reused. Differential Revision: https://reviews.llvm.org/D53233 llvm-svn: 351422
* Replace "no-frame-pointer-*" function attributes with "frame-pointer"Francis Visoiu Mistrih2019-01-144-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Part of the effort to refactoring frame pointer code generation. We used to use two function attributes "no-frame-pointer-elim" and "no-frame-pointer-elim-non-leaf" to represent three kinds of frame pointer usage: (all) frames use frame pointer, (non-leaf) frames use frame pointer, (none) frame use frame pointer. This CL makes the idea explicit by using only one enum function attribute "frame-pointer" Option "-frame-pointer=" replaces "-disable-fp-elim" for tools such as llc. "no-frame-pointer-elim" and "no-frame-pointer-elim-non-leaf" are still supported for easy migration to "frame-pointer". tests are mostly updated with // replace command line args ‘-disable-fp-elim=false’ with ‘-frame-pointer=none’ grep -iIrnl '\-disable-fp-elim=false' * | xargs sed -i '' -e "s/-disable-fp-elim=false/-frame-pointer=none/g" // replace command line args ‘-disable-fp-elim’ with ‘-frame-pointer=all’ grep -iIrnl '\-disable-fp-elim' * | xargs sed -i '' -e "s/-disable-fp-elim/-frame-pointer=all/g" Patch by Yuanfang Chen (tabloid.adroit)! Differential Revision: https://reviews.llvm.org/D56351 llvm-svn: 351049
* [RISCV] Introduce codegen patterns for RV64M-only instructionsAlex Bradbury2019-01-124-4/+1729
| | | | | | | | | | | | | | | | | | As discussed on llvm-dev <http://lists.llvm.org/pipermail/llvm-dev/2018-December/128497.html>, we have to be careful when trying to select the *w RV64M instructions. i32 is not a legal type for RV64 in the RISC-V backend, so operations have been promoted by the time they reach instruction selection. Information about whether the operation was originally a 32-bit operations has been lost, and it's easy to write incorrect patterns. Similarly to the variable 32-bit shifts, a DAG combine on ANY_EXTEND will produce a SIGN_EXTEND if this is likely to result in sdiv/udiv/urem being selected (and so save instructions to sext/zext the input operands). Differential Revision: https://reviews.llvm.org/D53230 llvm-svn: 350993
* [RISCV] Add patterns for RV64I SLLW/SRLW/SRAW instructionsAlex Bradbury2019-01-123-184/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | | This restores support for selecting the SLLW/SRLW/SRAW instructions, which was removed in rL348067 as the previous patterns made some unsafe assumptions. Also see the related llvm-dev discussion <http://lists.llvm.org/pipermail/llvm-dev/2018-December/128497.html> Ultimately I didn't introduce a custom SelectionDAG node, but instead added a DAG combine that inserts an AssertZext i5 on the shift amount for an i32 variable-length shift and also added an ANY_EXTEND DAG-combine which will instead produce a SIGN_EXTEND for an i32 variable-length shift, increasing the opportunity to safely select SLLW/SRLW/SRAW. There are obviously different ways of addressing this (a number discussed in the llvm-dev thread), so I'd welcome further feedback and comments. Note that there are now some cases in test/CodeGen/RISCV/rv64i-exhaustive-w-insts.ll where sraw/srlw/sllw is selected even though sra/srl/sll could be used without any extra instructions. Given both are semantically equivalent, there doesn't seem a good reason to prefer one vs the other. Given that would require more logic to still select sra/srl/sll in those cases, I've left it preferring the *w variants. Differential Revision: https://reviews.llvm.org/D56264 llvm-svn: 350992
* [RISCV][NFC] Add CHECK lines for atomic operations on RV64IAlex Bradbury2019-01-114-0/+5770
| | | | | | | As or RV32I, we include these for completeness. Committing now to make it easier to review the RV64A patch. llvm-svn: 350962
* [RISCV] Add support for the various RISC-V FMA instruction variantsAlex Bradbury2018-12-135-89/+339
| | | | | | | | | | | | | | | | | | | | | | | | | | | Adds support for the various RISC-V FMA instructions (fmadd, fmsub, fnmsub, fnmadd). The criteria for choosing whether a fused add or subtract is used, as well as whether the product is negated or not, is whether some of the arguments to the llvm.fma.* intrinsic are negated or not. In the tests, extraneous fadd instructions were added to avoid the negation being performed using a xor trick, which prevented the proper FMA forms from being selected and thus tested. The FMA instruction patterns might seem incorrect (e.g., fnmadd: -rs1 * rs2 - rs3), but they should be correct. The misleading names were inherited from MIPS, where the negation happens after computing the sum. The llvm.fmuladd.* intrinsics still do not generate RISC-V FMA instructions, as that depends on TargetLowering::isFMAFasterthanFMulAndFAdd. Some comments in the test files about what type of instructions are there tested were updated, to better reflect the current content of those test files. Differential Revision: https://reviews.llvm.org/D54205 Patch by Luís Marques. llvm-svn: 349023
* [RISCV] Remove RV64I SLLW/SRLW/SRAW patterns and add new test casesAlex Bradbury2018-12-014-62/+197
| | | | | | | | | | | | | | | | | | | | | | | | | | | As noted by Eli Friedman <https://reviews.llvm.org/D52977?id=168629#1315291>, the RV64I shift patterns for SLLW/SRLW/SRAW make some incorrect assumptions. SRAW assumed that (sext_inreg foo, i32) could only be produced when sign-extended an i32. However, it can be produced by input such as: define i64 @tricky_ashr(i64 %a, i64 %b) { %1 = shl i64 %a, 32 %2 = ashr i64 %1, 32 %3 = ashr i64 %2, %b ret i64 %3 } It's important not to select sraw in the above case, because sraw only uses bits lower 5 bits from the shift, while a shift of 32-63 would be valid. Similarly, the patterns for srlw assumed (and foo, 0xffffffff) would only be produced when zero-extending a value that was originally i32 in LLVM IR. This is obviously incorrect. This patch removes the SLLW/SRLW/SRAW shift patterns for the time being and adds test cases that would demonstrate a miscompile if the incorrect patterns were re-added. llvm-svn: 348067
* [SelectionDAG] Support result type promotion for FLT_ROUNDS_Alex Bradbury2018-11-301-0/+21
| | | | | | | | | For targets where i32 is not a legal type (e.g. 64-bit RISC-V), LegalizeIntegerTypes must promote the result of ISD::FLT_ROUNDS_. Differential Revision: https://reviews.llvm.org/D53820 llvm-svn: 347986
* [SelectionDAG] Support promotion of PREFETCH operandsAlex Bradbury2018-11-301-0/+19
| | | | | | | | | For targets where i32 is not a legal type (e.g. 64-bit RISC-V), LegalizeIntegerTypes must promote the operands of ISD::PREFETCH. Differential Revision: https://reviews.llvm.org/D53281 llvm-svn: 347980
* [SelectionDAG] Support promotion of FRAMEADDR/RETURNADDR operandsAlex Bradbury2018-11-301-0/+62
| | | | | | | | | For targets where i32 is not a legal type (e.g. 64-bit RISC-V), LegalizeIntegerTypes must promote the operand. Differential Revision: https://reviews.llvm.org/D53279 llvm-svn: 347978
* [TargetLowering][RISCV] Introduce isSExtCheaperThanZExt hook and implement ↵Alex Bradbury2018-11-301-6/+3
| | | | | | | | | | | | | | | for RISC-V DAGTypeLegalizer::PromoteSetCCOperands currently prefers to zero-extend operands when it is able to do so. For some targets this is more expensive than a sign-extension, which is also a valid choice. Introduce the isSExtCheaperThanZExt hook and use it in the new SExtOrZExtPromotedInteger helper. On RISC-V, we prefer sign-extension for FromTy == MVT::i32 and ToTy == MVT::i64, as it can be performed using a single instruction. Differential Revision: https://reviews.llvm.org/D52978 llvm-svn: 347977
* [RISCV] Introduce codegen patterns for instructions introduced in RV64IAlex Bradbury2018-11-307-4/+2906
| | | | | | | | | | | | | | | | | | | | | | | | | | | As discussed in the RFC <http://lists.llvm.org/pipermail/llvm-dev/2018-October/126690.html>, 64-bit RISC-V has i64 as the only legal integer type. This patch introduces patterns to support codegen of the new instructions introduced in RV64I: addiw, addiw, subw, sllw, slliw, srlw, srliw, sraw, sraiw, ld, sd. Custom selection code is needed for srliw as SimplifyDemandedBits will remove lower bits from the mask, meaning the obvious pattern won't work: def : Pat<(sext_inreg (srl (and GPR:$rs1, 0xffffffff), uimm5:$shamt), i32), (SRLIW GPR:$rs1, uimm5:$shamt)>; This is sufficient to compile and execute all of the GCC torture suite for RV64I other than those files using frameaddr or returnaddr intrinsics (LegalizeDAG doesn't know how to promote the operands - a future patch addresses this). When promoting i32 sltu/sltiu operands, it would be more efficient to use sign-extension rather than zero-extension for RV64. A future patch adds a hook to allow this. Differential Revision: https://reviews.llvm.org/D52977 llvm-svn: 347973
* [RISCV] Implement codegen for cmpxchg on RV32IAAlex Bradbury2018-11-291-0/+769
| | | | | | | | | | | | | Utilise a similar ('late') lowering strategy to D47882. The changes to AtomicExpandPass allow this strategy to be utilised by other targets which implement shouldExpandAtomicCmpXchgInIR. All cmpxchg are lowered as 'strong' currently and failure ordering is ignored. This is conservative but correct. Differential Revision: https://reviews.llvm.org/D48131 llvm-svn: 347914
* [RISCV] Constant materialisation for RV64IAlex Bradbury2018-11-161-7/+204
| | | | | | | | | | | | | | | | | | | | | | | This commit introduces support for materialising 64-bit constants for RV64I, making use of the RISCVMatInt::generateInstSeq helper in order to share logic for immediate materialisation with the MC layer (where it's used for the li pseudoinstruction). test/CodeGen/RISCV/imm.ll is updated to test RV64, and gains new 64-bit constant tests. It would be preferable if anyext constant returns were sign rather than zero extended (see PR39092). This patch simply adds an explicit signext to the returns in imm.ll. Further optimisations for constant materialisation are possible, most notably for mask-like values which can be generated my loading -1 and shifting right. A future patch will standardise on the C++ codepath for immediate selection on RV32 as well as RV64, and then add further such optimisations to RISCVMatInt::generateInstSeq in order to benefit both RV32 and RV64 for codegen and li expansion. Differential Revision: https://reviews.llvm.org/D52962 llvm-svn: 347042
* [RISCV] Mark FREM as ExpandAlex Bradbury2018-11-152-0/+32
| | | | | | | | | | | | Mark the FREM SelectionDAG node as Expand, which is necessary in order to support the frem IR instruction on RISC-V. This is expanded into a library call. Adds the corresponding test. Previously, this would have triggered an assertion at instruction selection time. Differential Revision: https://reviews.llvm.org/D54159 Patch by Luís Marques. llvm-svn: 346958
* [RISCV] Support .option relax and .option norelaxAlex Bradbury2018-11-123-0/+52
| | | | | | | | | | | | | | | | | | | | | | This extends the .option support from D45864 to enable/disable the relax feature flag from D44886 During parsing of the relax/norelax directives, the RISCV::FeatureRelax feature bits of the SubtargetInfo stored in the AsmParser are updated appropriately to reflect whether relaxation is currently enabled in the parser. When an instruction is parsed, the parser checks if relaxation is currently enabled and if so, gets a handle to the AsmBackend and sets the ForceRelocs flag. The AsmBackend uses a combination of the original RISCV::FeatureRelax feature bits set by e.g -mattr=+/-relax and the ForceRelocs flag to determine whether to emit relocations for symbol and branch diffs. Diff relocations should therefore only not be emitted if the relax flag was not set on the command line and no instruction was ever parsed in a section with relaxation enabled to ensure correct diffs are emitted. Differential Revision: https://reviews.llvm.org/D46423 Patch by Lewis Revill. llvm-svn: 346655
* [RISCV] Avoid unnecessary XOR for seteq/setne 0Alex Bradbury2018-11-095-115/+114
| | | | | | | | Differential Revision: https://reviews.llvm.org/D53492 Patch by James Clarke. llvm-svn: 346497
* [RISCV] Update test/CodeGen/RISCV/calling-conv.ll after rL346432Alex Bradbury2018-11-091-8/+8
| | | | | | The DAGCombiner changes led to a different schedule. llvm-svn: 346496
* [RISCV] Add some missing expansions for floating-point intrinsicsAlex Bradbury2018-11-022-7/+750
| | | | | | | | | | | | | | | | | | A number of intrinsics, such as llvm.sin.f32, would result in a failure to select. This patch adds expansions for the relevant selection DAG nodes, as well as exhaustive testing for all f32 and f64 intrinsics. The codegen for FMA remains a TODO item, pending support for the various RISC-V FMA instruction variants. The llvm.minimum.f32.* and llvm.maximum.* tests are commented-out, pending upstream support for target-independent expansion, as discussed in http://lists.llvm.org/pipermail/llvm-dev/2018-November/127408.html. Differential Revision: https://reviews.llvm.org/D54034 Patch by Luís Marques. llvm-svn: 346034
* [RISCV] Eliminate unnecessary masking of promoted shift amountsAlex Bradbury2018-10-123-14/+70
| | | | | | | | | | | | | | | | SelectionDAGBuilder::visitShift will always zero-extend a shift amount when it is promoted to the ShiftAmountTy. This results in zero-extension (masking) which is unnecessary for RISC-V as the shift operations only read the lower 5 or 6 bits (RV32 or RV64). I initially proposed adding a getExtendForShiftAmount hook so the shift amount can be any-extended (D52975). @efriedma explained this was unsafe, so I have instead eliminate the unnecessary and operations at instruction selection time in a manner similar to X86InstrCompiler.td. Differential Revision: https://reviews.llvm.org/D53224 llvm-svn: 344432
* [RISCV] Re-generate test/CodeGen/RISCV/vararg.ll after r344142Alex Bradbury2018-10-111-34/+32
| | | | | | The improved load-store forwarding committed in r344142 broke this test. llvm-svn: 344238
* [RISCV] Update alu8.ll and alu16.ll test casesAlex Bradbury2018-10-082-5/+9
| | | | | | | | The srli test in alu8.ll was a no-op, as it shifted by 8 bits. Fix this, and also change the immediate in alu16.ll as shifted by something other than a poewr of 8 is more interesting. llvm-svn: 343958
* [RISCV] Introduce alu8.ll and alu16.ll testsAlex Bradbury2018-10-072-0/+412
| | | | | | | These track the quality of generated code for simple arithmetic operations that were legalised from non-native types. llvm-svn: 343930
* [RISCV] Regenerate several tests now enableMultipleCopyHints is enabled by ↵Alex Bradbury2018-10-053-60/+60
| | | | | | | | default r343851 caused codegen changes in several tests. This patch regenerates them. llvm-svn: 343873
* [RISCV][NFC] Remove dead CHECK lines from vararg.ll testAlex Bradbury2018-10-041-310/+0
| | | | | | The RISCV32 check prefix is no longer used so these lines are dead. llvm-svn: 343757
* [RISCV] Bugfix for floats passed on the stack with the ILP32 ABI on RV32FAlex Bradbury2018-10-041-0/+81
| | | | | | | | | | | | | f32 values passed on the stack would previously cause an assertion in unpackFromMemLoc.. This would only trigger in the presence of the F extension making f32 a legal type. Otherwise the f32 would be legalized. This patch fixes that by keeping LocVT=f32 when a float is passed on the stack. It also adds test coverage for this case, and tests that also demonstrate lw/sw/flw/fsw will be selected when most profitable. i.e. there is no unnecessary i32<->f32 conversion in registers. llvm-svn: 343756
* [RISCV] Remove RV64 test lines from umulo-128-legalisation-lowering.llAlex Bradbury2018-10-031-29/+0
| | | | | | | The generated code is incorrect anyway, and this test adds noise to the upcoming set of patches that flesh out RV64 support. llvm-svn: 343675
* [RISCV] Codegen for i8, i16, and i32 atomicrmw with RV32AAlex Bradbury2018-09-191-0/+4282
| | | | | | | | | | | | | | | | | | | | Introduce a new RISCVExpandPseudoInsts pass to expand atomic pseudo-instructions after register allocation. This is necessary in order to ensure that register spills aren't introduced between LL and SC, thus breaking the forward progress guarantee for the operation. AArch64 does something similar for CmpXchg (though only at O0), and Mips is moving towards this approach (see D31287). See also [this mailing list post](http://lists.llvm.org/pipermail/llvm-dev/2016-May/099490.html) from James Knight, which summarises the issues with lowering to ll/sc in IR or pre-RA. See the [accompanying RFC thread](http://lists.llvm.org/pipermail/llvm-dev/2018-June/123993.html) for an overview of the lowering strategy. Differential Revision: https://reviews.llvm.org/D47882 llvm-svn: 342534
* [RISCV] atomic_store_nn have a different layout to regular storeRoger Ferrer Ibanez2018-08-271-12/+12
| | | | | | | | | | | We cannot directy reuse the patterns of StPat because for some reason the store DAG node and the atomic_store_nn DAG nodes put the ptr and the value in different positions. Currently we attempt to store the address to an address formed by the value. Differential Revision: https://reviews.llvm.org/D51217 llvm-svn: 340722
* [SelectionDAG] Improve the legalisation lowering of UMULO.Eli Friedman2018-08-161-0/+175
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is no way in the universe, that doing a full-width division in software will be faster than doing overflowing multiplication in software in the first place, especially given that this same full-width multiplication needs to be done anyway. This patch replaces the previous implementation with a direct lowering into an overflowing multiplication algorithm based on half-width operations. Correctness of the algorithm was verified by exhaustively checking the output of this algorithm for overflowing multiplication of 16 bit integers against an obviously correct widening multiplication. Baring any oversights introduced by porting the algorithm to DAG, confidence in correctness of this algorithm is extremely high. Following table shows the change in both t = runtime and s = space. The change is expressed as a multiplier of original, so anything under 1 is “better” and anything above 1 is worse. +-------+-----------+-----------+-------------+-------------+ | Arch | u64*u64 t | u64*u64 s | u128*u128 t | u128*u128 s | +-------+-----------+-----------+-------------+-------------+ | X64 | - | - | ~0.5 | ~0.64 | | i686 | ~0.5 | ~0.6666 | ~0.05 | ~0.9 | | armv7 | - | ~0.75 | - | ~1.4 | +-------+-----------+-----------+-------------+-------------+ Performance numbers have been collected by running overflowing multiplication in a loop under `perf` on two x86_64 (one Intel Haswell, other AMD Ryzen) based machines. Size numbers have been collected by looking at the size of function containing an overflowing multiply in a loop. All in all, it can be seen that both performance and size has improved except in the case of armv7 where code size has regressed for 128-bit multiply. u128*u128 overflowing multiply on 32-bit platforms seem to benefit from this change a lot, taking only 5% of the time compared to original algorithm to calculate the same thing. The final benefit of this change is that LLVM is now capable of lowering the overflowing unsigned multiply for integers of any bit-width as long as the target is capable of lowering regular multiplication for the same bit-width. Previously, 128-bit overflowing multiply was the widest possible. Patch by Simonas Kazlauskas! Differential Revision: https://reviews.llvm.org/D50310 llvm-svn: 339922
* [RISCV][MC] Don't fold symbol differences if ↵Alex Bradbury2018-08-161-0/+46
| | | | | | | | | | | | | | | | | | | | | | requiresDiffExpressionRelocations is true When emitting the difference between two symbols, the standard behavior is that the difference will be resolved to an absolute value if both of the symbols are offsets from the same data fragment. This is undesirable on architectures such as RISC-V where relaxation in the linker may cause the computed difference to become invalid. This caused an issue when compiling to object code, where the size of a function in the debug information was already calculated even though it could change as a consequence of relaxation in the subsequent linking stage. This patch inhibits the resolution of symbol differences to absolute values where the target's AsmBackend has declared that it does not want these to be folded. Differential Revision: https://reviews.llvm.org/D45773 Patch by Edward Jones. llvm-svn: 339864
* [RISCV] Fixed test case failure due to r338047Ana Pazos2018-07-311-1/+1
| | | | llvm-svn: 338341
* [RISCV] Add support for _interrupt attributeAna Pazos2018-07-265-0/+1317
| | | | | | | | | | | | | | | | | | | | | - Save/restore only registers that are used. This includes Callee saved registers and Caller saved registers (arguments and temporaries) for integer and FP registers. - If there is a call in the interrupt handler, save/restore all Caller saved registers (arguments and temporaries) and all FP registers. - Emit special return instructions depending on "interrupt" attribute type. Based on initial patch by Zhaoshi Zheng. Reviewers: asb Reviewed By: asb Subscribers: rkruppe, the_o, MartinMosbeck, brucehoult, rbar, johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones, mgrang, rogfer01, llvm-commits Differential Revision: https://reviews.llvm.org/D48411 llvm-svn: 338047
* [RISCV] Add machine function pass to merge base + offsetSameer AbuAsal2018-06-271-37/+38
| | | | | | | | | | | | | | | | | | | | | | | | Summary: In r333455 we added a peephole to fix the corner cases that result from separating base + offset lowering of global address.The peephole didn't handle some of the cases because it only has a basic block view instead of a function level view. This patch replaces that logic with a machine function pass. In addition to handling the original cases it handles uses of the global address across blocks in function and folding an offset from LW\SW instruction. This pass won't run for OptNone compilation, so there will be a negative impact overall vs the old approach at O0. Reviewers: asb, apazos, mgrang Reviewed By: asb Subscribers: MartinMosbeck, brucehoult, the_o, rogfer01, mgorny, rbar, johnrusso, simoncook, niosHD, kito-cheng, shiva0217, zzheng, llvm-commits, edward-jones Differential Revision: https://reviews.llvm.org/D47857 llvm-svn: 335786
* [RISC-V] Fix a test case to not include label names as those aren'tChandler Carruth2018-06-211-2/+2
| | | | | | | stable in non-asserts builds. This fixes a test failure in release config. llvm-svn: 335202
* [RISCV] Add tests for overflow intrinsicsRoger Ferrer Ibanez2018-06-191-0/+84
| | | | | | | This is using the existing codegen so we can see the change once we custom lower ISD::{U,S}{ADD,SUB}O nodes. llvm-svn: 335023
OpenPOWER on IntegriCloud