search for: superregister

...s bogus or if there's a bug here. > > A little more information: the assert checks that after coalescing > two nodes, > all subregister live intervals for the register coaelsced to now > interfere > with whatever the eliminated live interval interfered with, since the > superregister live interval now contains information from the > eliminated live > interval and thus it interferes with whatever the eliminated live > interval > interfered with (and thuis so should the subregister live interval, > correct?). > In my case, this test _fails_, which I found...

...ic block and retarget all the uses to use the result of the single > reload. It does not (yet) split intra-bb intervals. Ah, got it. Thanks. > > Also, in the ancient subregister coalescing code, there used to be > > an update > > of the SSARegMap to point subregisters to the superregister they were > > coalesced to (IIRC). That has since gone away. I used to use that > > in my > > code to return the correct live interval for a virtual register in > > the case > > where a subregister extract was coalesced. > > Right. That has been removed because...

...I want > to know if that assert is bogus or if there's a bug here. A little more information: the assert checks that after coalescing two nodes, all subregister live intervals for the register coaelsced to now interfere with whatever the eliminated live interval interfered with, since the superregister live interval now contains information from the eliminated live interval and thus it interferes with whatever the eliminated live interval interfered with (and thuis so should the subregister live interval, correct?). In my case, this test _fails_, which I found to be unexpected. In other word...

...words, after coalescing, should it be the case that > > subregister > > intervals contain at least all of the range information that was > > contained > > in any eliminated intervals when those eliminated intervals were > > coalesced > > to the subregister's superregister? > > Right. The code is being conservative. It's saying all of the entirety > of the superregister's live interval must also be in the subregister's > live interval. i.e. When the superregister is live, the subregister > must be live. Ok, but that is NOT what's happe...

...xplain the basic mechanics of the live interval splitting code? Is it all in LiveIntervalAnalysis.cpp under addIntervalsForSpills and child routines? What is it trying to do? Also, in the ancient subregister coalescing code, there used to be an update of the SSARegMap to point subregisters to the superregister they were coalesced to (IIRC). That has since gone away. I used to use that in my code to return the correct live interval for a virtual register in the case where a subregister extract was coalesced. That information appears to now be in RegSubIdxMap, which is local to runOnMachineFunction, so...

I have a question about what is going on at line 754 of SimpleRegisterCoalescing.cpp. The comment says we are updating the live intervals for subregisters. This happens when we coalesce to a physical register. Now, I read that as, "merge in the range information from the eliminated live interval to the subregister live interval," but that appears to not be what happens. In my case,

...troduce a single reload per basic block and retarget all the uses to use the result of the single reload. It does not (yet) split intra-bb intervals. > > Also, in the ancient subregister coalescing code, there used to be > an update > of the SSARegMap to point subregisters to the superregister they were > coalesced to (IIRC). That has since gone away. I used to use that > in my > code to return the correct live interval for a virtual register in > the case > where a subregister extract was coalesced. Right. That has been removed because it's surprisingly painful...

...escing, should it be the case that >>> subregister >>> intervals contain at least all of the range information that was >>> contained >>> in any eliminated intervals when those eliminated intervals were >>> coalesced >>> to the subregister's superregister? >> >> Right. The code is being conservative. It's saying all of the >> entirety >> of the superregister's live interval must also be in the >> subregister's >> live interval. i.e. When the superregister is live, the subregister >> must be l...

Hi, I have a MachineInstr that writes to a subreg, but clobbers the superreg. How should I BuildMI this instruction? I try to do a IMPLICIT_DEF super_reg and then write to a subreg of that super register , but it gets DCE:ed. Is there a way to express this clobbering of a superregister? thanks, Jonas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110407/b0ff13bd/attachment.html>

