- Oct 14, 2021
-
-
Brian Cain authored
This commit adds the system reg/regpair definitions and the corresponding register transfer instructions.
-
Andrew Savonichev authored
These registers are used as operands for instructions that expect an integer register, so they should be added to Int32Regs or Int64Regs register classes. Otherwise the machine verifier emits an error for the following LIT tests when LLVM_ENABLE_MACHINE_VERIFIER=1 environment variable is set: *** Bad machine code: Illegal physical register for instruction *** - function: kernel_func - basic block: %bb.0 entry (0x55c8903d5438) - instruction: %3:int64regs = LEA_ADDRi64 $vrframelocal, 0 - operand 1: $vrframelocal $vrframelocal is not a Int64Regs register. CodeGen/NVPTX/call-with-alloca-buffer.ll CodeGen/NVPTX/disable-opt.ll CodeGen/NVPTX/lower-alloca.ll CodeGen/NVPTX/lower-args.ll CodeGen/NVPTX/param-align.ll CodeGen/NVPTX/reg-types.ll DebugInfo/NVPTX/dbg-declare-alloca.ll DebugInfo/NVPTX/dbg-value-const-byref.ll Differential Revision: https://reviews.llvm.org/D110164
-
Jonas Paulsson authored
-
Andrew Savonichev authored
The patch attempts to optimize a sequence of SIMD loads from the same base pointer: %0 = gep float*, float* base, i32 4 %1 = bitcast float* %0 to <4 x float>* %2 = load <4 x float>, <4 x float>* %1 ... %n1 = gep float*, float* base, i32 N %n2 = bitcast float* %n1 to <4 x float>* %n3 = load <4 x float>, <4 x float>* %n2 For AArch64 the compiler generates a sequence of LDR Qt, [Xn, #16]. However, 32-bit NEON VLD1/VST1 lack the [Wn, #imm] addressing mode, so the address is computed before every ld/st instruction: add r2, r0, #32 add r0, r0, #16 vld1.32 {d18, d19}, [r2] vld1.32 {d22, d23}, [r0] This can be improved by computing address for the first load, and then using a post-indexed form of VLD1/VST1 to load the rest: add r0, r0, #16 vld1.32 {d18, d19}, [r0]! vld1.32 {d22, d23}, [r0] In order to do that, the patch adds more patterns to DAGCombine: - (load (add ptr inc1)) and (add ptr inc2) are now folded if inc1 and inc2 are constants. - (or ptr inc) is now recognized as a pointer increment if ptr is sufficiently aligned. In addition to that, we now search for all possible base updates and then pick the best one. Differential Revision: https://reviews.llvm.org/D108988
-
Simon Pilgrim authored
Avoids unused assignment scan-build warning.
-
Simon Pilgrim authored
Without SSE41 sext/zext instructions the extensions will be split, meaning that the MUL->PMADDWD fold will split the sext_i32(x) into zext_i32(sext_i16(x))
-
Simon Pilgrim authored
2 returns, one after the other - reported by coverity
-
Jeremy Morse authored
Some functions get opted out of instruction referencing if they're being compiled with no optimisations, however the LiveDebugValues pass picks one implementation and then sticks with it through the rest of compilation. This leads to a segfault if we encounter a function that doesn't use instr-ref (because it's optnone, for example), but we've already decided to use InstrRefBasedLDV which expects to be passed a DomTree. Solution: keep both implementations around in the pass, and pick whichever one is appropriate to the current function.
-
Jonas Paulsson authored
This reverts 3562076d and includes some refactoring as well. Review: Ulrich Weigand Differential Revision: https://reviews.llvm.org/D111733
-
Jonas Paulsson authored
This patch fixes the bug that consisted of treating variable / immediate length mem operations (such as memcpy, memset, ...) differently. The variable length case needs to have the length minus 1 passed due to the use of EXRL target instructions. However, the DAGCombiner can convert a register length argument into a constant one, and whenever that happened one byte too little would end up being performed. This is also a refactorization by reducing the number of opcodes and variants involved. For any opcode (variable or constant length), only the length minus one is passed on to the ISD node. The rest of the logic is now instead handled during isel pseudo expansion. Review: Ulrich Weigand Differential Revision: https://reviews.llvm.org/D111729
-
Max Kazantsev authored
Replace check with if ((ExitIfTrue && CI->isZero()) || (!ExitIfTrue && CI->isOne())) with equivalent and simpler version if (ExitIfTrue == CI->isZero())
-
Max Kazantsev authored
Check lightweight getter condition before calling all_of.
-
Ben Shi authored
Opitimize immediate materialisation in the following way if profitable: 1. Use BCLRI for upper 32 bits if the lower 32 bits are negative int32. 2. Use BSETI for upper 32 bits if the lower 32 bits are positive int32. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D111508
-
Abinav Puthan Purayil authored
The 24-bit mul intrinsics yields the low-order 32 bits. We should only do the transformation if the operands are known to be not wider than 24 bits and the result is known to be not wider than 32 bits. Differential Revision: https://reviews.llvm.org/D111523
-
Ben Shi authored
Use LUI+SLLI.UW to compose the upper bits instead of LUI+SLLI. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D111705
-
Lang Hames authored
SimpleRemoteEPC notionally allowed subclasses to override the createMemoryManager and createMemoryAccess methods to use custom objects, but could not actually be subclassed in practice (The construction process in SimpleRemoteEPC::Create could not be re-used). Instead of subclassing, this commit adds a SimpleRemoteEPC::Setup class that can be used by clients to set up the memory manager and memory access members. A default-constructed Setup object results in no change from previous behavior (EPCGeneric* memory manager and memory access objects used by default).
-
Shoaib Meenai authored
If the parameter had been annotated as nonnull because of the null check, we want to remove the attribute, since it may no longer apply and could result in miscompiles if left. Similarly, we also want to remove undef-implying attributes, since they may not apply anymore either. Fixes PR52110. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D111515
-
- Oct 13, 2021
-
-
Mircea Trofin authored
The tests that exercise the 'release' mode, where the model is AOT-ed, check the output has certain properties, to validate that, indeed, a different policy from the default one was exercised. For determinism, we can't reliably check that output for an arbitrary learned policy, since it could be that policy happens to mimic the default one in that particular case. This patch adds a requirement that those tests run only when the model is autogenerated (e.g. on build bots). Differential Revision: https://reviews.llvm.org/D111747
-
Philip Reames authored
This extends the foldOpIntoPhi code used when visiting a freeze user of a phi to allow any non-undef/poison operand as opposed to only non-undef/poison constants. This lets us hoist a freeze in the increment of an IV into the preheader in many cases. Differential Revision: https://reviews.llvm.org/D111744
-
Martin Storsjö authored
After 8fc7a907, this loop does the same as a plain `std::replace`. Also clarify the comment about what this function does. Differential Revision: https://reviews.llvm.org/D111730
-
Roman Lebedev authored
`X86TTIImpl::getGSScalarCost()` has (at least) two issues: * it naively computes the cost of sequence of `insertelement`/`extractelement`. If we are operating not on the XMM (but YMM/ZMM), this widely overestimates the cost of subvector insertions/extractions. * Gather/scatter takes a vector of pointers, and scalarization results in us performing scalar memory operation for each of these pointers, but we never account for the cost of extracting these pointers out of the vector of pointers. Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D111222
-
Sjoerd Meijer authored
Even if there are no interesting functions, the SCCP solver would still run before bailing. Now bail earlier, avoid running the solver for nothing. Differential Revision: https://reviews.llvm.org/D111645
-
Arthur Eubanks authored
Following D110451, we need to make sure to support 64 bit values.
-
Joe Nash authored
NFC. This check does not verify any functional property since size 8 was added. Remove it for simplicity. Reviewed By: rampitec Differential Revision: https://reviews.llvm.org/D111737 Change-Id: Ifd7cbd324a137f939d8dc04acb8fbd54c9527a42
-
Kai Nacke authored
This PR implements the save of the XPLINK callee-saved registers on z/OS. Reviewed By: uweigand, Kai Differential Revision: https://reviews.llvm.org/D111653
-
Philip Reames authored
This is a follow on for D111675 which implements the gep case. I'd originally left it out because I was hoping to actually implement the inrange todo, but after a bit of staring at the code, decided to leave it as is since it doesn't effect this use case (i.e. instcombine requires the op to freeze to be an instruction). Differential Revision: https://reviews.llvm.org/D111691
-
Jay Foad authored
This has a couple of benefits: 1. It can sometimes fix clusters that got broken apart when the register allocator inserted a copy. 2. Post-RA scheduling does not have to worry about increasing register pressure, which in some cases gives it more freedom to reorder instructions. Testing on a collection of 10,000 graphics shaders compiled for gfx1010 showed: - The average length of each run of one or more load instructions increased by about 1%. - The number of runs of two or more load instructions increased by about 4%. Differential Revision: https://reviews.llvm.org/D111646
-
Jeremy Morse authored
In D110173 we start using the existing LLVM IDF calculator to place PHIs as we reconstruct an SSA form of machine-code program. Sadly that's slower than the old (but broken) way, this patch attempts to recover some of that performance. The key observation: every time we def a register, we also have to def it's register units. If we def'd $rax, in the current implementation we independently calculate PHI locations for {al, ah, ax, eax, hax, rax}, and they will all have the same PHI positions. Instead of doing that, we can calculate the PHI positions for {al, ah} and place PHIs for any aliasing registers in the same positions. Any def of a super-register has to def the unit, and vice versa, so this is sound. It cuts down the SSA placement we need to do significantly. This doesn't work for stack slots, or registers we only ever read, so place PHIs normally for those. LiveDebugValues choses to ignore writes to SP at calls, and now have to ignore writes to SP register units too. Differential Revision: https://reviews.llvm.org/D111627
-
Sanjay Patel authored
-
Sanjay Patel authored
This is NFC-intended for scalar code. There are still unnecessary m_ConstantInt restrictions in surrounding code, so this is not a complete fix. This prevents regressions seen with a planned follow-on to D111410.
-
Jeremy Morse authored
Old versions of gcc want template specialisations to happen within the namespace where the template lives; this is still present in gcc 5.1, which we officially support, so it has to be worked around.
-
Jeremy Morse authored
InstrRefBasedLDV used to try and determine which values are in which registers using a lattice approach; however this is hard to understand, and broken in various ways. This patch replaces that approach with a standard SSA approach using existing LLVM utilities. PHIs are placed at dominance frontiers; value propagation then eliminates un-necessary PHIs. This patch also adds a bunch of unit tests that should cover many of the weirder forms of control flow. Differential Revision: https://reviews.llvm.org/D110173
-
Kerry McLaughlin authored
This patch adds patterns to match the following with INC/DEC: - @llvm.aarch64.sve.cnt[b|h|w|d] intrinsics + ADD/SUB - vscale + ADD/SUB For some implementations of SVE, INC/DEC VL is not as cheap as ADD/SUB and so this behaviour is guarded by the "use-scalar-inc-vl" feature flag, which for SVE is off by default. There are no known issues with SVE2, so this feature is enabled by default when targeting SVE2. Reviewed By: david-arm Differential Revision: https://reviews.llvm.org/D111441
-
Simon Pilgrim authored
-
Heejin Ahn authored
This makes Wasm EH work with dynamic linking. So far we were only able to handle destructors, which do not use any tags or LSDA info. 1. This uses `TargetExternalSymbol` for `GCC_except_tableN` symbols, which points to the address of per-function LSDA info. It is more convenient to use than `MCSymbol` because it can take additional target flags. 2. When lowering `wasm_lsda` intrinsic, if PIC is enabled, make the symbol relative to `__memory_base` and generate the `add` node. If PIC is disabled, continue to use the absolute address. 3. Make tag symbols (`__cpp_exception` and `__c_longjmp`) undefined in the backend, because it is hard to make it work with dynamic linking's loading order. Instead, we make all tag symbols undefined in the LLVM backend and import it from JS. 4. Add support for undefined tags to the linker. Companion patches: - https://github.com/WebAssembly/binaryen/pull/4223 - https://github.com/emscripten-core/emscripten/pull/15266 Reviewed By: sbc100 Differential Revision: https://reviews.llvm.org/D111388
-
Lang Hames authored
Negative deltas for LDRLiteral19 have their high bits set. If these bits aren't masked out then they will overwrite other instruction bits, leading to a bogus encoding. This long-standing relocation bug was exposed by e50aea58, "[JITLink][ORC] Major JITLinkMemoryManager refactor.", which caused memory layouts to be reordered, which in turn lead to a previously unseen negative delta. (Unseen because LDRLiteral19s were only created in JITLink passes where they always pointed at segments that were layed-out-after in the old layout). No testcase yet: Our existing regression test infrastructure is good at checking that operand bits are correct, but provides no easy way to test for bad opcode bits. I'll have a think about the right way to approach this. https://llvm.org/PR52153
-
Visa Hankala authored
The mips-specific includes have been unnecessary ever since the __clear_cache() builtin replaced cacheflush(). Differential Revision: https://reviews.llvm.org/D111486
-
Philip Reames authored
The newly introduced API for checking whether poison comes solely from flags which can be dropped was out of sync. This was noticed by a reviewer post commit. For the moment, disable the floating point flags. In a follow up change, I plan to add support in dropPoisonGeneratingFlags, but that deserves to be a change of it's own.
-
Ben Shi authored
Do the following optimization for immediate materialisation: 1. For values in range 0xffffffff 7fffffff ~ 0xffffffff 00000000, first generate the lower 32-bit with Val|0x80000000 (which is expected be an int32), then emit (BCLRI r, 31). 2. For values in range 0x80000000 ~ 0xffffffff, first generate the lower 32-bit with Val&~0x80000000 (which is expected to be an int32), then emit (BSETI r, 31). Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D111532
-
Fangrui Song authored
GCC 9.1 removed Intel MPX support. Linux kernel removed MPX in 2019. glibc 2.35 will remove MPX. Our support is limited: we support assembling of bndmov but not bnd. Just remove it. Reviewed By: pengfei, skan Differential Revision: https://reviews.llvm.org/D111517
-