similar to: About the concept of "materialization"

Bruce, Thanks for the explanation. But based on my inspection on the source code, it seems that materialization is related to lazily reading LLVM objects (Module, Function, etc.) into the memory from bitcode files, which is possibly useful during LTO. I’m not sure though. Pei From: <bruce.hoult at gmail.com> on behalf of Bruce Hoult <bruce at hoult.org> Date: Wednesday, June 28,

OK. About the error it’s a long story, so it’s probably better to pin some source code here. Below is a piece of code related to my problem, clipped from lib/Transforms/Utils/ValueMapper.cpp. I was wondering what “materialized” means here. Value *Mapper::mapBlockAddress(const BlockAddress &BA) { Function *F = cast<Function>(mapValue(BA.getFunction())); // F may not have

Hello Developers, I am working with my other batchmates to improve register remat in LLVM. We want to remat live ranges made of multiple instruction. Just to support our proposal here is a simple example that currently remat does not cover $ cat ~/tmp/tl.c void foo(long); void bar() { for (int i = 0; i < 1600; ++i) foo(3494348345984503943); } $ clang -O3 -S -o - ~/tmp/tl.c -target

On Apr 16, 2007, at 1:17 PM, David Greene wrote: > Chris Lattner wrote: >> On Thu, 12 Apr 2007, Fernando Magno Quintao Pereira wrote: >>>> I'm definitely interested in improving coalescing and it sounds >>>> like >>>> this would fall under that work. Do you have references to papers >>>> that talk about the various algorithms?

Evan Cheng wrote: > Obviously, smart heuristics can make a big difference here (estimated > register pressures, etc.) But the more important thing is how the > passes down stream can recover from the earlier mistakes. By this, we > mean live range splitting and re-materialization. Can you explain this a little more? Do you mean that neither live range splitting nor

On Tue, 17 Apr 2007, David Greene wrote: > Evan Cheng wrote: >> Obviously, smart heuristics can make a big difference here (estimated >> register pressures, etc.) But the more important thing is how the >> passes down stream can recover from the earlier mistakes. By this, we >> mean live range splitting and re-materialization. > > Can you explain this a little

Thanks Florian. Tim you said: > Some cases can be undone by rematerialization, but not all, and it can involve a lot of effort which increases compile time. Do you have examples of cases where rematerialization is not possible? We are interested in learning about any previous attempts at trying to address the issue in RA. Have you tried it? Bardia Mahjour Compiler Optimizations IBM Toronto

Yes, but my point is that there would be some overhead to do cast the <N x i1> vectortype to an integerNty. Is there any good way to check not all of these N bits in the vectortype are 0s? On Fri, Apr 10, 2015 at 5:37 PM, Bruce Hoult <bruce at hoult.org> wrote: > Sure, if you actually just want an i1 saying whether or not at least one > bit is set to 1, then comparing against 0

I see. My CPU is a general Core i7 Ivy bridge CPU. On Fri, Apr 10, 2015 at 6:48 PM, Bruce Hoult <bruce at hoult.org> wrote: > I suppose that depends on your CPU. Do you even have a CPU that supports > operations on <N x i1> as packed bits in vector registers? > > > On Sat, Apr 11, 2015 at 12:43 PM, zhi chen <zchenhn at gmail.com> wrote: > >> Yes, but my

On Mon, Sep 19, 2016 at 6:21 PM, James Molloy <james at jamesmolloy.co.uk> wrote: > Hi, > > I've been looking at this myself for ARM, and came up with a much simpler > solution: lower immediate materializations to a post-RA pseudo and expand > the chain of materialization instructions after register allocation / > remat. Remat only sees one instruction with no

Hi all, Virtual ISAs such as WebAssembly and NVPTX use infinite virtual register sets instead of traditional phsyical registers. PrologEpilogInserter is run after register allocation and asserts that all virtuals have been allocated but doesn't otherwise depend on this if scavenging is not needed. We'd like to use the target-independent PEI code for WebAssembly, so we're proposing a

----- Original Message ----- > From: "Quentin Colombet via llvm-dev" <llvm-dev at lists.llvm.org> > To: "vivek pandya" <vivekvpandya at gmail.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Nirav Rana" > <h2015087 at pilani.bits-pilani.ac.in>, "Matthias Braun" > <matze at braunis.de> > Sent:

Thanks, Bruce. So, what is the easiest way to check if there is any bit set to 1 in a <N x i1> vector type? I used bitcast instruction to cast it into "iN" first and them compare iN to 0. Do you have a better way to do it? Thanks again. On Fri, Apr 10, 2015 at 5:22 PM, Bruce Hoult <bruce at hoult.org> wrote: > LLVM doesn't have a "logical neg" (or

On Apr 17, 2007, at 2:24 PM, Chris Lattner wrote: > On Tue, 17 Apr 2007, David Greene wrote: >> Evan Cheng wrote: >>> Obviously, smart heuristics can make a big difference here >>> (estimated >>> register pressures, etc.) But the more important thing is how the >>> passes down stream can recover from the earlier mistakes. By >>> this, we

Thanks for the quick answer Bruce. So far as I can tell (from a quick read), this is really for integrated assemblers/disassemblers - but we use an external assembler. When invoking clang we would provide ‘-mcpu=chip_v1’ or ‘-mcpu=chip_v2’, and the mnemonic ‘LD32’ is only valid when compiling for ‘chip_v1’, while ‘LD.32’ is only valid when compiling for ‘chip_v2’. But I will study the

--------------------------- Wed, Sep 11, 2019: --------------------------- - LICM vs Loop Sink Strategy (Whitney) - LICM and SCEV expander host code with no regards to increased live-ranges. This is a long standing issue where historically preference has been to keep LICM more aggressive. - Two questions from IBM side: a. This problem is not specific to the POWER

That breaks the whole IR idea of using alloca to allocate/denote space for local variables, and then optimize those into SSA values when optimization proves that is OK. Also, for a lot of things, that attribute is simply impossible to implement. Any value that is live across a call needs to be spilled to memory. You cannot put an unspillable value in a callee preserved register, because you

Hello LLVM Developers, We are working on extending currently available register rematerialization to include cases where sequence of multiple instructions is required to rematerialize a value. We had a discussion on this in community mailing list and link is here: http://lists.llvm.org/pipermail/llvm-dev/2016-September/subject.html#104777 >From the above discussion and studying the code we

On Wed, Dec 9, 2015 at 3:02 PM Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Derek Schuff via llvm-dev" <llvm-dev at lists.llvm.org> > > To: llvm-dev at lists.llvm.org > > Sent: Wednesday, December 9, 2015 4:31:31 PM > > Subject: [llvm-dev] Allowing virtual registers after register allocation > > > >

To say this first: This whole discussion about using virtregs until emit or having growable physregs is hard to argue without actually having experience trying to go either way. Problems when using virtregs throughout the backend until emit time: - The MC layer is using MCPhysReg (which is an uint16_t) and would need retrofitting to support virtregs - VirtRegs are assumed to have a definition,