summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
* [VirtualFileSystem] Support virtual working directory in the RedirectingFSJonas Devlieghere2019-10-151-10/+35
| | | | | | | | | | | | | | | | | | Before this patch, changing the working directory of the RedirectingFS would just forward to its external file system. This prevented us from having a working directory that only existed in the VFS mapping. This patch adds support for a virtual working directory in the RedirectingFileSystem. It now keeps track of its own WD in addition to updating the WD of the external file system. This ensures that we can still fall through for relative paths. This change was originally motivated by the reproducer infrastructure in LLDB where we want to deal transparently with relative paths. Differential revision: https://reviews.llvm.org/D65677 llvm-svn: 374917
* [AMDGPU] Support mov dpp with 64 bit operandsStanislav Mekhanoshin2019-10-154-0/+103
| | | | | | | | | | We define mov/update dpp intrinsics as overloaded but do not support i64, which is a practically useful type. Fix the selection and lowering. Differential Revision: https://reviews.llvm.org/D68673 llvm-svn: 374910
* [AMDGPU] Allow DPP combiner to work with REG_SEQUENCEStanislav Mekhanoshin2019-10-151-5/+54
| | | | | | Differential Revision: https://reviews.llvm.org/D68828 llvm-svn: 374908
* [DAGCombiner] fold select-of-constants based on sign-bit testSanjay Patel2019-10-151-0/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | Examples: i32 X > -1 ? C1 : -1 --> (X >>s 31) | C1 i8 X < 0 ? C1 : 0 --> (X >>s 7) & C1 This is a small generalization of a fold requested in PR43650: https://bugs.llvm.org/show_bug.cgi?id=43650 The sign-bit of the condition operand can be used as a mask for the true operand: https://rise4fun.com/Alive/paT Note that we already handle some of the patterns (isNegative + scalar) because there's an over-specialized, yet over-reaching fold for that in foldSelectCCToShiftAnd(). It doesn't use any TLI hooks, so I can't easily rip out that code even though we're duplicating part of it here. This fold is guarded by TLI.convertSelectOfConstantsToMath(), so it should not cause problems for targets that prefer select over shift. Also worth noting: I thought we could generalize this further to include the case where the true operand of the select is not constant, but Alive says that may allow poison to pass through where it does not in the original select form of the code. Differential Revision: https://reviews.llvm.org/D68949 llvm-svn: 374902
* revert git test commitDigger Lin2019-10-151-1/+1
| | | | llvm-svn: 374898
* a test commit accessDigger Lin2019-10-151-1/+1
| | | | llvm-svn: 374897
* [AsmPrinter] Fix unused variable warning in Release builds. NFC.Benjamin Kramer2019-10-151-0/+1
| | | | llvm-svn: 374894
* [Alignment][NFC] Value::getPointerAlignment returns MaybeAlignGuillaume Chatelet2019-10-156-49/+53
| | | | | | | | | | | | | | | | | Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet, jdoerfert Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68398 llvm-svn: 374889
* [ARM][MVE] validForTailPredication instsSam Parker2019-10-153-17/+56
| | | | | | | | | | | | | | | | | | | | Reverse the logic for valid tail predication instructions and create a whitelist instead. Added other instruction groups that aren't obviously safe: - instructions that 'narrow' their result. - lane moves. - byte swapping instructions. - interleaving loads and stores. - cross-beat carries. - top/bottom instructions. - complex operations. Hopefully we should be able to add more of these instructions to the whitelist, once we have a more concrete idea of the transform. Differential Revision: https://reviews.llvm.org/D67904 llvm-svn: 374887
* [InstCombine] fold a shifted bool zext to a select (2nd try)Sanjay Patel2019-10-151-0/+6
| | | | | | | | | | | | | | | | | | | | The 1st attempt at rL374828 inserted the code at the wrong position (outside of the constant-shift-amount block). Trying again with an additional test to verify const-ness. For a constant shift amount, add the following fold. shl (zext (i1 X)), ShAmt --> select (X, 1 << ShAmt, 0) https://rise4fun.com/Alive/IZ9 Fixes PR42257. Based on original patch by @zvi (Zvi Rackover) Differential Revision: https://reviews.llvm.org/D63382 llvm-svn: 374886
* [Alignment] Migrate Attribute::getWith(Stack)AlignmentGuillaume Chatelet2019-10-1513-55/+51
| | | | | | | | | | | | | | | | | | | Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet, jdoerfert Reviewed By: courbet Subscribers: arsenm, jvesely, nhaehnle, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D68792 llvm-svn: 374884
* [DebugInfo] Add a DW_OP_LLVM_entry_value operationDavid Stenberg2019-10-158-19/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Internally in LLVM's metadata we use DW_OP_entry_value operations with the same semantics as DWARF; that is, its operand specifies the number of bytes that the entry value covers. At the time of emitting entry values we don't know the emitted size of the DWARF expression that the entry value will cover. Currently the size is hardcoded to 1 in DIExpression, and other values causes the verifier to fail. As the size is 1, that effectively means that we can only have valid entry values for registers that can be encoded in one byte, which are the registers with DWARF numbers 0 to 31 (as they can be encoded as single-byte DW_OP_reg0..DW_OP_reg31 rather than a multi-byte DW_OP_regx). It is a bit confusing, but it seems like llvm-dwarfdump will print an operation "correctly", even if the byte size is less than that, which may make it seem that we emit correct DWARF for registers with DWARF numbers > 31. If you instead use readelf for such cases, it will interpret the number of specified bytes as a DWARF expression. This seems like a limitation in llvm-dwarfdump. As suggested in D66746, a way forward would be to add an internal variant of DW_OP_entry_value, DW_OP_LLVM_entry_value, whose operand instead specifies the number of operations that the entry value covers, and we then translate that into the byte size at the time of emission. In this patch that internal operation is added. This patch keeps the limitation that a entry value can only be applied to simple register locations, but it will fix the issue with the size operand being incorrect for DWARF numbers > 31. Reviewers: aprantl, vsk, djtodoro, NikolaPrica Reviewed By: aprantl Subscribers: jyknight, fedor.sergeev, hiraditya, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D67492 llvm-svn: 374881
* [Alignment][NFC] Remove dependency on GlobalObject::setAlignment(unsigned)Guillaume Chatelet2019-10-1527-71/+79
| | | | | | | | | | | | | | | | | Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: arsenm, mehdi_amini, jvesely, nhaehnle, hiraditya, steven_wu, dexonsmith, dang, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68944 llvm-svn: 374880
* [DebugInfo] Add interface for pre-calculating the size of emitted DWARFDavid Stenberg2019-10-154-27/+118
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: DWARF's DW_OP_entry_value operation has two operands; the first is a ULEB128 operand that specifies the size of the second operand, which is a DWARF block. This means that we need to be able to pre-calculate and emit the size of DWARF expressions before emitting them. There is currently no interface for doing this in DwarfExpression, so this patch introduces that. When implementing this I initially thought about running through DwarfExpression's emission two times; first with a temporary buffer to emit the expression, in order to being able to calculate the size of that emitted data. However, DwarfExpression is a quite complex state machine, so I decided against that, as it seemed like the two runs could get out of sync, resulting in incorrect size operands. Therefore I have implemented this in a way that we only have to run DwarfExpression once. The idea is to emit DWARF to a temporary buffer, for which it is possible to query the size. The data in the temporary buffer can then be emitted to DwarfExpression's main output. In the case of DIEDwarfExpression, a temporary DIE is used. The values are all allocated using the same BumpPtrAllocator as for all other DIEs, and the values are then transferred to the real value list. In the case of DebugLocDwarfExpression, the temporary buffer is implemented using a BufferByteStreamer which emits to a buffer in the DwarfExpression object. Reviewers: aprantl, vsk, NikolaPrica, djtodoro Reviewed By: aprantl Subscribers: hiraditya, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D67768 llvm-svn: 374879
* [X86] Resolve KnownUndef/KnownZero bits into target shuffle masks in helper. ↵Simon Pilgrim2019-10-151-9/+18
| | | | | | NFCI. llvm-svn: 374878
* [DebugInfo] Remove some users of DBG_VALUEs IsIndirect fieldJeremy Morse2019-10-156-54/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch kills off a significant user of the "IsIndirect" field of DBG_VALUE machine insts. Brought up in in PR41675, IsIndirect is techncally redundant as it can be expressed by the DIExpression of a DBG_VALUE inst, and it isn't helpful to have two ways of expressing things. Rather than setting IsIndirect, have DBG_VALUE creators add an extra deref to the insts DIExpression. There should now be no appearences of IsIndirect=True from isel down to LiveDebugVariables / VirtRegRewriter, which is ensured by an assertion in LDVImpl::handleDebugValue. This means we also get to delete the IsIndirect handling in LiveDebugVariables. Tests can be upgraded by for example swapping the following IsIndirect=True DBG_VALUE: DBG_VALUE $somereg, 0, !123, !DIExpression(DW_OP_foo) With one where the indirection is in the DIExpression, by _appending_ a deref: DBG_VALUE $somereg, $noreg, !123, !DIExpression(DW_OP_foo, DW_OP_deref) Which both mean the same thing. Most of the test changes in this patch are updates of that form; also some changes in how the textual assembly printer handles these insts. Differential Revision: https://reviews.llvm.org/D68945 llvm-svn: 374877
* [MIPS GlobalISel] Add MSA registers to fprb. Select vector load, storePetar Avramovic2019-10-154-26/+103
| | | | | | | | | | | | | | | | | | Add vector MSA register classes to fprb, they are 128 bit wide. MSA instructions use the same registers for both integer and floating point operations. Therefore we only need to check for vector element size during legalization or instruction selection. Add helper function in MipsLegalizerInfo and switch to legalIf LegalizeRuleSet to keep legalization rules compact since they depend on MipsSubtarget and presence of MSA. fprb is assigned to all vector operands. Move selectLoadStoreOpCode to MipsInstructionSelector in order to reduce number of arguments. Differential Revision: https://reviews.llvm.org/D68867 llvm-svn: 374872
* Change Comments SmallVector to std::vector in DebugLocStream [NFC]David Stenberg2019-10-152-3/+3
| | | | | | | | | | | | | | This changes the 32-element SmallVector to a std::vector. When building a RelWithDebInfo clang-8 binary, the average size of the vector was ~10000, so it does not seem very beneficial or practical to use a small vector for that. The DWARFBytes SmallVector grows in the same way as Comments, so perhaps that also should be changed to a purely dynamically allocated structure, but that requires some more code changes, so I let that remain as a SmallVector for now. llvm-svn: 374871
* [MIPS GlobalISel] Refactor MipsRegisterBankInfo [NFC]Petar Avramovic2019-10-152-153/+127
| | | | | | | | | | Check if size of operand LLT matches sizes of available register banks before inspecting the opcode in order to reduce number of checks. Factor commonly used pieces of code into functions. Differential Revision: https://reviews.llvm.org/D68866 llvm-svn: 374870
* [Demangle] Add a few more options to the microsoft demanglerMartin Storsjo2019-10-152-20/+41
| | | | | | | | | | | | | | | This corresponds to commonly used options to UnDecorateSymbolName within llvm. Add them as hidden options in llvm-undname. MS undname.exe takes numeric flags, corresponding to the UNDNAME_* constants, but instead of hardcoding in mappings for those numbers, just add textual options instead, as it the use of them here is primarily intended for testing. Differential Revision: https://reviews.llvm.org/D68917 llvm-svn: 374865
* [X86] Don't check for VBROADCAST_LOAD being a user of the source of a ↵Craig Topper2019-10-151-3/+1
| | | | | | | | | | | | | | | | | | VBROADCAST when trying to share broadcasts. The only things VBROADCAST_LOAD uses is an address and a chain node. It has no vector inputs. So if its a user of the source of another broadcast that could only mean one of two things. The other broadcast is broadcasting the address of the broadcast_load. Or the source is a load and the use we're seeing is the chain result from that load. Neither of these cases make sense to combine here. This issue was reported post-commit r373871. Test case has not been reduced yet. llvm-svn: 374862
* Revert [SROA] Reuse existing lifetime markers if possibleDavid L. Jones2019-10-151-8/+2
| | | | | | | | This reverts r374692 (git commit 92694eba933ef4ea0b1b6377809ff266df37d61b) Reproducer sent to commit thread on llvm-commits. llvm-svn: 374859
* [RISCV] Support fast calling conventionShiva Chen2019-10-151-2/+67
| | | | | | | | | | | | LLVM may annotate the function with fastcc if there has only one caller and there're no other caller out of the module and the function is not naked or contain variable arguments. The fastcc functions could pass the arguments by the caller saved registers. Differential Revision: https://reviews.llvm.org/D68559 llvm-svn: 374857
* [WebAssembly] Trapping fptoint builtins and intrinsicsThomas Lively2019-10-151-0/+17
| | | | | | | | | | | | | | | | | | | | | Summary: The WebAssembly backend lowers fptoint instructions to a code sequence that checks for overflow to avoid traps because fptoint is supposed to be speculatable. These new builtins and intrinsics give users a way to depend on the trapping semantics of the underlying instructions and avoid the extra code generated normally. Patch by coffee and tlively. Reviewers: aheejin Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D68902 llvm-svn: 374856
* Revert [InstCombine] fold a shifted bool zext to a selectSanjay Patel2019-10-141-6/+0
| | | | | | This reverts r374828 (git commit 1f40f15d54aac06421448b6de131231d2d78bc75) due to bot breakage llvm-svn: 374851
* [MemorySSA] Update for partial unswitch.Alina Sbirlea2019-10-141-0/+7
| | | | | | | | Update MSSA for blocks cloned when doing partial unswitching. Enable additional testing with MSSA. Resolves PR43641. llvm-svn: 374850
* [X86] Teach X86MCodeEmitter to properly encode zmm16-zmm31 as index register ↵Craig Topper2019-10-141-0/+3
| | | | | | | | | | | | to vgatherpf/vscatterpf. We need to encode bit 4 into the EVEX.V' bit. We do this right for regular gather/scatter which use either MRMSrcMem or MRMDestMem formats. The prefetches use MRM*m formats. Fixes an issue recently added to PR36202. llvm-svn: 374849
* Revert "Dead Virtual Function Elimination"Jorge Gorbe Moya2019-10-146-215/+36
| | | | | | This reverts commit 9f6a873268e1ad9855873d9d8007086c0d01cf4f. llvm-svn: 374844
* In the new pass manager use PTO.LoopUnrolling to determine when and howEric Christopher2019-10-141-6/+6
| | | | | | | | | | | | | | | | | | | we will unroll loops. Also comment a few occasions where we need to know whether or not we're forcing the unwinder or not. The default before and after this patch is for LoopUnroll to be enabled, and for it to use a cost model to determine whether to unroll the loop (`OnlyWhenForced = false`). Before this patch, disabling loop unroll would not run the LoopUnroll pass. After this patch, the LoopUnroll pass is being run, but it restricts unrolling to only the loops marked by a pragma (`OnlyWhenForced = true`). In addition, this patch disables the UnrollAndJam pass when disabling unrolling. Testcase is in clang because it's controlling how the loop optimizer is being set up and there's no other way to trigger the behavior. llvm-svn: 374838
* [ARM][AsmParser] handles offset expression in parenthesesJian Cai2019-10-141-5/+7
| | | | | | | | | | | | | | | Summary: Integrated assembler does not accept offset expressions surrounded by parenthesis. Handle this case for GAS compability. https://bugs.llvm.org/show_bug.cgi?id=43631 Subscribers: kristof.beyls, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68764 llvm-svn: 374832
* DebugInfo: Remove unnecessary/mistaken inclusion of Bitcode/BitcodeAnalyzer.hDavid Blaikie2019-10-142-4/+0
| | | | | | | | | | | | | | | | Introduced in r374582, Michael Spencer pointed out this broke the modules build due to a missing tblgen dependency on llvm/IR/Attributes.inc. Michael fixed the dependency in r374827. So this removes the inclusion and the new dependency (effectively reverting r374827 and including the alternative fix of removing rather than supporting the new dependency). Thanks for the quick fix/notice, Michael! llvm-svn: 374831
* [InstCombine] fold a shifted bool zext to a selectSanjay Patel2019-10-141-0/+6
| | | | | | | | | | | | | | | For a constant shift amount, add the following fold. shl (zext (i1 X)), ShAmt --> select (X, 1 << ShAmt, 0) https://rise4fun.com/Alive/IZ9 Fixes PR42257. Based on original patch by @zvi (Zvi Rackover) Differential Revision: https://reviews.llvm.org/D63382 llvm-svn: 374828
* [Modules Build] Add missing dependency.Michael J. Spencer2019-10-141-0/+3
| | | | | | A previous commit made libLLVMDebugInfoDWARF depend on the LLVM_Bitcode module which depends on the LLVM_intrinsic_gen module which depends on "llvm/IR/Attributes.inc" which is a generated header not depended on by libLLVMDebugInfo. Add that dependency. llvm-svn: 374827
* [LoopIdiom] BCmp: loop exit count must not be wider than size_t that `bcmp` ↵Roman Lebedev2019-10-141-0/+6
| | | | | | | | | | | | takes As reported by Joerg Sonnenberger in IRC, for 32-bit systems, where pointer and size_t are 32-bit, if you use 64-bit-wide variable in the loop, you could end up with loop exit count being of the type wider than the size_t. Now, i'm not sure if we can produce `bcmp` from that (just truncate?), but we certainly should not assert/miscompile. llvm-svn: 374811
* [ThinLTO] Fix printing of NoInline function summary flagTeresa Johnson2019-10-141-1/+1
| | | | | | | | | | | | | | | | Summary: The guard for printing function flags in the summary was not checking the NoInline flag. Reviewers: wmi Subscribers: mehdi_amini, inglorion, hiraditya, steven_wu, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68948 llvm-svn: 374802
* AMDGPU: Fix redundant setting of m0 for atomic load/storeMatt Arsenault2019-10-141-10/+7
| | | | | | | Atomic load/store would have their setting of m0 handled twice, which happened to be optimized out later. llvm-svn: 374801
* Add FMF to vector ops for phiMichael Berg2019-10-141-1/+1
| | | | | | | | | | | | | | Summary: Small amendment to handle vector cases for D67564. Reviewers: spatel, eli.friedman, hfinkel, cameron.mcinally, arsenm, jmolloy, bogner Reviewed By: cameron.mcinally, bogner Subscribers: llvm-commits, efriedma, reames, bogner, wdng Differential Revision: https://reviews.llvm.org/D68748 llvm-svn: 374794
* [NVPTX] Restructure shfl instrinsics and add variants that return a predicate.Artem Belevich2019-10-142-111/+63
| | | | | | | | | Also, amend constraints for non-sync variants that are no longer available on sm_70+ with PTX6.4+. Differential Revision: https://reviews.llvm.org/D68892 llvm-svn: 374790
* BitsInit::resolveReferences - silence static analyzer null dereference ↵Simon Pilgrim2019-10-141-1/+1
| | | | | | | | warning. NFCI. The static analyzer is warning about a potential null dereference, assert to check that the loop has set the cached pointer. llvm-svn: 374789
* XCOFFObjectWriter - silence static analyzer dyn_cast<> null dereference ↵Simon Pilgrim2019-10-141-1/+1
| | | | | | | | warning. NFCI. The static analyzer is warning about a potential null dereference, but we should be able to use cast<> directly and if not assert will fire for us. llvm-svn: 374788
* [CostModel][X86] Add CTLZ scalar costsSimon Pilgrim2019-10-141-1/+22
| | | | | | | | Add specific scalar costs for CTLZ instructions, we can't discriminate between CTLZ and CTLZ_ZERO_UNDEF so we have to assume the worst. Given how BSR is often a microcoded nightmare on some older targets we might still be underestimating it. For targets supporting LZCNT (Intel Haswell+ or AMD Fam10+), we provide overrides that assume 1cy costs. llvm-svn: 374786
* Reapply r374743 with a fix for the ocaml bindingJoerg Sonnenberger2019-10-1411-67/+199
| | | | | | | | | | | | | | | | | | | Add a pass to lower is.constant and objectsize intrinsics This pass lowers is.constant and objectsize intrinsics not simplified by earlier constant folding, i.e. if the object given is not constant or if not using the optimized pass chain. The result is recursively simplified and constant conditionals are pruned, so that dead blocks are removed even for -O0. This allows inline asm blocks with operand constraints to work all the time. The new pass replaces the existing lowering in the codegen-prepare pass and fallbacks in SDAG/GlobalISEL and FastISel. The latter now assert on the intrinsics. Differential Revision: https://reviews.llvm.org/D65280 llvm-svn: 374784
* [ARM] Selection for MVE VMOVNDavid Green2019-10-143-0/+48
| | | | | | | | | | | | | | The adds both VMOVNt and VMOVNb instruction selection from the appropriate shuffles. We detect shuffle masks of the form: 0, N, 2, N+2, 4, N+4, ... or 0, N+1, 2, N+3, 4, N+5, ... ISel will also try the opposite patterns, with inputs reversed. These are selected to VMOVNt and VMOVNb respectively. Differential Revision: https://reviews.llvm.org/D68283 llvm-svn: 374781
* [CostModel][X86] Add CTPOP scalar costs (PR43656)Simon Pilgrim2019-10-141-0/+23
| | | | | | | | Add specific scalar costs for ctpop instructions, these are based on the llvm-mca's SLM throughput numbers (the oldest model we have). For targets supporting POPCNT, we provide overrides that assume 1cy costs. llvm-svn: 374775
* [Alignment][NFC] Move and type functions from MathExtras to AlignmentGuillaume Chatelet2019-10-142-5/+5
| | | | | | | | | | | | | | | | | Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68942 llvm-svn: 374773
* [AArch64] Stackframe accesses to SVE objects.Sander de Smalen2019-10-144-41/+108
| | | | | | | | | | | | | | | | | Materialize accesses to SVE frame objects from SP or FP, whichever is available and beneficial. This patch still assumes the objects are pre-allocated. The automatic layout of SVE objects within the stackframe will be added in a separate patch. Reviewers: greened, cameron.mcinally, efriedma, rengolin, thegameg, rovka Reviewed By: cameron.mcinally Differential Revision: https://reviews.llvm.org/D67749 llvm-svn: 374772
* [DebugInfo] Fix truncation of call site immediatesDavid Stenberg2019-10-141-1/+1
| | | | | | | | | | | | | | | | | | | | Summary: This addresses a bug in collectCallSiteParameters() where call site immediates would be truncated from int64_t to unsigned. This fixes PR43525. Reviewers: djtodoro, NikolaPrica, aprantl, vsk Reviewed By: aprantl Subscribers: hiraditya, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D68869 llvm-svn: 374770
* Revert "Add a pass to lower is.constant and objectsize intrinsics"Dmitri Gribenko2019-10-1411-199/+67
| | | | | | | This reverts commit r374743. It broke the build with Ocaml enabled: http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/19218 llvm-svn: 374768
* [AMDGPU] Come back patch for the 'Assign register class for cross block ↵Alexander Timofeev2019-10-144-125/+208
| | | | | | | | | | | | | | | | | | | | | | | | values according to the divergence.' Detailed description: After https://reviews.llvm.org/D59990 submit several issues were discovered. Changes in common code were preserved but AMDGPU specific part was reverted to keep the backend working correctly. Discovered issues were addressed in the following commits: https://reviews.llvm.org/D67662 https://reviews.llvm.org/D67101 https://reviews.llvm.org/D63953 https://reviews.llvm.org/D63731 This change brings back AMDGPU specific changes. Reviewed by: rampitec, arsenm Differential Revision: https://reviews.llvm.org/D68635 llvm-svn: 374767
* [X86][BtVer2] Improved latency and throughput of float/vector loads and stores.Andrea Di Biagio2019-10-141-6/+6
| | | | | | | | | | | | | | | | | | | | This patch introduces the following changes to the btver2 scheduling model: - The number of micro opcodes for YMM loads and stores is now 2 (it was incorrectly set to 1 for both aligned and misaligned loads/stores). - Increased the number of AGU resource cycles for YMM loads and stores to 2cy (instead of 1cy). - Removed JFPU01 and JFPX from the list of resources consumed by pure float/vector loads (no MMX). I verified with llvm-exegesis that pure XMM/YMM loads are no-pipe. Those are dispatched to the FPU but not really issues on JFPU01. Differential Revision: https://reviews.llvm.org/D68871 llvm-svn: 374765
OpenPOWER on IntegriCloud