Displaying 20 results from an estimated 1024 matches for "hoists".
Did you mean:
hoist
2017 Feb 21
2
Error at Pre-regalloc Machine LICM: "getVRegDef assumes a single definition or no definition"' failed.
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
2015 Dec 11
4
trouble hoisting GlobalValues
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
2016 Dec 22
1
Spill hoisting on RAL: looking for some debugging ideas
...like
AARCH64 there are a plenty of callee-saved registers and this bug can
not be easily reproduced, so I am trying to understand why spill
hoisting do such things in mine case.
I found InlineSpiller::eliminateRedundantSpills that seems to be in
charge. I traced code down to problem. First time it hoists vreg19 ok.
Second time it sees MI, created first time, sees slot index, but then
on line:
if (LI->getVNInfoAt(Idx) != VNI) continue;
it continues.
(gdb) p *VNI
$21 = {id = 4, def = {lie = {Value = 260284292}}}
(gdb) p *LI->getVNInfoAt(Idx)
$22 = {id = 0, def = {lie = {Value = 260282980}}}...
2011 Feb 07
3
[LLVMdev] A question about LICM (Loop Invariant Code Motion)
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
2012 Mar 08
1
[LLVMdev] "Machine LICM" for Constants?
...ristic seems reasonable, but doesn't seem to do the right thing
in this case. Hacking the instruction itineraries to make the
instructions not seem cheap doesn't seem like the right answer either.
I'm guessing the motivation for this heuristic is that, in a loop with
many possible hoists, some cheap and some expensive, 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 ins...
2015 Jan 08
4
[LLVMdev] Machine LICM and cheap instructions?
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::
2004 May 02
1
[LLVMdev] hoisting problem.
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
2012 Mar 07
2
[LLVMdev] "Machine LICM" for Constants?
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
2015 Dec 11
3
trouble hoisting GlobalValues
----- Original Message -----
> 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
2015 Feb 11
3
[LLVMdev] question about licm
----- Original Message -----
> 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
2012 Mar 07
0
[LLVMdev] "Machine LICM" for Constants?
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,
2016 Aug 05
3
GVN Hoist moving a store across load
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
2017 Apr 03
4
Dereferenceable load semantics & LICM
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
2015 Feb 11
2
[LLVMdev] question about licm
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,
2015 Feb 03
2
[LLVMdev] RFC: Constant Hoisting
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
2019 Nov 03
2
InlineSpiller - hoists leave virtual registers without live intervals
/// 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
2013 Nov 11
2
[LLVMdev] What's the Alias Analysis does clang use ?
Hi, LLVM community:
I found basicaa seems not to tell must-not-alias for __restrict__ arguments
in c/c++. It only compares two pointers and the underlying objects they
point to. I wonder how clang does alias analysis
for c/c++ keyword restrict.
let assume we compile the following code:
$cat myalias.cc
float foo(float * __restrict__ v0, float * __restrict__ v1, float *
__restrict__ v2, float *
2015 Feb 12
2
[LLVMdev] RFC: Native Windows C++ exception handling
> 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 raise an exception (else we'd return 0 from foo), the exception must
2016 Jul 15
3
RFC: Strong GC References in LLVM
On Fri, Jul 15, 2016 at 12:21 PM, Sanjoy Das <sanjoy at playingwithpointers.com
> wrote:
> Hi Daniel,
>
> Daniel Berlin wrote:
> > As a starting point, LLVM will conservatively not speculate such
> > loads and stores; and will leave open the potential to upstream
> > logic that will have a more precise sense of when these loads
> and
2017 Mar 31
2
Dereferenceable load semantics & LICM
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 = tail...