search for: hoisted

Hello. Does anybody have an idea why I'm getting the error below when using llc with arguments -O1 -disable-cgp? Note that this error is not given when using llc -O0. (I'd like to mention 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

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 BITCAST as a no-op and eventually users of the GV fold the relocation...

...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 int: SS#0 [16r,592B:0) 0 at x hoisted: 16r STbo %vreg19, <fi#0> Second below: Checking redundant spills for 0 at 16r in %vreg19 [16r,96B:0)[144B,240B:1)[296r,416B:2)[416B,456r:3)[472r,592B:4) 0 at 16r 1 at 144B-phi 2 at 296r 3 at 416B-phi 4 at 472r Merged to stack int: SS#0 [16r,592B:0) 0 at x hoisted: 16r STbo %vreg1...

...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 local pointer, the load can not be hoisted either. However, with this example: int gv = 3;//global var int func(int n) { int i; int a[1000]; for (i = 0; i < n; ++i) { a[i] += gv; // load from the @gv pointer, hoist } } load for the global var...

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

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

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

...lues > > 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 > > 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 BITCAST as...

...caa 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 > _______________________________________________ > LLVM Develope...

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

...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 -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

2017-04-01 15:59 GMT+02:00 Piotr Padlewski <piotr.padlewski at gmail.com>: > > > 2017-03-31 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

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 loading instructions. There are maybe three 'solutions' to this problem, maybe more....

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

..., Mod/Ref Pointers: (float* %res, 4) ===-------------------------------------------------------------------------=== ... Statistics Collected ... ===-------------------------------------------------------------------------=== 7 licm - Number of instructions hoisted out of loop 4 licm - Number of load insts hoisted or sunk 32 memory-builtins - Number of load instructions with unsolved size and offset The result is not good. The loop contains redundant computation. Clearly, Basicaa works out wrong AliasSet 'may alias' (arrayidx, arrayidx1...

...perform the add before invoking either handler); is that more or less the idea? That makes sense, thanks. Yep. In the worst case, we could model code before landing pad dispatch as a cleanup handler, but I think the most common transforms are easily undone. Consider your example where a + b gets hoisted before the catch dispatch. Adds have no side effects, so we can freely sink them back down into the catch handler once we start outlining. Things that are hard to move, like loads and stores to unknown memory locations, cannot be hoisted over the llvm.eh.begincatch() call in the first place. It sh...

...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 (volatile store, > syscall etc.)? All of those can't be hoisted or sunk -- we have to > make sure that they execute in semantically the same conditions that > they did in the original program. > > may-throw is, AFAIK, worse. They act as barriers to sinking *other things*. You cannot sink a store past a may-throw, or hoist a load above them. You can...

...load void (%struct.A*)**, void (%struct.A*)*** %b, align 8, !invariant.group !0, !dereferenceable !1 !1 = !{i64 8} Then it doesn't help either, because LICM drops !dereferencealbe metadata when hoisting (and adding it would be invalid, because we don't know if it is also dereferenceable in hoisted block). On the other hand, after performing my LICM of !invariant.group load, GVN hoists the second load and I am not sure why it is legal then. Any ideas? Piotr -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachmen...