similar to: [LLVMdev] Post increment and register pressure

Hi Sundeep, I am also interested in the load-store lifting transformation. For static globals as-in your example, the transformation in general would rely on a better static global aliasing information that is currently in review http://reviews.llvm.org/D10059 For non-static globals, one problem with loop-based analysis alone is that in a popular embedded benchmark suite, you get serious gains

Hi, We are working on a research project whose objective is developing a pre-allocation scheduling algorithm that achieves the optimal balance between exploiting ILP (hiding latencies) and minimizing register pressure.  A prototype of our algorithm has been implemented and integrated into an experimental version of LLVM 2.9. Our algorithm is based on a combinatorial optimization approach, which

We have run an experiment in which we set all physical register limits to zero. The purpose of this experiment was estimating the potential impact of getting complete liveness info. The results of this experiment were better than the results that we got using the real physical limits (the total number of spills in CPU2006 was reduced), but the difference was not substantial. We took this as an

Hi Xing, The register pressure sets are basically concepts that tells you how may variables can live in register at the same time. This information is available for two different level of abstraction: per register class and per register unit. The register unit is the basic entity we use to represent a register. Tablegen generates all of that for you, so you do not need to worry about them.

Hello, In a previous email, Matthias mentioned that register pressure estimates in the machine scheduler are not absolute; they only account for the registers that are used in the block.I assume that he meant that registers that are live-through (both live-in and live-out) are not accounted for in register pressure calculations. If a register is either live-in or live-out but not both, it must be

Hi everyone, I'm looking through codes related to registered pressure tracking, mainly the source files 'RegisterPressure.h/cpp', 'MachineRegisterInfo.h/cpp', 'TargetRegisterInfo.h/cpp'. There is a concept I can hardly understand, the 'register pressure set'. Class 'TargetRegisterInfo' defines two virtual methods 'getRegClassPressureSets' and

On Aug 15, 2011, at 1:27 AM, Ghassan Shobaki wrote: > One factor that is causing our current register pressure estimate to be off is not being able to properly account for live-in and live-out registers (both virtual and physical). As far as we can tell, LLVM represents live-in regs with CopyFromReg instrs and live-out regs with CopyToReg instrs. However, it looks that in a given basic block,

Hello all, I am writing to get some feedback on an optimization that I would like to upstream. The basic idea is to localize global variables inside loops so that it can be allocated into registers. For example, transform the following sequence static int gbl_var; void foo() { for () { ...access gbl_var... } } into something like static int gbl_var; void foo() { int lcl_var;

Thank you for the answers, Jakob! That's really informative for someone who is still new to LLVM like me. Please see my responses below. -Ghassan  ________________________________ From: Jakob Stoklund Olesen <stoklund at 2pi.dk> To: Ghassan Shobaki <ghassan_shobaki at yahoo.com> Cc: "llvmdev at cs.uiuc.edu" <llvmdev at cs.uiuc.edu> Sent: Tuesday, August 16,

I am working on a project where we are integrating an existing pre-RA scheduler into LLVM and we are trying to match our peak register pressure values with the machine instruction schedulers values while using X86. I am finding some mismatches in test cases like the one attached. The registers "AH" and "AL" are live-out but not live-in and I don't see that they are defined

> On Aug 30, 2017, at 1:43 PM, Matthias Braun <matze at braunis.de> wrote: > > That means you cannot use the code from RegisterPressure.{cpp|h} to compute this. The other liveness analysis we have in llvm codegen is LiveIntervals (LiveItnervalAnalysis) which gives you a list of liveness segments of a given vreg (the same representation is used in most linear scan allocators even

I thought about a little bit more, I think adding Register pressure control in your patch or PRE may be the only choice. Because at least for this case I am looking at, what your patch did is created more relatively complex long live range, rematerialization is not smart enough to undo your change or at least without a lot of work, coalescing only create even longer live range not shorter,

On Wed, 15 Apr 2020 at 03:36, John Brawn <John.Brawn at arm.com> wrote: > > > Could you please point out what am I doing wrong in the patch ? > > It's because you're getting the function name by doing > callee->getName().str().c_str() > The str() call generates a temporary copy of the name which ceases to exist outside of this expression > causing the

Hi, Daniel: Thanks a lot for detailed background information, we are willing to provide the right fix, however it will take time, do you mind if you forward me the discussion you had 5 months ago? I may not be able to access it since I only joined ellvmdev list this week. I did some performance measurement last night, some of our critical benchmark degraded up to 30% with your patch, so we have

Hi All, I noticed LLVM target independent side is converting an ordered less than "setolt" into unordered greater than "setuge" operation. There are no target hooks to control going from the ordered mode into unordered. I am trying to figure out the best way to support unordered operation on Hexagon. We don't have a single instruction to do unordered operation. So we

On Jul 28, 2011, at 8:18 AM, Sundeep wrote: >>> 1. I checked out and built llvm, clang, and test-suite from svn tip. >> When I >>> run llvm/test *without* my changes on x86, I see 3 failures. Is it >> expected? >>> I was expecting svn tip on x86 to be clean. Is there a nightly >> regression >>> result available somewhere that I can check for

> Given what you are saying, you are also suggesting we are not rematerializing addressing computations where it is cheaper to do so. That seems pretty critical to good RA :P Yep, about 5 months ago I had a conversation about this too... it may even be the one you're referencing. Our remat is really conservative - it only rematerializes values that have zero input operands (move immediate

That should be literally impossible, which makes me think something was tested wrong The second patch i posted disables scalar pre (assuming you use -disable-pre) but not load pre. Since the patch you reverted touched only scalar pre, disabling scalar pre should *also* do the same thing. On Thu, Jul 16, 2015 at 5:43 PM, Lawrence <lawrence at codeaurora.org> wrote: > Hi, Daniel: >

> On Oct 13, 2017, at 1:46 PM, Matthias Braun <matze at braunis.de> wrote: > > Yes, I've run into the problem myself that the Pending queue isn't even checked with the tryCandidate() logic and so takes priority over all other scheduling decisions. > > I personally would be open to changes in this area. To start the brainstorming I could imagine that we move nodes

This conflict is with many optimizations incl. copy prop, coalescing, hoisting etc. Each could increase register pressure and with similar impact. Attempts to control the register pressure locally (within an optimization pass) tend to get hard to tune and maintain. Would it be a better way to describe eg in metadata how to undo an optimization? Optimizations that attempt to reduce pressure like