summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* [AArch64,Assembler] Compiler support for ID_MMFR5_EL1Mark Murray2019-10-161-0/+1
| | | | | | | | | | | | Summary: Add read-only system register ID_MMFR5_EL1 and unit tests. Subscribers: kristof.beyls, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69039 llvm-svn: 375010
* [Remarks] Add support for prepending a path to external filesFrancis Visoiu Mistrih2019-10-165-17/+39
| | | | | | | | | This helps with testing and debugging for paths that are assumed absolute. It also uses a FileError to provide the file path it's trying to open. llvm-svn: 375008
* bpf: fix wrong truncation elimination when there is back-edge/loopJiong Wang2019-10-164-167/+205
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, BPF backend is doing truncation elimination. If one truncation is performed on a value defined by narrow loads, then it could be redundant given BPF loads zero extend the destination register implicitly. When the definition of the truncated value is a merging value (PHI node) that could come from different code paths, then checks need to be done on all possible code paths. Above described optimization was introduced as r306685, however it doesn't work when there is back-edge, for example when loop is used inside BPF code. For example for the following code, a zero-extended value should be stored into b[i], but the "and reg, 0xffff" is wrongly eliminated which then generates corrupted data. void cal1(unsigned short *a, unsigned long *b, unsigned int k) { unsigned short e; e = *a; for (unsigned int i = 0; i < k; i++) { b[i] = e; e = ~e; } } The reason is r306685 was trying to do the PHI node checks inside isel DAG2DAG phase, and the checks are done on MachineInstr. This is actually wrong, because MachineInstr is being built during isel phase and the associated information is not completed yet. A quick search shows none target other than BPF is access MachineInstr info during isel phase. For an PHI node, when you reached it during isel phase, it may have all predecessors linked, but not successors. It seems successors are linked to PHI node only when doing SelectionDAGISel::FinishBasicBlock and this happens later than PreprocessISelDAG hook. Previously, BPF program doesn't allow loop, there is probably the reason why this bug was not exposed. This patch therefore fixes the bug by the following approach: - The existing truncation elimination code and the associated "load_to_vreg_" records are removed. - Instead, implement truncation elimination using MachineSSA pass, this is where all information are built, and keep the pass together with other similar peephole optimizations inside BPFMIPeephole.cpp. Redundant move elimination logic is updated accordingly. - Unit testcase included + no compilation errors for kernel BPF selftest. Patch Review === Patch was sent to and reviewed by BPF community at: https://lore.kernel.org/bpf Reported-by: David Beckett <david.beckett@netronome.com> Reviewed-by: Yonghong Song <yhs@fb.com> Signed-off-by: Jiong Wang <jiong.wang@netronome.com> llvm-svn: 375007
* [RISCV] Add MachineInstr immediate verificationLuis Marques2019-10-166-4/+101
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements the `TargetInstrInfo::verifyInstruction` hook for RISC-V. Currently the hook verifies the machine instruction's immediate operands, to check if the immediates are within the expected bounds. Without the hook invalid immediates are not detected except when doing assembly parsing, so they are silently emitted (including being truncated when emitting object code). The bounds information is specified in tablegen by using the `OperandType` definition, which sets the `MCOperandInfo`'s `OperandType` field. Several RISC-V-specific immediate operand types were created, which extend the `MCInstrDesc`'s `OperandType` `enum`. To have the hook called with `llc` pass it the `-verify-machineinstrs` option. For Clang add the cmake build config `-DLLVM_ENABLE_EXPENSIVE_CHECKS=True`, or temporarily patch `TargetPassConfig::addVerifyPass`. Review concerns: - The patch adds immediate operand type checks that cover at least the base ISA. There are several other operand types for the C extension and one type for the F/D extensions that were left out of this initial patch because they introduced further design concerns that I felt were best evaluated separately. - Invalid register classes (e.g. passing a GPR register where a GPRC is expected) are already caught, so were not included. - This design makes the more abstract `MachineInstr` verification depend on MC layer definitions, which arguably is not the cleanest design, but is in line with how things are done in other parts of the target and LLVM in general. - There is some duplication of logic already present in the `MCOperandPredicate`s. Since the `MachineInstr` and `MCInstr` notions of immediates are fundamentally different, this is currently necessary. Reviewers: asb, lenary Reviewed By: lenary Subscribers: hiraditya, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, s.egerton, pzheng, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67397 llvm-svn: 375006
* [AMDGPU] Fix-up cases where writelane has 2 SGPR operandsDavid Stuttard2019-10-162-0/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Even though writelane doesn't have the same constraints as other valu instructions it still can't violate the >1 SGPR operand constraint Due to later register propagation (e.g. fixing up vgpr operands via readfirstlane) changing writelane to only have a single SGPR is tricky. This implementation puts a new check after SIFixSGPRCopies that prevents multiple SGPRs being used in any writelane instructions. The algorithm used is to check for trivial copy prop of suitable constants into one of the SGPR operands and perform that if possible. If this isn't possible put an explicit copy of Src1 SGPR into M0 and use that instead (this is allowable for writelane as the constraint is for SGPR read-port and not constant-bus access). Reviewers: rampitec, tpr, arsenm, nhaehnle Reviewed By: rampitec, arsenm, nhaehnle Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, mgorny, yaxunl, tpr, t-tye, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D51932 Change-Id: Ic7553fa57440f208d4dbc4794fc24345d7e0e9ea llvm-svn: 375004
* RedirectingFileSystem::openFileForRead - replace bitwise & with boolean && ↵Simon Pilgrim2019-10-161-1/+1
| | | | | | | | to fix warning Seems to be just a typo - now matches other instances which do something similar llvm-svn: 374995
* RealFile - fix self-initialization warning in constructor.Simon Pilgrim2019-10-161-3/+3
| | | | llvm-svn: 374994
* [InstCombine][AMDGPU] Fix crash with v3i16/v3f16 buffer intrinsicsPiotr Sobczak2019-10-161-0/+7
| | | | | | | | | | | | | | | | | | | | Summary: This is something of a workaround to avoid a crash later on in type legalizer (WidenVectorResult()). Also added some f16 tests, including a non-working v3f16 case with a FIXME. Reviewers: arsenm, tpr, nhaehnle Reviewed By: arsenm Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68865 llvm-svn: 374993
* Revert "[HardwareLoops] Optimisation remarks"Sjoerd Meijer2019-10-161-81/+23
| | | | | | | | while I investigate the PPC build bot failures. This reverts commit ad763751565b9663bc338fa2ca5ade86c6ca22ec. llvm-svn: 374992
* [ARM] Add a register class for GPR pairs without SP and use it. NFCIMikhail Maltsev2019-10-162-7/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently Thumb2InstrInfo.cpp uses a register class which is auto-generated by tablegen. Such approach is fragile because auto-generated classes might change when other register classes are added. For example, before https://reviews.llvm.org/D62667 we were using GPRPair_with_gsub_1_in_rGPRRegClass, but had to change it to GPRPair_with_gsub_1_in_GPRwithAPSRnospRegClass because the former class stopped being generated (this did not change the functionality though). This patch adds a register class consisting of even-odd GPR register pairs from (R0, R1) to (R10, R11), which excludes (R12, SP) and uses it in Thumb2InstrInfo.cpp instead of GPRPair_with_gsub_1_in_GPRwithAPSRnospRegClass. Reviewers: ostannard, simon_tatham, dmgreen, efriedma Reviewed By: simon_tatham Subscribers: kristof.beyls, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69026 llvm-svn: 374990
* SimpleLoopUnswitch - fix uninitialized variable and null dereference ↵Simon Pilgrim2019-10-161-2/+3
| | | | | | warnings. NFCI. llvm-svn: 374986
* [AMDGPU] Extend the SI Load/Store optimizerPiotr Sobczak2019-10-161-13/+174
| | | | | | | | | | | | | | | | | | | | | Summary: Extend the SI Load/Store optimizer to merge MIMG load instructions. Handle different flavours of image_load and image_sample instructions. When the instructions of the same subclass differ only in dmask, merge them and update dmask accordingly. Reviewers: nhaehnle Reviewed By: nhaehnle Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64911 llvm-svn: 374984
* [ARM][ParallelDSP] Change smlad insertion orderSam Parker2019-10-161-16/+51
| | | | | | | | | | Instead of inserting everything after the 'root' of the reduction, insert all instructions as close to their operands as possible. This can help reduce register pressure. Differential Revision: https://reviews.llvm.org/D67392 llvm-svn: 374981
* [HardwareLoops] Optimisation remarksSjoerd Meijer2019-10-161-23/+81
| | | | | | | | | | | | This adds the initial plumbing to support optimisation remarks in the IR hardware-loop pass. I have left a todo in a comment where we can improve the reporting, and will iterate on that now that we have this initial support in. Differential Revision: https://reviews.llvm.org/D68579 llvm-svn: 374980
* [NFC] Replace a linked list in LiveDebugVariables pass with a DenseMapOrlando Cazalet-Hyams2019-10-161-82/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In LiveDebugVariables.cpp: Prior to this patch, UserValues were grouped into linked list chains. Each chain was the union of two sets: { A: Matching Source variable } or { B: Matching virtual register }. A ptr to the heads (or 'leaders') of each of these chains were kept in a map with the { Source variable } used as the key (set A predicate) and another with { Virtual register } as key (set B predicate). There was a search through the chains in the function getUserValue looking for UserValues with matching { Source variable, Complex expression, Inlined-at location }. Essentially searching for a subset of A through two interleaved linked lists of set A and B. Importantly, by design, the subset will only contain one or zero elements here. That is to say a UserValue can be uniquely identified by the tuple { Source variable, Complex expression, Inlined-at location } if it exists. This patch removes the linked list and instead uses a DenseMap to map the tuple { Source variable, Complex expression, Inlined-at location } to UserValue ptrs so that the getUserValue search predicate is this map key. The virtual register map now maps a vreg to a SmallVector<UserVal *> so that set B is still available for quick searches. Reviewers: aprantl, probinson, vsk, dblaikie Reviewed By: aprantl Subscribers: russell.gallop, gbedwell, bjope, hiraditya, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D68816 llvm-svn: 374979
* [LegalizeTypes] Don't use PromoteTargetBoolean in WidenVecOp_SETCC.Craig Topper2019-10-161-1/+4
| | | | | | | | | | | | | Similar to r374970, but I don't have a test for this. PromoteTargetBoolean is intended to be use for legalizing an operand that needs to be promoted. It picks its type based on the return from getSetccResultType and is intended to be used when we have freedom to pick the new type. But the return type we need for WidenVecOp_SETCC is completely determined by the type of the input node. llvm-svn: 374972
* [LegalizeTypes] Don't call PromoteTargetBoolean from SplitVecOp_VSETCC.Craig Topper2019-10-161-1/+5
| | | | | | | | | | | | | | | PromoteTargetBoolean calls getSetccResultType to get the return type. But we were passing it the setcc result type rather than the setcc input type. This causes an issue on X86 with avx512vl where the setcc result type for vXf16 vectors is vXi16 while the result type for vXi16 vectors is vXi1. There's really no guarantee that getSetccResultType is the type we need here. So now we just grab the extend type from getExtendForContent and extend to the original result VT of the node we're splitting. llvm-svn: 374970
* CodeExtractor: NFC: Use Range based loopAditya Kumar2019-10-161-4/+4
| | | | | | | | | | | | Reviewers: vsk, tejohnson, fhahn Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68924 llvm-svn: 374963
* [Reland][VirtualFileSystem] Support virtual working directory in the ↵Jonas Devlieghere2019-10-151-10/+35
| | | | | | | | | | | | | | | | | | | | RedirectingFS 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: 374955
* [Orc] Add a method for ObjectLinkingLayer to return ownership of object buffers.Lang Hames2019-10-151-0/+7
| | | | | | | | | | | | | | | | RTDyldObjectLinkingLayer allowed clients to register a NotifyEmitted function to reclaim ownership of object buffers once they had been linked. This patch adds similar functionality to ObjectLinkingLayer: Clients can now optionally call the ObjectLinkingLayer::setReturnObjectBuffer method to register a function that will be called when discarding object buffers. If set, this function will be called to return ownership of the object regardless of whether the link succeeded or failed. Use cases for this function include debug dumping (it provides a way to dump all objects linked into JIT'd code) and object re-use (e.g. storing an object in a cache). llvm-svn: 374951
* [JITLink] Switch to slab allocation for InProcessMemoryManager, re-enable test.Lang Hames2019-10-151-10/+40
| | | | | | | | | | | | | | InProcessMemoryManager used to make separate memory allocation calls for each permission level (RW, RX, RO), which could lead to target-out-of-range errors if data and code were placed too far apart (this was the source of failures in the JITLink/AArch64 testcase when it was first landed). This patch updates InProcessMemoryManager to allocate a single slab which is subdivided between text and data. This should guarantee that accesses remain in-range provided that individual object files do not exceed 1Mb in size. This patch also re-enables the JITLink/AArch64 testcase. llvm-svn: 374948
* [XCOFF]implement parsing relocation information for 32-bit xcoff object fileDigger Lin2019-10-151-4/+68
| | | | | | | | | | | | | | Summary: Parsing the relocation entry information for 32-bit xcoff object file including deal with the relocation overflow. Reviewers: hubert.reinterpretcast, jasonliu, sfertile, xingxue. Subscribers: hiraditya, rupprecht, seiya Differential Revision: https://reviews.llvm.org/D67008 llvm-svn: 374946
* AMDGPU: Fix infinite searches in SIFixSGPRCopiesAustin Kerbow2019-10-152-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Two conditions could lead to infinite loops when processing PHI nodes in SIFixSGPRCopies. The first condition involves a REG_SEQUENCE that uses registers defined by both a PHI and a COPY. The second condition arises when a physical register is copied to a virtual register which is then used in a PHI node. If the same virtual register is copied to the same physical register, the result is an endless loop. %0:sgpr_64 = COPY $sgpr0_sgpr1 %2 = PHI %0, %bb.0, %1, %bb.1 $sgpr0_sgpr1 = COPY %0 Reviewers: alex-t, rampitec, arsenm Reviewed By: rampitec Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68970 llvm-svn: 374944
* Revert "[VirtualFileSystem] Support virtual working directory in the ↵Jonas Devlieghere2019-10-151-35/+10
| | | | | | | | | | | RedirectingFS" This reverts the original commit and the follow up: Revert "[VirtualFileSystem] Support virtual working directory in the RedirectingFS" Revert "[test] Update YAML mapping in VirtualFileSystemTest" llvm-svn: 374935
* Added support for "#pragma clang section relro=<name>"Dmitry Mikulin2019-10-152-0/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D68806 llvm-svn: 374934
* [WebAssembly] Allow multivalue types in block signature operandsThomas Lively2019-10-159-93/+135
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Renames `ExprType` to the more apt `BlockType` and adds a variant for multivalue blocks. Currently non-void blocks are only generated at the end of functions where the block return type needs to agree with the function return type, and that remains true for multivalue blocks. That invariant means that the actual signature does not need to be stored in the block signature `MachineOperand` because it can be inferred by `WebAssemblyMCInstLower` from the return type of the parent function. `WebAssemblyMCInstLower` continues to lower block signature operands to immediates when possible but lowers multivalue signatures to function type symbols. The AsmParser and Disassembler are updated to handle multivalue block types as well. Reviewers: aheejin, dschuff, aardappel Subscribers: sbc100, jgravelle-google, hiraditya, sunfish, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68889 llvm-svn: 374933
* [X86] combineX86ShufflesRecursively - split the getTargetShuffleInputs call ↵Simon Pilgrim2019-10-151-3/+9
| | | | | | | | | | from the resolveTargetShuffleAndZeroables call. Exposes an issue in getFauxShuffleMask where the OR(SHUFFLE,SHUFFLE) decode should always resolve zero/undef elements. Part of the fix for PR43024 where ideally we shouldn't call resolveTargetShuffleAndZeroables for Depth == 0 llvm-svn: 374928
* [XCOFF] Output object text section header and symbol entry for program code.Digger Lin2019-10-152-81/+216
| | | | | | | | | | | | | | | | | | | | | | | | | This is remaining part of rG41ca91f2995b: [AIX][XCOFF] Output XCOFF object text section header and symbol entry for rogram code. SUMMARY: Original form of this patch is provided by Stefan Pintillie. 1. The patch try to output program code section header , symbol entry for program code (PR) and Instruction into the raw text section. 2. The patch include how to alignment and layout the CSection in the text section. 3. The patch also reorganize the code , put some codes into a function. (XCOFFObjectWriter::writeSymbolTableEntryForControlSection) Additional: We can not add raw data of text section test in the patch, If want to output raw text section data,it need a function description patch first. Reviewers: hubert.reinterpretcast, sfertile, jasonliu, xingxue. Subscribers: wuzish, nemanjai, hiraditya, MaskRay, jsjji. Differential Revision: https://reviews.llvm.org/D66969 llvm-svn: 374923
* [X86] Make memcmp() use PTEST if possible and also enable AVX1David Zarzycki2019-10-152-18/+49
| | | | llvm-svn: 374922
* [NewGVN] Check that call has an access.Alina Sbirlea2019-10-151-2/+5
| | | | | | | | | | Check that a call has an attached MemoryAccess before calling getClobbering on the instruction. If no access is attached, the instruction does not access memory. Resolves PR43441. llvm-svn: 374920
* [MemorySSA] Update DomTree before applying MSSA updates.Alina Sbirlea2019-10-151-8/+5
| | | | | | Update on the fix in rL374850. llvm-svn: 374918
* [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
OpenPOWER on IntegriCloud