search for: hoist

...ion also I'm using custom Instruction selection for BUILD_VECTOR, which gets converted in my back end's machine instrution VLOAD_D, although the custom code seems to always select instructions in a valid way.) ******** Pre-regalloc Machine LICM: Test ******** Entering BB#4 Hoist non-reg-pressure: %vreg50<def> = VLOAD_D 1; MSA128D:%vreg50 dbg:IfVectorize.c:37:16 Hoisting %vreg50<def> = VLOAD_D 1; MSA128D:%vreg50 dbg:IfVectorize.c:37:16 from BB#4 to BB#3 Hoist non-reg-pressure: %vreg51<def> = VLOAD_D 0; MSA128D:%vreg51 Hoisting %vreg51&...

Hello LLVM, To reduce the code-size cost of relocations, I'm trying to hoist GlobalValues that are used many times. A new pass hides each hoisted GV behind a BITCAST in the dominating BB. The pass then updates users with the output of the BITCAST. This pass works properly AFAICT. The problems come in instruction selection. SelectionDAGBuilder::visitBitCast() treats the...

Hi, I am debugging private backend and faced interesting problem: sometimes spill hoisting creates double stores. (some output from -debug-only=regalloc). First hoisting: Checking redundant spills for 0 at 16r in %vreg19 [16r,144B:0)[144B,240B:1)[240B,280r:2)[296r,416B:3)[416B,456r:4)[472r,592B:5) 0 at 16r 1 at 144B-phi 2 at 240B-phi 3 at 296r 4 at 416B-phi 5 at 472r Merged to stac...

