summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
...
* [CodeGen] Don't scavenge non-saved regs in exception throwing functionsOliver Stannard2019-02-011-7/+9
| | | | | | | | | | | | | | | | Previously, LiveRegUnits was assuming that if a block has no successors and does not return, then no registers are live at the end of it (because the end of the block is unreachable). This was causing the register scavenger to use callee-saved registers to materialise stack frame addresses without saving them in the prologue. This would normally be fine, because the end of the block is unreachable, but this is not legal if the block ends by throwing a C++ exception. If this happens, the scratch register will be modified, but its previous value won't be preserved, so it doesn't get restored by the exception unwinder. Differential revision: https://reviews.llvm.org/D57381 llvm-svn: 352844
* [SelectionDAG] Support promotion of the FPOWI integer operandAlex Bradbury2019-02-012-0/+8
| | | | | | | | | | | | | | 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
* [opaque pointer types] Add a FunctionCallee wrapper type, and use it.James Y Knight2019-02-0111-136/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc doesn't choke on it, hopefully. Original Message: The FunctionCallee type is effectively a {FunctionType*,Value*} pair, and is a useful convenience to enable code to continue passing the result of getOrInsertFunction() through to EmitCall, even once pointer types lose their pointee-type. Then: - update the CallInst/InvokeInst instruction creation functions to take a Callee, - modify getOrInsertFunction to return FunctionCallee, and - update all callers appropriately. One area of particular note is the change to the sanitizer code. Previously, they had been casting the result of `getOrInsertFunction` to a `Function*` via `checkSanitizerInterfaceFunction`, and storing that. That would report an error if someone had already inserted a function declaraction with a mismatching signature. However, in general, LLVM allows for such mismatches, as `getOrInsertFunction` will automatically insert a bitcast if needed. As part of this cleanup, cause the sanitizer code to do the same. (It will call its functions using the expected signature, however they may have been declared.) Finally, in a small number of locations, callers of `getOrInsertFunction` actually were expecting/requiring that a brand new function was being created. In such cases, I've switched them to Function::Create instead. Differential Revision: https://reviews.llvm.org/D57315 llvm-svn: 352827
* GlobalISel: Fix MMO creation with non-power-of-2 mem sizeMatt Arsenault2019-01-311-4/+5
| | | | | | | It should probably just be mandatory for getTgtMemIntrinsic to return the alignment. llvm-svn: 352817
* Revert "[opaque pointer types] Add a FunctionCallee wrapper type, and use it."James Y Knight2019-01-3111-36/+136
| | | | | | | | | This reverts commit f47d6b38c7a61d50db4566b02719de05492dcef1 (r352791). Seems to run into compilation failures with GCC (but not clang, where I tested it). Reverting while I investigate. llvm-svn: 352800
* [DAGCombine] Avoid CombineZExtLogicopShiftLoad if there is free ZEXTGuozhi Wei2019-01-311-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes pr39098. For the attached test case, CombineZExtLogicopShiftLoad can optimize it to t25: i64 = Constant<1099511627775> t35: i64 = Constant<0> t0: ch = EntryToken t57: i64,ch = load<(load 4 from `i40* undef`, align 8), zext from i32> t0, undef:i64, undef:i64 t58: i64 = srl t57, Constant:i8<1> t60: i64 = and t58, Constant:i64<524287> t29: ch = store<(store 5 into `i40* undef`, align 8), trunc to i40> t57:1, t60, undef:i64, undef:i64 But later visitANDLike transforms it to t25: i64 = Constant<1099511627775> t35: i64 = Constant<0> t0: ch = EntryToken t57: i64,ch = load<(load 4 from `i40* undef`, align 8), zext from i32> t0, undef:i64, undef:i64 t61: i32 = truncate t57 t63: i32 = srl t61, Constant:i8<1> t64: i32 = and t63, Constant:i32<524287> t65: i64 = zero_extend t64 t58: i64 = srl t57, Constant:i8<1> t60: i64 = and t58, Constant:i64<524287> t29: ch = store<(store 5 into `i40* undef`, align 8), trunc to i40> t57:1, t60, undef:i64, undef:i64 And it triggers CombineZExtLogicopShiftLoad again, causes a dead loop. Both forms should generate same instructions, CombineZExtLogicopShiftLoad generated IR looks cleaner. But it looks more difficult to prevent visitANDLike to do the transform, so I prevent CombineZExtLogicopShiftLoad to do the transform if the ZExt is free. Differential Revision: https://reviews.llvm.org/D57491 llvm-svn: 352792
* [opaque pointer types] Add a FunctionCallee wrapper type, and use it.James Y Knight2019-01-3111-136/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The FunctionCallee type is effectively a {FunctionType*,Value*} pair, and is a useful convenience to enable code to continue passing the result of getOrInsertFunction() through to EmitCall, even once pointer types lose their pointee-type. Then: - update the CallInst/InvokeInst instruction creation functions to take a Callee, - modify getOrInsertFunction to return FunctionCallee, and - update all callers appropriately. One area of particular note is the change to the sanitizer code. Previously, they had been casting the result of `getOrInsertFunction` to a `Function*` via `checkSanitizerInterfaceFunction`, and storing that. That would report an error if someone had already inserted a function declaraction with a mismatching signature. However, in general, LLVM allows for such mismatches, as `getOrInsertFunction` will automatically insert a bitcast if needed. As part of this cleanup, cause the sanitizer code to do the same. (It will call its functions using the expected signature, however they may have been declared.) Finally, in a small number of locations, callers of `getOrInsertFunction` actually were expecting/requiring that a brand new function was being created. In such cases, I've switched them to Function::Create instead. Differential Revision: https://reviews.llvm.org/D57315 llvm-svn: 352791
* [DAG] Aggressively cleanup dangling node in CombineZExtLogicopShiftLoad.Nirav Dave2019-01-311-0/+4
| | | | | | | | | | | | | While dangling nodes will eventually be pruned when they are considered, leaving them disables combines requiring single-use. Reviewers: Carrot, spatel, craig.topper, RKSimon, efriedma Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D57520 llvm-svn: 352784
* [Intrinsic] Expand SMULFIX to MUL, MULH[US], or [US]MUL_LOHI on vector argumentsLeonard Chan2019-01-312-14/+21
| | | | | | | | | | | r zero scale SMULFIX, expand into MUL which produces better code for X86. For vector arguments, expand into MUL if SMULFIX is provided with a zero scale. Otherwise, expand into MULH[US] or [US]MUL_LOHI. Differential Revision: https://reviews.llvm.org/D56987 llvm-svn: 352783
* Lower widenable_conditions in CGPPhilip Reames2019-01-311-0/+14
| | | | | | | | This ensures that if we make it to the backend w/o lowering widenable_conditions first, that we generate correct code. Doing it in CGP - instead of isel - let's us fold control flow before hitting block local instruction selection. Differential Revision: https://reviews.llvm.org/D57473 llvm-svn: 352779
* [SelectionDAG] Codesize: don't expand SHIFT to SHIFT_PARTSSjoerd Meijer2019-01-311-3/+7
| | | | | | | | | | | | | | | | And instead just generate a libcall. My motivating example on ARM was a simple: shl i64 %A, %B for which the code bloat is quite significant. For other targets that also accept __int128/i128 such as AArch64 and X86, it is also beneficial for these cases to generate a libcall when optimising for minsize. On these 64-bit targets, the 64-bits shifts are of course unaffected because the SHIFT/SHIFT_PARTS lowering operation action is not set to custom/expand. Differential Revision: https://reviews.llvm.org/D57386 llvm-svn: 352736
* Revert "Reapply "[CGP] Check for existing inttotpr before creating new one""David L. Jones2019-01-311-18/+4
| | | | | | | | This change reverts r351626. The changes in r351626 cause quadratic work in several cases. (See r351626 thread on llvm-commits for details.) llvm-svn: 352722
* GlobalISel: Handle odd splits in fewerElementsVector for load/storeMatt Arsenault2019-01-311-30/+173
| | | | llvm-svn: 352720
* GlobalISel: Implement narrowScalar for bswapMatt Arsenault2019-01-311-0/+25
| | | | llvm-svn: 352719
* GlobalISel: Don't call changingInstruction before giving upMatt Arsenault2019-01-311-1/+1
| | | | llvm-svn: 352718
* GlobalISel: Allow bitcount ops to have different result typeMatt Arsenault2019-01-311-4/+30
| | | | | | For AMDGPU the result is always 32-bit for 64-bit inputs. llvm-svn: 352717
* GlobalISel: Use helper function for MMO splittingMatt Arsenault2019-01-312-26/+21
| | | | | | | | Also fix an alignment bug getMachineMemOperand. If the tracked value is null, the offset isn't tracked so the base alignment needs to be reduced. llvm-svn: 352716
* GlobalISel: Fix creating MMOs with align 0Matt Arsenault2019-01-312-2/+6
| | | | llvm-svn: 352712
* [LegalizeVectorTypes] Allow illegal indices when splitting extract_vector_eltThomas Lively2019-01-311-1/+0
| | | | | | | | | | | | | | | | | Summary: Fixes PR40267, in which the removed assertion was triggering on perfectly valid IR. As far as I can tell, constant out of bounds indices should be allowed when splitting extract_vector_elt, since they will simply be propagated as out of bounds indices in the resulting split vector and handled appropriately elsewhere. Reviewers: aheejin Subscribers: dschuff, sbc100, jgravelle-google, hiraditya Differential Revision: https://reviews.llvm.org/D57471 llvm-svn: 352702
* [LegalizeTypes] Use report_fatal_error instead of llvm_unreachable in the ↵Craig Topper2019-01-311-2/+3
| | | | | | | | | | default case of some type legalization handlers that can be reached with intrinsics with result or operands that aren't legal types. These can be triggered by mistakenly using a 64-bit mode only intrinsics with a -mtriple=i686. Using report_fatal_error gives a better experience for this mistake in release builds instead of probably crashing. We already do this for some of the vector type legalization handles. llvm-svn: 352699
* [GlobalISel][AArch64] Select G_FEXPJessica Paquette2019-01-301-1/+6
| | | | | | | | | | | | | | | This teaches the legalizer to handle G_FEXP in AArch64. As a result, it also allows us to select G_FEXP. It... - Updates the legalizer-info tests - Adds a test for legalizing exp - Updates the existing fp tests to show that we can now select G_FEXP https://reviews.llvm.org/D57483 llvm-svn: 352692
* [GlobalISel][LegalizerHelper] Add some missing MI change observer calls.Amara Emerson2019-01-301-0/+2
| | | | | | No test as it's a preventative fix. llvm-svn: 352691
* MIR: Reject non-power-of-4 alignments in MMO parsingMatt Arsenault2019-01-301-0/+4
| | | | llvm-svn: 352686
* [DAGCombiner] sub X, 0/1 --> add X, 0/-1Sanjay Patel2019-01-301-10/+22
| | | | | | | | | | This extends the existing transform for: add X, 0/1 --> sub X, 0/-1 ...to allow the sibling subtraction fold. This pattern could regress with the proposed change in D57401. llvm-svn: 352680
* [GlobalISel][AArch64] Add instruction selection support for @llvm.log2Jessica Paquette2019-01-301-1/+7
| | | | | | | | | | | | | This teaches GlobalISel to emit a RTLib call for @llvm.log2 when it encounters it. It updates the existing floating point tests to show that we don't fall back on the intrinsic, and select the correct instructions. It also adds a legalizer test for G_FLOG2. https://reviews.llvm.org/D57357 llvm-svn: 352673
* [GlobalISel][AArch64] Add instruction selection support for @llvm.sqrtJessica Paquette2019-01-301-0/+2
| | | | | | | | | | This teaches the legalizer about G_FSQRT in AArch64. Also adds a legalizer test for G_FSQRT, a selection test for it, and updates existing floating point tests. https://reviews.llvm.org/D57361 llvm-svn: 352671
* [GlobalISel] Add IRTranslator support for @llvm.sqrt -> G_FSQRTJessica Paquette2019-01-301-0/+5
| | | | | | | | | | | Follow-up commit to https://reviews.llvm.org/D57359. (r352668) This adds IRTranslator support for recognising a @llvm.sqrt intrinsic and translating it into a G_FSQRT. https://reviews.llvm.org/D57360 llvm-svn: 352670
* Reverting r352642 - Handle restore instructions in LiveDebugValues - as it's ↵Wolfgang Pieb2019-01-303-215/+94
| | | | | | | | causing assertions on some buildbots. llvm-svn: 352666
* Add a 'dynamic' parameter to the objectsize intrinsicErik Pilkington2019-01-301-1/+1
| | | | | | | | | | | | | | This is meant to be used with clang's __builtin_dynamic_object_size. When 'true' is passed to this parameter, the intrinsic has the potential to be folded into instructions that will be evaluated at run time. When 'false', the objectsize intrinsic behaviour is unchanged. rdar://32212419 Differential revision: https://reviews.llvm.org/D56761 llvm-svn: 352664
* [DEBUGINFO] Handle restore instructions in LiveDebugValuesWolfgang Pieb2019-01-303-94/+215
| | | | | | | | | | | | | The LiveDebugValues pass recognizes spills but not restores, which can cause large gaps in location information for some variables, depending on control flow. This patch make LiveDebugValues recognize restores and generate appropriate DBG_VALUE instructions. Reviewers: aprantl, NicolaPrica Differential Revision: https://reviews.llvm.org/D57271 llvm-svn: 352642
* GlobalISel: Add assert that legalize mutation makes senseMatt Arsenault2019-01-301-1/+64
| | | | | | | | | I've repeatedly encountered bugs resulting from custom legalize mutations returning nonsense legalize results, such as increasing the number of elements for FewerElements. Add an assert function to make sure the type to mutate to is consistent with the legalize action. llvm-svn: 352636
* GlobalISel: Implement fewerElementsVector for selectMatt Arsenault2019-01-301-0/+74
| | | | llvm-svn: 352601
* [WebAssembly] Exception handling: Switch to the new proposalHeejin Ahn2019-01-303-106/+105
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This switches the EH implementation to the new proposal: https://github.com/WebAssembly/exception-handling/blob/master/proposals/Exceptions.md (The previous proposal was https://github.com/WebAssembly/exception-handling/blob/master/proposals/old/Exceptions.md) - Instruction changes - Now we have one single `catch` instruction that returns a except_ref value - `throw` now can take variable number of operations - `rethrow` does not have 'depth' argument anymore - `br_on_exn` queries an except_ref to see if it matches the tag and branches to the given label if true. - `extract_exception` is a pseudo instruction that simulates popping values from wasm stack. This is to make `br_on_exn`, a very special instruction, work: `br_on_exn` puts values onto the stack only if it is taken, and the # of values can vay depending on the tag. - Now there's only one `catch` per `try`, this patch removes all special handling for terminate pad with a call to `__clang_call_terminate`. Before it was the only case there are two catch clauses (a normal `catch` and `catch_all` per `try`). - Make `rethrow` act as a terminator like `throw`. This splits BB after `rethrow` in WasmEHPrepare, and deletes an unnecessary `unreachable` after `rethrow` in LateEHPrepare. - Now we stop at all catchpads (because we add wasm `catch` instruction that catches all exceptions), this creates new `findWasmUnwindDestinations` function in SelectionDAGBuilder. - Now we use `br_on_exn` instrution to figure out if an except_ref matches the current tag or not, LateEHPrepare generates this sequence for catch pads: ``` catch block i32 br_on_exn $__cpp_exception end_block extract_exception ``` - Branch analysis for `br_on_exn` in WebAssemblyInstrInfo - Other various misc. changes to switch to the new proposal. Reviewers: dschuff Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D57134 llvm-svn: 352598
* GlobalISel: Use appropriate extension for legalizing select conditionsMatt Arsenault2019-01-302-1/+22
| | | | llvm-svn: 352597
* GlobalISel: Support narrowScalar for uneven loadsMatt Arsenault2019-01-301-11/+40
| | | | llvm-svn: 352594
* GlobalISel: Handle some odd splits in fewerElementsVectorMatt Arsenault2019-01-301-10/+55
| | | | | | Also add some quick hacks to AMDGPU legality for the tests. llvm-svn: 352591
* GlobalISel: Handle more cases for widenScalar for G_STOREMatt Arsenault2019-01-301-3/+10
| | | | llvm-svn: 352585
* GlobalISel: Verify memory size for load/storeMatt Arsenault2019-01-301-4/+9
| | | | llvm-svn: 352578
* GlobalISel: Fix unused variable warning in release buildsMatt Arsenault2019-01-291-2/+1
| | | | llvm-svn: 352565
* GlobalISel: Verify pointer castsMatt Arsenault2019-01-291-0/+44
| | | | | | | Not sure if the old AArch64 tests should be just deleted or not. llvm-svn: 352562
* GlobalISel: Partially implement widenScalar for MERGE_VALUESMatt Arsenault2019-01-291-0/+40
| | | | llvm-svn: 352560
* [DAGCombiner] fold extract_subvector of extract_subvectorSanjay Patel2019-01-291-0/+13
| | | | | | | | | | | | | | | This is the sibling fold for insert-of-insert that was added with D56604. Now that we have x86 shuffle narrowing (D57156), this change shows improvements for lots of AVX512 reduction code (not sure that we would ever expect extract-of-extract otherwise). There's a small regression in some of the partial-permute tests (extracting followed by splat). That is tracked by PR40500: https://bugs.llvm.org/show_bug.cgi?id=40500 Differential Revision: https://reviews.llvm.org/D57336 llvm-svn: 352528
* GlobalISel: Fix narrowScalar for load/store with different mem sizeMatt Arsenault2019-01-291-2/+27
| | | | | | | | | | This was ignoring the memory size, and producing multiple loads/stores if the operand size was different from the memory size. I assume this is the intent of not having an explicit G_ANYEXTLOAD (although I think that would probably be better). llvm-svn: 352523
* Adjust documentation for git migration.James Y Knight2019-01-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes most references to the paths: llvm.org/svn/ llvm.org/git/ llvm.org/viewvc/ github.com/llvm-mirror/ github.com/llvm-project/ reviews.llvm.org/diffusion/ to instead point to https://github.com/llvm/llvm-project. This is *not* a trivial substitution, because additionally, all the checkout instructions had to be migrated to instruct users on how to use the monorepo layout, setting LLVM_ENABLE_PROJECTS instead of checking out various projects into various subdirectories. I've attempted to not change any scripts here, only documentation. The scripts will have to be addressed separately. Additionally, I've deleted one document which appeared to be outdated and unneeded: lldb/docs/building-with-debug-llvm.txt Differential Revision: https://reviews.llvm.org/D57330 llvm-svn: 352514
* [SelectionDAGBuilder] Remove redundant variable. NFCI.Nirav Dave2019-01-291-7/+3
| | | | llvm-svn: 352506
* Reversing the checkin for version 352484 as tests are failing.Ayonam Ray2019-01-292-28/+52
| | | | llvm-svn: 352504
* [CodeGen] Omit range checks from jump tables when lowering switches with ↵Ayonam Ray2019-01-292-52/+28
| | | | | | | | | | | | | | | | | unreachable default During the lowering of a switch that would result in the generation of a jump table, a range check is performed before indexing into the jump table, for the switch value being outside the jump table range and a conditional branch is inserted to jump to the default block. In case the default block is unreachable, this conditional jump can be omitted. This patch implements omitting this conditional branch for unreachable defaults. Review ID: D52002 Reviewers: Hans Wennborg, Eli Freidman, Roman Lebedev llvm-svn: 352484
* [DebugInfo][DAG] Process FrameIndex dbg.values unconditionallyJeremy Morse2019-01-291-0/+15
| | | | | | | | | | | | | | | A FrameIndex should be valid throughout a block regardless of what instructions get selected in that block -- therefore we shouldn't harness dbg.values that refer to FrameIndexes to an SDNode. There are numerous codegen reasons why an SDNode never appears or doesn't become a location that a DBG_VALUE can refer to. None of them actually affect the variable location. Therefore, before any other tests to encode dbg_values in a SelectionDAG, identify FrameIndex operands and encode them unattached to any SDNode. Differential Revision: https://reviews.llvm.org/D57328 llvm-svn: 352467
* [CodeGenPrepare] Handle all debug calls in dupRetToEnableTailCallOpts()Jonas Paulsson2019-01-291-4/+2
| | | | | | | | | | | | This patch makes sure that a debug value that is after the bitcast in dupRetToEnableTailCallOpts() is also skipped. The reduced test case is from SPEC-2006 on SystemZ. Review: Vedant Kumar, Wolfgang Pieb https://reviews.llvm.org/D57050 llvm-svn: 352462
* Recommit r352255 "[SelectionDAG][X86] Don't use SEXTLOAD for promoting ↵Craig Topper2019-01-281-1/+1
| | | | | | | | | | | | | | | | masked loads in the type legalizer" This did not cause the buildbot failure it was previously reverted for. Original commit message: I'm not sure why we were using SEXTLOAD. EXTLOAD seems more appropriate since we don't care about the upper bits. This patch changes this and then modifies the X86 post legalization combine to emit a extending shuffle instead of a sign_extend_vector_inreg. Could maybe use an any_extend_vector_inre On AVX512 targets I think we might be able to use a masked vpmovzx and not have to expand this at all. llvm-svn: 352433
OpenPOWER on IntegriCloud