similar to: IR question re: constants

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

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

Thanks for the tip! I looked into it and it looks 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

On 12/20/2017 03:49 PM, Alina Sbirlea via llvm-dev wrote: > +Philip to get his input too. > I've talked with George offline, and here's a summary: > > In D16875 <https://reviews.llvm.org/D16875>, the decision made was: > "The LLVM spec is ambiguous about whether we can hoist a non-volatile > load above a volatile load when the loads alias. It's probably

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 Krzysztof, Could I get some background info on reasoning about hoisting in the presence of volatile loads? I was looking at this testcase: test/Transforms/LICM/volatile-alias.ll Context: MemorySSA treats volatile loads as defs. I'm looking to better understand expected behavior in the presence of volatile accesses. More context: https://reviews.llvm.org/D40375. Thanks in advance, Alina

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,

The fact two IR values are defined the same way doesn't necessarily imply they are actually the same value. e.g. %a = load volatile i32, i32* %p %b = load volatile i32, i32* %p As Sanjoy said, though, it should always be legal to optimize all uses of different "freeze(%x)" values to use the same def - this is equivalent to choosing the same value for all freezes. It's just not

I'd like to suggest a different direction which should accomplish similar ends. I think it would make sense to introduce an attribute: csecandidate. If we see a call-site "X" marked as csecandidate, it would imply that it can be replaced with any other call-site "Y" with the same arguments which dominate the call-site at "X". However, there are some cases that

On 12/20/2017 1:37 PM, Sanjoy Das wrote:> > Fwiw, I was under the impression that regular loads could *not* be > reordered with volatile loads since we could have e.g.: > > int *normal = &global_variable; > volatile int* ptr = 0; > int k = *ptr; // segfaults, and the signal handler writes to *normal > int value = *normal; > > and that we'd have

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

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

On 7/30/2013 11:44 PM, Chris Lattner wrote: > > The canonical form should be that loop invariants are hoisted. The canonical form should not depend on the knowledge as to what is invariant and what isn't. It has more to do with preserving certain "common" properties of a loop, such as header, preheader, latch branch, etc. > Optimizations should not depend on perfect

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

On Fri, Jun 15, 2007 at 04:16:57PM +0200, Florian Brandner wrote: > hi, > > > Florian Brandner wrote: > > Dan Gohman wrote: > >> On Wed, May 23, 2007 at 12:23:38AM -0700, Chris Lattner wrote: > >>> Right. The original Value*'s are preserved in the DAG, but dropped when > >>> MachineInstrs are created. We could add a machineoperand to

I'm current facing an issue related to AliasSetTracker/LICM: the transitive closure of the alias sets is materially more conservative than individual aliasing queries and this conservatism leads to generally worse optimization in LICM. For instance, consider this module: declare i32 @only_reads() readonly declare void @escape(i32*, i32*, i32*) define void @f(i32 %count) { entry: %a =

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

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

On Jul 31, 2013, at 6:53 AM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > On 7/30/2013 11:44 PM, Chris Lattner wrote: >> >> The canonical form should be that loop invariants are hoisted. > > The canonical form should not depend on the knowledge as to what is invariant and what isn't. It has more to do with preserving certain "common"