...Defines == true is conservatively correct >here. >My guess, but I haven’t checked the code, is that super-register should be >understood as any alias of Reg. > >Worth checking. > >Q. I agree EBX is partly defined, but I think that is what Clobbers is for. The interface for isSuperRegister certainly makes a pretty clear distinction between something being a superRegister and something being an overlapping register. What do you think I should be checking to understand the assumptions/expectations better? > >> >> I wanted to be sure that I wasn't missing something...

...sk. > Basically, if that helps, > Clobber: The register cannot live through. > Define: (Part of) the register is define by this instruction. Put differently, you can use a register as a definition of an instruction when it is clobbered but not defined. > >> The interface for isSuperRegister >> certainly makes a pretty clear distinction between something being a superRegister and something being an >> overlapping register. What do you think I should be checking to understand the assumptions/expectations better? > > The code :). > >> >>> >>...

Would I be correct in assuming that the alias set is defined as the registers which may reside in the same space as the register? In other words the register is either a super or sub register which holds the same physical location in the register set? Could someone please explain what the Alias set is if it is not what I described above? TargetRegisterInfo::getAliasSet( unsigned reg ) Thanks

I'm working on getting an out of tree target machine verifier clean. This has found some nasty bugs so I'd like to continue with it. One instance of bad machine code is "Using an undefined physical register". This arises whenever undef propagates to a machine instruction. Usually this means the input was meaningless - e.g. call an undefined address. Other times it's a

I am looking at results from analyzePhysReg, and am getting results a little different than I expected for x86. The call to this is coming from this code in llvm::MachineBasicBlock::computeRegisterLiveness 1163 MachineOperandIteratorBase::PhysRegInfo Analysis = 1164 ConstMIOperands(I).analyzePhysReg(Reg, TRI); The instruction I being analyzed is: %BX<def> = MOV16rm

I need to model my registers for my allocator. I need to identify the super-register and the sub-register conflicts. Something like: For each set of registers R in the set of aligned registers defined by the input request virtual register alpha. Now each register block r in R can have zero, one, or more registers defined in the block started at the aligned size and ending at the aligned size plus

Hello Jeff, you're the first one to reply to my question :) I got a bit confused with the fact you said that the subregister class is larger than the superregister class. As far as i understood or what i tried to do with my code is to define a register pair composed of two 8 bit registers the way i described in my previous message. So R1R0 in WDREGS is directly mapped into R0 and R1 of GPR8. Meaning that 2 GPR8 = 1 WDREG. Also, R1R0 is the superreg of R1 and...

Ryan, I don't think I fully understand the problem you described, but please see the comments below. Hope this helps you solve the problem. On Sat, Oct 6, 2012 at 3:18 PM, ryan baird <ryanrbaird at gmail.com> wrote: > I'm working on a target based on the MIPS target, and when I copy f64 > values into 32 bit registers for calling functions, I need the operation to > work

Hi, I don't know if anyone else has responded to your question, but I am currently in development of a register allocator. Thank you for bringing up the fact that sub-register classes may be larger than their super-register. If this remains the case, I for one will write a transform for my allocator which will make the 16 bit register the super-register with the 8bit as the sub. At least for

...ass through into the live-out value. Looking into the code for anaylzePhysReg, I think the code looks like it intends for Defines to truly mean Reg or a super-register of Reg is defined, not any overlapping Reg is defined. The code looks like this: bool IsRegOrSuperReg = MOReg == Reg || TRI->isSuperRegister(MOReg, Reg); ... if (IsRegOrSuperReg) { PRI.Defines = true; // Reg or a super-register is defined. if (!MO.isDead()) AllDefsDead = false; } I think the fundamental bug here is that the operands are swapped when passed into isSuperRegister. The definition of isSuperRegister is /// \br...

I'm working on a target based on the MIPS target, and when I copy f64 values into 32 bit registers for calling functions, I need the operation to work on a of 32 bit registers (because the language I'm translating to isn't actually mips). I've been looking at how to do this, but I haven't been able to figure it out. Since the Mips target code is still really close to mine,