search for: hoisting

...k 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<def> = VLOAD_D 0; MSA128D:%vreg51 from BB#4 to BB#3 Can't remat / high reg-pressure...

...hind 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 BITCAST as a no-op and eventually users of the GV fold the relocation as if hoisting never happened. Experiments turning the BITCAST into a copytoreg failed and anyway I feel like I'm just shooting in the dark. Can anyone can suggest a strategy for lowering a hoisted GV? The end result should be that the GV materializes as a simple move-immediate to register. Thanks, -steve

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 stack i...

...*fp: **LICM.cpp if (isLoopInvariantInst(I) && canSinkOrHoistInst(I) && isSafeToExecuteUnconditionally(I)) // invokes I->IsSafeToSpeculativelyExecute() hoist(I); But I do not know why we need to treat fp/local pointer different with global pointer here. I think hoisting fp/local pointers should be fine if they are loop invariant and does not alias with other pointers.. Anyone can help me to figure this out? Thank you very much. -Yuelu, UIUC

...pensive, we would prefer to hoist the expensive ones rather than wasting all our register slack on the cheap ones. Is there another way to accomplish this goal while still performing the hoist in situations where register pressure is low enough? Say, considering the instructions in a loop for hoisting in descending order of cost, rather than in program order? Note that ARM gets around this by creating a pseudo-instruction for 32-bit immediate loads (MOVi32imm) , rather than putting a pattern directly in ARMInstrInfo.td. This fused instruction *is* rematerializable (since it defines the ent...

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::

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

Hi All, I work on a backend for a target similar 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

...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 each &...

...gt; 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 hoist it. > > <File: LICM.cpp> > 666 bool LICM::isGuaranteedToExecute(Instruction &Inst) { > 667 > 668 // We have to check to make sure that the instruction dominates > all > 669...

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 for a target like ARM or X86 as a comparison. Evan On Mar 7,

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

...IsBeforeThrowingInst; >> >> -- Sanjoy >> > I was thinking about something very similar and it seems to be a good > approach to me because it has much lower complexity. > > In the review Sanjoy correctly spoted that I am not discarding > invariant.group metadata when hoisting, which is incorrect in general. > This generates a big problem to devirtualization, because discarding > metadata when hoisting vtable load might be worse than not hoisting when > there might be another load/store with !invariant.group dominating it > (e.g. after inlining). > > I...

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,

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 loadi...

...he intention is that you can... but I do not see how a hoist can ever pass verification/compile correctly. Am I doing something incorrectly here? Or are hoistable spills just that rare on GPU code that it's never come up? As a side note, compiler option "-disable-spill-hoist" (DisableHoisting) is referenced in exactly zero places, so if anyone in a similar situation finds this post, maybe don't bother testing with that flag just yet. :)

...g -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 hoisting to entry: %3 = load float** %v1.addr, align 8 LICM hoisting to entry: %arrayidx1 = getelementptr inbounds float* %1, i64 1 LICM hoisting to entry: %5 = l...

...+ b) + 1; } and suppose that nothing gets moved around before outlining. Then, after outlining, the landingpad will be followed by an eh.actions call and then an indirect branch that targets L1 and L2, correct? Do we need to worry that a late codesize optimization might want to merge the adds by hoisting them up above the indirect branch? If that happened, wouldn't it get skipped over if an exception were raised? 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. In the IR, the fake 'indirectbr' ins...

...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 (v...

...; preds = %while.body br label %while.end while.end: ; preds = %while.end.loopexit, %entry ret void } We know that the load of vptr and virtual function will not change in this loop, which is indicated by !invariant.group. Hoisting invariant.group load is legal because %b is dereferenceable, but hoisting next load is illegal by LICM because it can't prove that %vtable is dereferenceable. But if I add dereferenceable metadata on vtable load like %vtable = load void (%struct.A*)**, void (%struct.A*)*** %b, align 8, !invari...