summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
* Allow inconsistent offsets for 'noreturn' basic blocks when '-verify-cfiinstrs'Vladimir Stefanovic2018-08-301-0/+4
| | | | | | | | | | | | | With r295105, some 'noreturn' blocks (those that don't return and have no successors) may be merged. If such blocks' predecessors have different outgoing offset or register, don't report an error in CFIInstrInserter verify(). Thanks to Vlad Tsyrklevich for reporting the issue. Differential Revision: https://reviews.llvm.org/D51161 llvm-svn: 341087
* [NFC] Rename the DivergenceAnalysis to LegacyDivergenceAnalysisNicolai Haehnle2018-08-302-2/+2
| | | | | | | | | | | | | | | | | | | | Summary: This is patch 1 of the new DivergenceAnalysis (https://reviews.llvm.org/D50433). The purpose of this patch is to free up the name DivergenceAnalysis for the new generic implementation. The generic implementation class will be shared by specialized divergence analysis classes. Patch by: Simon Moll Reviewed By: nhaehnle Subscribers: jvesely, jholewinski, arsenm, nhaehnle, mgorny, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D50434 Change-Id: Ie8146b11be2c50d5312f30e11c7a3036a15b48cb llvm-svn: 341071
* [CodeGen] emit inline asm clobber list warnings for reserved (cont)Ties Stuij2018-08-301-32/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a continuation of https://reviews.llvm.org/D49727 Below the original text, current changes in the comments: Currently, in line with GCC, when specifying reserved registers like sp or pc on an inline asm() clobber list, we don't always preserve the original value across the statement. And in general, overwriting reserved registers can have surprising results. For example: extern int bar(int[]); int foo(int i) { int a[i]; // VLA asm volatile( "mov r7, #1" : : : "r7" ); return 1 + bar(a); } Compiled for thumb, this gives: $ clang --target=arm-arm-none-eabi -march=armv7a -c test.c -o - -S -O1 -mthumb ... foo: .fnstart @ %bb.0: @ %entry .save {r4, r5, r6, r7, lr} push {r4, r5, r6, r7, lr} .setfp r7, sp, #12 add r7, sp, #12 .pad #4 sub sp, #4 movs r1, #7 add.w r0, r1, r0, lsl #2 bic r0, r0, #7 sub.w r0, sp, r0 mov sp, r0 @APP mov.w r7, #1 @NO_APP bl bar adds r0, #1 sub.w r4, r7, #12 mov sp, r4 pop {r4, r5, r6, r7, pc} ... r7 is used as the frame pointer for thumb targets, and this function needs to restore the SP from the FP because of the variable-length stack allocation a. r7 is clobbered by the inline assembly (and r7 is included in the clobber list), but LLVM does not preserve the value of the frame pointer across the assembly block. This type of behavior is similar to GCC's and has been discussed on the bugtracker: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11807 . No consensus seemed to have been reached on the way forward. Clang behavior has briefly been discussed on the CFE mailing (starting here: http://lists.llvm.org/pipermail/cfe-dev/2018-July/058392.html). I've opted for following Eli Friedman's advice to print warnings when there are reserved registers on the clobber list so as not to diverge from GCC behavior for now. The patch uses MachineRegisterInfo's target-specific knowledge of reserved registers, just before we convert the inline asm string in the AsmPrinter. If we find a reserved register, we print a warning: repro.c:6:7: warning: inline asm clobber list contains reserved registers: R7 [-Winline-asm] "mov r7, #1" ^ Reviewers: efriedma, olista01, javed.absar Reviewed By: efriedma Subscribers: eraman, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D51165 llvm-svn: 341062
* Don't count debug instructions towards neighborhood countMatt Arsenault2018-08-301-3/+13
| | | | | | | | | In computeRegisterLiveness, the max instructions to search was counting dbg_value instructions, which could potentially cause an observable codegen change from the presence of debug info. llvm-svn: 341028
* CodeGen: Make computeRegisterLiveness search forward firstMatt Arsenault2018-08-301-33/+35
| | | | | | | | If there is an unused def, this would previously report that the register was live. Check for uses first so that it is reported as dead if never used. llvm-svn: 341027
* CodeGen: Make computeRegisterLiveness consider successorsMatt Arsenault2018-08-301-0/+14
| | | | | | | | If the end of the block is reached during the scan, check the live ins of the successors. This was already done in the other direction if the block entry was reached. llvm-svn: 341026
* [DWARF] Missing location debug information with -O2.Carlos Alberto Enciso2018-08-303-20/+26
| | | | | | | | | Check that Machine CSE correctly handles during the transformation, the debug location information for local variables. Differential Revision: https://reviews.llvm.org/D50887 llvm-svn: 341025
* DAG: Don't use ABI copies in some contextsMatt Arsenault2018-08-301-2/+3
| | | | | | | | | | | | | If an ABI-like value is used in a different block, the type split used is not necessarily the same as the call's ABI. The value is used through an intermediate copy virtual registers from the other block. This resulted in copies with inconsistent sizes later. Fixes regressions since r338197 when AMDGPU started splitting vector types for calls. llvm-svn: 341018
* [GlobalMerge] Fix GlobalMerge on bss external global variables.Huihui Zhang2018-08-301-1/+1
| | | | | | | | | | | | | | | | | Summary: Global variables that are external and zero initialized are supposed to be merged with global variables in the bss section rather than the data section. Reviewers: efriedma, rengolin, t.p.northover, javed.absar, asl, john.brawn, pcc Reviewed By: efriedma Subscribers: dmgreen, llvm-commits Differential Revision: https://reviews.llvm.org/D51379 llvm-svn: 341008
* [NFC] Make getPreferredAlignment honor section markings.Eli Friedman2018-08-291-10/+1
| | | | | | | | | | | | | This should more accurately reflect what the AsmPrinter will actually do. This is NFC, as far as I can tell; all the places that might be affected already have an extra check to avoid using the result of getPreferredAlignment in this situation. Differential Revision: https://reviews.llvm.org/D51377 llvm-svn: 340999
* Reverse subregister saved loops in register usage info collector; NFCMatthias Braun2018-08-291-23/+22
| | | | | | | | | | | | | | | | | | On AMDGPU we have 70 register classes, so iterating over all 70 each time and exiting is costly on the CPU, this flips the loop around so that it loops over the 70 register classes first, and exits without doing the inner loop if needed. On my test just starting radv this takes RegUsageInfoCollector::runOnMachineFunction from 6.0% of total time to 2.7% of total time, and reduces the startup from 2.24s to 2.19s Patch by David Airlie! Differential Revision: https://reviews.llvm.org/D48582 llvm-svn: 340993
* [MinGW] [X86] Add stubs for references to data variables that might end up ↵Martin Storsjo2018-08-292-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | imported from a dll Variables declared with the dllimport attribute are accessed via a stub variable named __imp_<var>. In MinGW configurations, variables that aren't declared with a dllimport attribute might still end up imported from another DLL with runtime pseudo relocs. For x86_64, this avoids the risk that the target is out of range for a 32 bit PC relative reference, in case the target DLL is loaded further than 4 GB from the reference. It also avoids having to make the text section writable at runtime when doing the runtime fixups, which makes it worthwhile to do for i386 as well. Add stub variables for all dso local data references where a definition of the variable isn't visible within the module, since the DLL data autoimporting might make them imported even though they are marked as dso local within LLVM. Don't do this for variables that actually are defined within the same module, since we then know for sure that it actually is dso local. Don't do this for references to functions, since there's no need for runtime pseudo relocations for autoimporting them; if a function from a different DLL is called without the appropriate dllimport attribute, the call just gets routed via a thunk instead. GCC does something similar since 4.9 (when compiling with -mcmodel=medium or large; from that version, medium is the default code model for x86_64 mingw), but only for x86_64. Differential Revision: https://reviews.llvm.org/D51288 llvm-svn: 340942
* [DAGCombiner] Add X / X -> 1 & X % X -> 0 foldsSimon Pilgrim2018-08-291-1/+18
| | | | | | | | Adds more divrem folds to try and get in sync with InstructionSimplify Differential Revision: https://reviews.llvm.org/D50636 llvm-svn: 340919
* Revert r340904 "[llvm-mc] - Allow to set custom flags for debug sections."George Rimar2018-08-291-3/+0
| | | | | | | It broke PPC64 BB: http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/23252 llvm-svn: 340906
* [llvm-mc] - Allow to set custom flags for debug sections.George Rimar2018-08-291-0/+3
| | | | | | | | | | | | | | | | | | | | | | I am experimenting with a single split dwarf (.dwo sections in .o files). I want to make linker to ignore .dwo sections in .o, for that I am trying to add SHF_EXCLUDE flag ("E") for them in my asm sample. I found that currently, it is impossible to add any flag for debug sections using llvm-mc. That happens because we have a set of predefined unique sections created early with default flags: https://github.com/llvm-mirror/llvm/blob/master/lib/MC/MCObjectFileInfo.cpp#L391 This patch allows a user to add any flags he wants. I had to edit TargetLoweringObjectFileImpl.cpp to set MetaData type for debug sections. Their kind was Data by default (so they were allocatable) and so after changes introduced by this patch the SHF_ALLOC flag was applied for them, what does not make sense for debug sections. One of OrcJITTests tests failed because of that. Differential revision: https://reviews.llvm.org/D51361 llvm-svn: 340904
* [GISel]: Add legalization support for Widening UADDO/USUBOAditya Nandakumar2018-08-291-0/+26
| | | | | | | | | | | https://reviews.llvm.org/D51384 Added code in LegalizerHelper to widen UADDO/USUBO along with unit tests. Reviewed by volkan. llvm-svn: 340892
* [X86] Support v2i32 gather/scatter indices with ↵Craig Topper2018-08-293-21/+46
| | | | | | | | | | | | | | | | -x86-experimental-vector-widening-legalization Summary: This is split out from D41062 to cover the code in LegalVectorTypes.cpp Reviewers: RKSimon, spatel, efriedma Reviewed By: efriedma Subscribers: sdardis, jvesely, nhaehnle, jrtc27, atanasyan, llvm-commits Differential Revision: https://reviews.llvm.org/D51337 llvm-svn: 340891
* [GISel]: Add missing opcodes for overflow intrinsicsAditya Nandakumar2018-08-281-13/+7
| | | | | | | | | | | | | | | | https://reviews.llvm.org/D51197 Currently, IRTranslator (and GISel) seems to be arbitrarily picking which overflow intrinsics get mapped into opcodes which either have a carry as an input or not. For intrinsics such as Intrinsic::uadd_with_overflow, translate it to an opcode (G_UADDO) which doesn't have any carry inputs (similar to LLVM IR). This patch adds 4 missing opcodes for completeness - G_UADDO, G_USUBO, G_SSUBE and G_SADDE. llvm-svn: 340865
* [DAGCombine] Rework MERGE_VALUES to inline in single pass. NFCI.Nirav Dave2018-08-281-1/+4
| | | | | | | Avoid hyperlinear cost of inlining MERGE_VALUE node by constructing temporary vector and doing a single replacement. llvm-svn: 340853
* [DAG] Avoid recomputing Divergence checks. NFCI.Nirav Dave2018-08-281-6/+10
| | | | | | | When making multiple updates to the same SDNode, recompute node divergence only once after all changes have been made. llvm-svn: 340852
* [DAG] Fix updateDivergence calculationNirav Dave2018-08-281-1/+1
| | | | | | | Check correct SDNode when deciding if we should update the divergence property. llvm-svn: 340851
* [DAGCombiner][AMDGPU][Mips] Fold bitcast with volatile loads if the ↵Craig Topper2018-08-281-3/+12
| | | | | | | | | | | | | | | | | | | resulting load is legal for the target. Summary: I'm not sure if this patch is correct or if it needs more qualifying somehow. Bitcast shouldn't change the size of the load so it should be ok? We already do something similar for stores. We'll change the type of a volatile store if the resulting store is Legal or Custom. I'm not sure we should be allowing Custom there... I was playing around with converting X86 atomic loads/stores(except seq_cst) into regular volatile loads and stores during lowering. This would allow some special RMW isel patterns in X86InstrCompiler.td to be removed. But there's some floating point patterns in there that didn't work because we don't fold (f64 (bitconvert (i64 volatile load))) or (f32 (bitconvert (i32 volatile load))). Reviewers: efriedma, atanasyan, arsenm Reviewed By: efriedma Subscribers: jvesely, arsenm, sdardis, kzhuravl, wdng, yaxunl, dstuttard, tpr, t-tye, arichardson, jrtc27, atanasyan, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D50491 llvm-svn: 340797
* Revert "[CodeGenPrepare] Scan past debug intrinsics to find select ↵David Blaikie2018-08-281-4/+3
| | | | | | | | | | | | | | | candidates (NFC)" This causes crashes due to the interleaved dbg.value intrinsics being left at the end of basic blocks, causing the actual terminators (br, etc) to be not where they should be (not at the end of the block), leading to later crashes. Further discussion on the original commit thread. This reverts commit r340368. llvm-svn: 340794
* [Pipeliner] Fix incorrect phi values in the epilog and kernelBrendon Cahoon2018-08-271-29/+32
| | | | | | | | | | | | | | | | | | | The code that generates the loop definition operand for phis in the epilog and kernel is incorrect in some cases. In the kernel, when a phi refers to another phi, the code that updates PhiOp2 needs to include the stage difference between the two phis. In the epilog, the check for using the loop definition instead of the phi definition uses the StageDiffAdj value (the difference between the phi stage and the loop definition stage), but the adjustment is not needed to determine if the current stage contains an iteration with the loop definition. Differential Revision: https://reviews.llvm.org/D51167 llvm-svn: 340782
* DAG: Check transformed type for forming fminnum/fmaxnum from vselectMatt Arsenault2018-08-271-2/+3
| | | | | | Follow up to r340655 to fix vector types which are split. llvm-svn: 340766
* MachineVerifier: Fix assert on implicit virtreg useMatt Arsenault2018-08-271-2/+4
| | | | | | | | | If the liveness of a physical register was invalid, this was attempting to iterate the subregisters of all register uses of the instruction, which would assert when it encountered an implicit virtual register operand. llvm-svn: 340763
* [SelectionDAG] add helper query for binops; NFCSanjay Patel2018-08-271-11/+2
| | | | | | We will also use this in a planned enhancement for vector insertelement. llvm-svn: 340741
* [SelectionDAG][x86] turn insertelement into undef with variable index into splatSanjay Patel2018-08-261-3/+10
| | | | | | | | | | | | | | | | | | I noticed this along with the patterns in D51125, but when the index is variable, we don't convert insertelement into a build_vector. For x86, that means these get expanded at legalization time into the loading/spilling code that we see in the tests. I think it's always better to avoid going to memory on these, and we get the optimal 'broadcast' if it's available. I suspect other targets may want to look at enabling the hook. AArch64 and AMDGPU have regression tests that would be affected (although I did not check what would happen in those cases). In the most basic cases shown here, AArch64 would probably do much better with a splat. Differential Revision: https://reviews.llvm.org/D51186 llvm-svn: 340705
* [IR] Replace `isa<TerminatorInst>` with `isTerminator()`.Chandler Carruth2018-08-264-9/+8
| | | | | | | | | | | | This is a bit awkward in a handful of places where we didn't even have an instruction and now we have to see if we can build one. But on the whole, this seems like a win and at worst a reasonable cost for removing `TerminatorInst`. All of this is part of the removal of `TerminatorInst` from the `Instruction` type hierarchy. llvm-svn: 340701
* [IR] Begin removal of TerminatorInst by removing successor manipulation.Chandler Carruth2018-08-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The core get and set routines move to the `Instruction` class. These routines are only valid to call on instructions which are terminators. The iterator and *generic* range based access move to `CFG.h` where all the other generic successor and predecessor access lives. While moving the iterator here, simplify it using the iterator utilities LLVM provides and updates coding style as much as reasonable. The APIs remain pointer-heavy when they could better use references, and retain the odd behavior of `operator*` and `operator->` that is common in LLVM iterators. Adjusting this API, if desired, should be a follow-up step. Non-generic range iteration is added for the two instructions where there is an especially easy mechanism and where there was code attempting to use the range accessor from a specific subclass: `indirectbr` and `br`. In both cases, the successors are contiguous operands and can be easily iterated via the operand list. This is the first major patch in removing the `TerminatorInst` type from the IR's instruction type hierarchy. This change was discussed in an RFC here and was pretty clearly positive: http://lists.llvm.org/pipermail/llvm-dev/2018-May/123407.html There will be a series of much more mechanical changes following this one to complete this move. Differential Revision: https://reviews.llvm.org/D47467 llvm-svn: 340698
* [SelectionDAG][X86] Reorder the operands the MaskedStoreSDNode to put the ↵Craig Topper2018-08-253-35/+18
| | | | | | | | | | | | | | | | | | | | | value first. Summary: Previously the value being stored is the last operand in SDNode. This causes the type legalizer to visit the mask operand before the value operand. The type legalizer was more complicated because of this since we want the type of the value to drive the decisions. This patch moves the value to be the first operand so we visit it first during type legalization. It also simplifies the type legalization code accordingly. X86 is currently the only in tree target that uses this SDNode. Not sure if there are any users out of tree. Reviewers: RKSimon, delena, hfinkel, eli.friedman Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D50402 llvm-svn: 340689
* [CodeGen] Set FrameSetup/FrameDestroy on BUNDLE instructionsBjorn Pettersson2018-08-251-3/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: If any of the bundled instructions are marked as FrameSetup or FrameDestroy, then that property is set on the BUNDLE instruction as well. As long as the scheduler/packetizer aren't mixing prologue/epilogue instructions (i.e. all the bundled instructions have the same property) then this simply gives the bundle the correct property (so when using a bundle iterator in late passes a bundle will be correctly identified as FrameSetup/FrameDestroy). When for example bundling a mix of FrameSetup instructions with non-FrameSetup instructions it could be discussed if the bundle should have the property or not. The choice here has been to set these properties on the BUNDLE instruction if any of the bundled instructions have the property set. Reviewers: #debug-info, kparzysz Reviewed By: kparzysz Subscribers: vsk, thegameg, llvm-commits Differential Revision: https://reviews.llvm.org/D50637 llvm-svn: 340680
* [LiveDebugVariables] Avoid faulty addDefsFromCopies in computeIntervalsBjorn Pettersson2018-08-251-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When computeIntervals is looking through COPY instruction to extend the location mapping for a debug variable it did not handle subregisters correctly. For example DBG_VALUE debug-use %0.sub_8bit_hi, ... %1:gr16 = COPY %0 was transformed into DBG_VALUE debug-use %0.sub_8bit_hi, ... %1:gr16 = COPY %0 DBG_VALUE debug-use %1, ... So the subregister index was missing in the added DBG_VALUE. As long as the subreg refered to the least significant bits of the superreg, then I guess we could get the correct result in a debugger even when referring to the superreg. But as in the example above when the subreg refers to other parts of the superreg, then debuginfo would be incorrect. I'm not sure exactly how to fix this properly, so this patch just avoids looking through the COPY when there is a subreg involved (for more info, see the FIXME added in the code). Reviewers: rnk, aprantl Reviewed By: aprantl Subscribers: JDevlieghere, llvm-commits Tags: #debug-info Differential Revision: https://reviews.llvm.org/D50788 llvm-svn: 340679
* DAG: Allow matching fminnum/fmaxnum from vselectMatt Arsenault2018-08-241-8/+27
| | | | llvm-svn: 340655
* [SafeStack] Set debug location for calls to __safestack_pointer_address.Eli Friedman2018-08-241-0/+4
| | | | | | | | | | | | Otherwise, the debug info is incorrect. On its own, this is mostly harmless, but the safe-stack also later inlines the call to __safestack_pointer_address, which leads to debug info with the wrong scope, which eventually causes an assertion failure (and incorrect debug info in release mode). Differential Revision: https://reviews.llvm.org/D51075 llvm-svn: 340651
* CodeGen: Add two more conditions for adding symbols to the ↵Peter Collingbourne2018-08-241-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | address-significance table. Firstly, require the symbol to be used within the module. If a symbol is unused within a module, then by definition it cannot be address-significant within that module. This condition is useful on all platforms because it could make symbol tables smaller -- without this change, emitting an address-significance table could cause otherwise unused undefined symbols to be added to the object file. But this change is necessary with COFF specifically in order to preserve the property that an unreferenced undefined symbol in an IR module does not result in a link failure. This is already the case for ELF because ELF linkers only reject links with unresolved symbols if there is a relocation to that symbol, but COFF linkers require all undefined symbols to be resolved regardless of relocations. So if a module contains an unreferenced undefined symbol, we need to make sure not to add it to the address-significance table (and thus the symbol table) in case it doesn't end up resolved at link time. Secondly, do not add dllimport symbols to the table. These symbols won't be able to be resolved because their definitions live in another module and are accessed via the IAT, and the address-significance table has no effect on other modules anyway. It wouldn't make sense to add the IAT entry symbol to the address-significance table either because the IAT entry isn't address-significant -- the generated code never takes its address. Differential Revision: https://reviews.llvm.org/D51199 llvm-svn: 340648
* DebugInfo: Fix skipping CUs in DWARFv5 debug_names tableDavid Blaikie2018-08-241-2/+5
| | | | | | | | | | My previoust test case had skipped CUs from one TU out of a two-TU LTO scenario, which meant the CU index wasn't needed (as it was unambiguous which CU a table entry applied to) - expanding the test to use 3 TUs, skipping one (so long as it's not the last one) shows the indexes are miscomputed. Fix that with a little indirection for the index. llvm-svn: 340646
* [DAGCombiner][Mips] Don't combine bitcast+store after LegalOperations when ↵Craig Topper2018-08-241-1/+1
| | | | | | | | | | | | | | the store is volatile, if the resulting store isn't Legal Previously we allowed the store to be Custom. But without knowing for sure that the Custom handling won't split the store, we shouldn't convert a volatile store. We also probably shouldn't be creating a store the requires custom handling after LegalizeOps. This could lead to an infinite loop if the custom handling was to insert a bitcast. Though I guess isStoreBitCastBeneficial could be used to block such a loop. The test changes here are due to the volatile part of this. The stores in the test are all volatile and i32 stores are marked custom, So we are no longer converting them This is related to D50491 where I was trying to allow some bitcasting of volatile loads Differential Revision: https://reviews.llvm.org/D50578 llvm-svn: 340626
* [SDAG] Add versions of computeKnownBits that return a valueJustin Bogner2018-08-241-93/+81
| | | | | | | | | | | Having the KnownBits as an output parameter is kind of awkward to use and a holdover from when it was two separate APInts. Instead, just return a KnownBits object. I'm leaving the existing interface in place for now, since updating the callers all at once would be thousands of lines of diff. llvm-svn: 340594
* [RegisterCoalescer] Fix for assert in removePartialRedundancyTim Renouf2018-08-231-0/+14
| | | | | | | | | | | | | | | | | Summary: I got "Use not jointly dominated by defs" when removePartialRedundancy attempted to prune then re-extend a subrange whose only liveness was a dead def at the copy being removed. V2: Removed junk from test. Improved comment. V3: Addressed minor review comments. Subscribers: MatzeB, qcolombet, nhaehnle, llvm-commits Differential Revision: https://reviews.llvm.org/D50914 Change-Id: I6f894e9f517f71e921e0c6d81d28c5f344db8dad llvm-svn: 340549
* Revert r340508: [DebugInfo] Fix bug in LiveDebugVariables.Chandler Carruth2018-08-231-10/+5
| | | | | | | | This patch's test case relies on debug prints which isn't generally an OK way to test stuff in LLVM and fails whenever asserts aren't enabled. I've send a heads-up to the commit and detailed comments on the review. llvm-svn: 340513
* [DebugInfo] Fix bug in LiveDebugVariables.Hsiangkai Wang2018-08-231-5/+10
| | | | | | | | | | | | | | | In lib/CodeGen/LiveDebugVariables.cpp, it uses std::prev(MBBI) to get DebugValue's SlotIndex. However, the previous instruction may be also a debug instruction. It could not use a debug instruction to query SlotIndex in mi2iMap. Scan all debug instructions and use the first debug instruction to query SlotIndex for following debug instructions. Only handle DBG_VALUE in handleDebugValue(). Differential Revision: https://reviews.llvm.org/D50621 llvm-svn: 340508
* [SelectionDAG] unroll unsupported vector FP ops earlier to avoid libcalls on ↵Sanjay Patel2018-08-221-7/+26
| | | | | | | | | | | | | | | | undef elements (PR38527) This solves the motivating case from: https://bugs.llvm.org/show_bug.cgi?id=38527 If we are legalizing an FP vector op that maps to 1 of the LLVM intrinsics that mimic libm calls, but we're going to end up with scalar libcalls for that vector type anyway, then we should unroll the vector op into scalars before widening. This avoids libcalls because we've lost the knowledge that some of the scalar elements are undef. Differential Revision: https://reviews.llvm.org/D50791 llvm-svn: 340469
* [ARM] Lower llvm.ctlz.i32 to a libcall when clz is not available.Eli Friedman2018-08-221-0/+15
| | | | | | | | | | The inline sequence is very long (about 70 bytes on Thumb1), so it's not really a good idea to inline it, especially when optimizing for size. Differential Revision: https://reviews.llvm.org/D47917 llvm-svn: 340458
* [SafeStack] Handle unreachable code with safe stack coloring.Eli Friedman2018-08-221-1/+3
| | | | | | | | | Instead of asserting that the function doesn't have any unreachable code, just ignore it for the purpose of computing liveness. Differential Revision: https://reviews.llvm.org/D51070 llvm-svn: 340456
* [CodeGenPrepare] Set debug locs when folding a comparison into a ↵Vedant Kumar2018-08-221-0/+4
| | | | | | | | | uadd.with.overflow CGP can replace a branch + select with a uadd.with.overflow. Teach it to set debug locations as it does this. llvm-svn: 340432
* [GISel]: Add legalization support for widening bit counting operationsAditya Nandakumar2018-08-221-0/+36
| | | | | | | | | | https://reviews.llvm.org/D51053 Added legalization for WidenScalar of various bitcounting opcodes. Reviewed by arsenm. llvm-svn: 340429
* [CodeGenPrepare] Set debug loc when widening a switch conditionVedant Kumar2018-08-221-0/+1
| | | | | | | Set a debug location on the cast instruction used to widen a switch condition. llvm-svn: 340379
* [CodeGenPrepare] Set debug locations when splitting selectsVedant Kumar2018-08-221-1/+5
| | | | | | | When splitting a select into a diamond, set debug locations on newly-created branch instructions and phi nodes. llvm-svn: 340371
* [CodeGenPrepare] Clean up dbg.value use-before-def as late as possibleVedant Kumar2018-08-211-5/+4
| | | | | | | | | | | CodeGenPrepare has a strategy for moving dbg.values so that a value's definition always dominates its debug users. This cleanup was happening too early (before certain CGP transforms were run), resulting in some dbg.value use-before-def errors. Perform this cleanup as late as possible to avoid use-before-def. llvm-svn: 340370
OpenPOWER on IntegriCloud