similar to: [LLVMdev] Register allocation of stack slots

On Mar 25, 2009, at 11:21 AM, Christian Sayer wrote: > Hi all, > for my target, the register allocator tends to make use of few (i.e. > it seems one single) registers when allocating stack slots to > registers. This happens only to function locals (allocas) - > allocation for e.g. function arguments passed by the stack work fine. > For example, the debug output of the

Dan, thanks for your hints about the post-RA scheduler. However, I have difficulties creating a reasonably small and concise testcase for the problem I described, and it's on my own target anyway. In principle, I see the following: %theStruct = type { %theStruct2, %theStruct3, i16, ... } define void @f1(%theStruct* %tmp) { // initialize some locals %a= alloca i16, align 2 store i16 1,

Hello all, For the past couple of months I've been writing a new llvm backend for Renesas RL78 MCU: https://www.renesas.com/eu/en/products/microcontrollers-microprocessors/rl78.html The software manual which contains all there is to know about RL78 is available here: https://www.renesas.com/us/en/doc/products/mpumcu/doc/rl78/r01us0015ej0220_rl78.pdf The motivation behind this is the

Hi David, Thank for very much for your reply! I got a reply on the clang mailing list in April from Dmitri: http://lists.llvm.org/pipermail/cfe-dev/2020-April/065115.html and following his advice “attaching pragmas as attributes to functions” I managed to do it, it was actually quite easy. >>Compatibility with an existing compiler is usually compelling - are the compilers you're

<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div dir="ltr" >Matthias,</div> <div dir="ltr" > </div> <div dir="ltr" >Thanks for the response.</div> <div

lib/CodeGen/RegAllocLocal.cpp:38: warning: 'NumFolded' defined but not used This has been introduced because of r46821. However, maybe removing just the variable isn't enought, because the comments in the section that got modified by 46821 are not optimal: if (PhysReg) { // Register is available, allocate it! assignVirtToPhysReg(VirtReg, PhysReg); } else { // No

I am hitting this assert in LLVM 2.5: /// spillPhysRegAroundRegDefsUses - Spill the specified physical register /// around all defs and uses of the specified interval. void LiveIntervals::spillPhysRegAroundRegDefsUses(const LiveInterval &li, unsigned PhysReg, VirtRegMap &vrm) { unsigned SpillReg = getRepresentativeReg(PhysReg); for (const

The following code in VirtRegMap.cpp is asserting in the C++ library because back() is called on an empty container: /// addLastUse - Add the last use information of all stack slots whose /// values are available in the specific register. void addLastUse(unsigned PhysReg, MachineInstr *Use) { std::multimap<unsigned, int>::iterator I = PhysRegsAvailable.lower_bound(PhysReg);

Hey all, I've found a bug in either the PBQP register allocator or in VirtRegRewriter. I'm observing this assertion in VirtRegRewriter::rewrite() fail: unsigned VirtReg = MO.getReg(); unsigned PhysReg = VRM->getPhys(VirtReg); ... assert(!MRI->isReserved(PhysReg) && "Reserved register assignment"); Indeed there is a case where

<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div dir="ltr" > </div> <div dir="ltr" >Hi all,</div> <div dir="ltr" > </div> <div

Hi Jakob, I've got a good test case that I'm working on at the moment. I noticed something odd though: Is '0' a valid register unit? I'm seeing a LiveInterval with li->reg == 0 show up, which previously wasn't valid. We have a few checks around the place to disregard the '0' physreg - could these trigger on interaction with a '0' interval? That could

On Aug 21, 2010, at 5:27 PM, Eli Friedman wrote: > See http://llvm.org/bugs/show_bug.cgi?id=4668 and > http://llvm.org/bugs/show_bug.cgi?id=5010. The basic description of > the issue (from http://llvm.org/bugs/show_bug.cgi?id=4668#c5): "The > fundamental problem is we can't spill a register once it's fixed to a > physical register." > >> From discussion

I've been playing around with spillers and found that the SimpleSpiller fails badly on a particular code. The problem arises because SimpleSpiller does the test VRM.isAssignedReg(virtReg) which is implemented as: 00183 bool isAssignedReg(unsigned virtReg) const { 00184 if (getStackSlot(virtReg) == NO_STACK_SLOT && 00185 getReMatId(virtReg) == NO_STACK_SLOT)

On Jan 14, 2013, at 1:39 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > On 1/14/2013 3:16 PM, Jakob Stoklund Olesen wrote: >> >> On Jan 14, 2013, at 12:56 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: >>> >>> My question is: is this something that was a part of the design? >> >> Yes, the register allocator

When we discussed this our line of thought was like this: - LLVM IR already uses %name for SSA values which is closer to what a vreg is than to what a physreg is. It would be neat to draw that parallel to llvm IR. - We wanted another sigil for physregs so they are easy to differentiate from vregs to allow people to differentiate vregs/physregs even if they don't know all the physreg names of

Hello, For my backend, I define and use a CC register similiarly to the EFLAGS register in X86 (I call it CCFLAGS). But if I make all arithmetic/logic instructions affect it ('let Defs = [CCFLAGS] in...' in InstrInfo.td) I run into // The only case we should have a dead physreg here without a killing or // instruction where we know it's dead is if it is live-in to the function

On Mon, Aug 30, 2010 at 5:52 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Aug 21, 2010, at 5:27 PM, Eli Friedman wrote: > >> See http://llvm.org/bugs/show_bug.cgi?id=4668 and >> http://llvm.org/bugs/show_bug.cgi?id=5010.  The basic description of >> the issue (from http://llvm.org/bugs/show_bug.cgi?id=4668#c5): "The >> fundamental problem

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,

On Mon, Jan 8, 2018 at 2:27 PM, Matthias Braun <mbraun at apple.com> wrote: > When we discussed this our line of thought was like this: > > - LLVM IR already uses %name for SSA values which is closer to what a vreg > is than to what a physreg is. It would be neat to draw that parallel to > llvm IR. > - We wanted another sigil for physregs so they are easy to differentiate

On Sep 2, 2012, at 11:52 PM, Lang Hames <lhames at gmail.com> wrote: > Hi Sergei, > > I just fixed the broken test case for PR13719 with r163107, but from the debugging output you've posted it suspect it won't fix your test case. > > Your analysis looks good - findLastUseBefore(..) doesn't appear to be handling physregs. I'm surprised that isn't causing