Hi, I recently looked into the LICM(Loop Invariant Code Motion) pass of LLVM and got a question about hoist load instruction to loop preheader. I would like to show two examples: Example 1: int func(int n, int *fp) { int i; int a[1000]; for (i = 0; i < n; ++i) { a[i] += *fp; // load from *fp pointer, no hoist } } Here, load *fp CAN NOT be hoisted to loop preheader. If replace *fp with an lo...

...like the problem as of SVN HEAD is that the lui and ori instructions in Mips are considered cheap (1-cycle def-use latency) by MachineLICM::IsCheapInstruction(), but are not trivially materializable because their register operands are not always available. This makes MachineLICM::IsProfitableToHoist() return false, preventing the hoist even though MachineLICM::IsLoopInvariantInst() returns true. The comment in IsProfitableToHoist() is: // If the instruction is cheap, only hoist if it is re-materilizable [sic]. LICM // will increase register pressure. It's probably not worth it if the...

Hi everyone, The MachineLICM pass has a heuristic such that, even in low-register-pressure situations, it will refuse to hoist "cheap" instructions out of loops. By default, when an itinerary is available, this means that all of the defined operands are available in at most 1 cycle. ARM overrides this, and provides this more-customized definition: bool ARMBaseInstrInfo:: hasLowDefLatency(const InstrItineraryData...

Hi, First, sorry in advance for pasting code like this :) I'm doing a simple optimization pass for a cs326 class project. The pass in question is LICM, and I'm getting an assertion when I try to hoist an instruction. My hoist function is below. I dont think I need that copying in there, that was just something people on the newsgroup suggested. I get the same assertion regardless. So, the code: ======================================== ======================================== bool L...

...imilar to Mips, where large immediates are loaded into registers with 2 instructions, 1 to load the MSBits and 1 to load the LSBits. I've noticed a recurring pattern where, despite low register pressure, these constants will be rematerialized in every iteration of a loop, rather than being hoisted. Here's an example using the mips-unknown-unknown target and Clang/LLVM HEAD. From newlib's implementation of strncat: #define DETECTNULL(X) (((X) - 0x01010101) & ~(X) & 0x80808080) while (!DETECTNULL (*aligned_s1)) aligned_s1++; This loop gets lowered under -O3 to: $BB0...

...t; From: "Rafael Espíndola via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Steve King" <steve at metrokings.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Friday, December 11, 2015 4:28:33 PM > Subject: Re: [llvm-dev] trouble hoisting GlobalValues > > On 11 December 2015 at 16:53, Steve King via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > Hello LLVM, > > To reduce the code-size cost of relocations, I'm trying to hoist > > GlobalValues that are used many times. A new pass hides eac...

...ge ----- > From: "Ashutosh Nema" <Ashutosh.Nema at amd.com> > To: "songlh" <songlh at cs.wisc.edu>, llvmdev at cs.uiuc.edu > Sent: Wednesday, February 11, 2015 3:20:27 AM > Subject: Re: [LLVMdev] question about licm > > Hi, > > LICM can only hoist instructions which dominates all loop exit > blocks. > In this case 'upper[j]' is not dominating exit block as its appearing > in second operand of logical AND operator. > > Prior to hoisting it check for condition in 'isGuaranteedToExecute' > and it decide not to...

Yes machine-licm can and should hoist constant materialization instructions out of the loop. If it's not doing that, it's probably because the target is not modeling the instruction correctly. I would walk through MachineLICM::IsLoopInvariantInst() in the debugger to figure it out. You can also try compiling the same bitcode fo...

Hi, I have a scenario, roughly like this: if (...) { ... = *x *x = 0 } else { ... = *x *x = 0 } The two sides are functionally different, but both load some value and then set it to 0. After GVN Hoist, I get: *x = 0 if (...) { ... = *x } else { ... = *x } That is, the store was hoisted above the loads. The code is not exactly public, so I can't just attach it as a testcase, but it seems like some simple check is missing somewhere. Does this ring a bell? -Krzysztof...

...23:20 GMT+02:00 Sanjoy Das <sanjoy at playingwithpointers.com>: > >> Hi Piotr, >> >> On March 31, 2017 at 1:07:12 PM, Piotr Padlewski >> (piotr.padlewski at gmail.com) wrote: >> > [snip] >> > Do I understand it correctly, that it is legal to do the hoist because >> all >> > of the instructions above %vtable does not throw? >> >> Yes, I think you're right. HeaderMayThrow is a conservative >> approximation, and the conservativeness is biting us here. >> >> > Are there any plans to fix it in the fut...

hi, I applied licm with basicaa on the following codes: int j = atoi(argc[1]); int lower[] = {10, 9, 8, 7, 6, 5, 4, 3, 2, 1}; int upper[] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}; for(i = lower[j]; a[i] < 100 && i < upper[j]; i ++); I notice that upper[j] is not hoisted out from the loop. Is this because j could be larger than 10? Thanks a lot! Best, Linhai

I've had a bug/pessimization which I've tracked down for 1 bit bitmasks: if (((xx) & (1ULL << (40)))) return 1; if (!((yy) & (1ULL << (40)))) ... The second time Constant Hoisting sees the value (1<<40) it wraps it up with a bitcast. That value then gets hoisted. However, the first (1<<40) is not bitcast and gets recognized as a BT. The second doesn't get recognised because of the hoisting. The result is some register allocation and unnecessary constant lo...

/// Optimizations after all the reg selections and spills are done. void InlineSpiller::postOptimization() { HSpiller.hoistAllSpills(); } Seems a problematic function to me, as hoistAllSpills() uses TII.storeRegToStackSlot() to insert new spills. The problem is, TII.storeRegToStackSlot is allowed to create new virtual registers, which can not be allocated a range as this whole thing is called _after_ all reg selection...

...]; float z = v2[1]; res = x * 0.67 + y * 0.17 + z * 0.16; t[i] = res; } return res; } $clang -emit-llvm -c myalias.cc -o myalias.bc Clearly each argument has attribute 'noalias' in LLVM IR. I plan to use basicaa and licm to hoist all load/store of x/y/z and res to ahead of loop. $ opt -basicaa -licm -print-alias-sets myalias.bc -o myalias.opt.bc -stats -debug-only=licm LICM hoisting to entry: %1 = load float** %v0.addr, align 8 LICM hoisting to entry: %arrayidx = getelementptr inbounds float* %0, i64 1 LICM hoisti...

> We'd have to hoist a + b to somewhere that dominates L1 and L2. I think the only BB in your program that dominates is the entry block I don't follow. What path do you see from entry to either L1 or L2 that doesn't pass through the indirectbr? In order to reach either L1 or L2, the call to maybe_throw() must...

...ts of patches fixing may-throw > > places, and extrapolate to more places). > > As I said, I'm only proposing a "don't speculate" flag, so this does > not (?) apply. > As long as it applies only to the instructions, and they do not act as "barriers" to hoisting/sinking, then yes, it should not apply. (In theory it still means things have to look at instructions, but they had to look at them anyway at that point :P) > > However, I didn't quite understand your point about may-throw -- how > is may-throw different from a generic side-effect...

Hi all, I have a question about dereferenceable metadata on load instruction. I have a patch (https://reviews.llvm.org/D31539) for LICM that hoists loads with !invariant.group. The motivation example is devirtualization: struct A { virtual void foo(); }; int bar(); void indirect(A &a) { while(bar()) a.foo(); } With -O2 -fstrict-vtable-pointers we get: define void @hoist(%struct.A* dereferenceable(8)) { entry: %call1 = tai...