similar to: [LLVMdev] Bug? Coalescing & Updating Subreg Intervals

On Wednesday 20 February 2008 07:00:28 pm Evan Cheng wrote: > > In other 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? >

On Feb 20, 2008, at 12:25 PM, David Greene wrote: > On Wednesday 20 February 2008 14:14, David Greene wrote: > >> I discovered this through an assert I put into some of my own >> code. 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

On Wednesday 20 February 2008 14:14, David Greene wrote: > I discovered this through an assert I put into some of my own code. 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

On Feb 20, 2008, at 7:36 PM, David A. Greene wrote: > On Wednesday 20 February 2008 07:00:28 pm Evan Cheng wrote: > >>> In other 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

On Thursday 21 February 2008 01:23, Evan Cheng wrote: > > Also, LiveIntervalAnalysis doesn't do any subregister checks as > > far as I can tell. It's certainly not the case that subregister > > intervals contain all of the information their supperregister's > > interval contains. > > SimpleRegisterCoalescing::JoinIntervals(). When coalescing a physical

On Thursday 21 February 2008 10:53, David Greene wrote: > Why do we do this trimming? The comment seems to say we don't care about > the rest of the live range from Clobbers (%reg1026 in this case) but that > doesn't match with our expectation that %reg15 will contain all of the live > range information from %reg1026. I'll add that merging this correctly could get

On Feb 21, 2008, at 9:06 AM, David Greene wrote: > On Thursday 21 February 2008 10:53, David Greene wrote: > >> Why do we do this trimming? The comment seems to say we don't care >> about >> the rest of the live range from Clobbers (%reg1026 in this case) >> but that >> doesn't match with our expectation that %reg15 will contain all of >>

On Wednesday 23 January 2008 02:01, Evan Cheng wrote: > > Can you explain the basic mechanics of the live interval splitting > > code? > It's splitting live intervals that span multiple basic blocks. That > is, when an interval is spilled, it introduce a single reload per > basic block and retarget all the uses to use the result of the single > reload. It does not

Evan, Can you explain 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

On Jan 22, 2008, at 12:23 PM, David Greene wrote: > Evan, > > Can you explain 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? It's splitting live intervals that span multiple basic blocks. That is, when an interval is spilled, it

>-----Original Message----- >From: Quentin Colombet [mailto:qcolombet at apple.com] >Sent: Thursday, December 03, 2015 4:43 PM >To: Smith, Kevin B <kevin.b.smith at intel.com> >Cc: llvm-dev at lists.llvm.org >Subject: Re: [llvm-dev] analyzePhysReg question > > >> On Dec 3, 2015, at 4:35 PM, Smith, Kevin B via llvm-dev <llvm- >dev at lists.llvm.org>

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

> On Dec 3, 2015, at 5:36 PM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On Dec 3, 2015, at 5:11 PM, Smith, Kevin B <kevin.b.smith at intel.com <mailto:kevin.b.smith at intel.com>> wrote: >> >> >> >>> -----Original Message----- >>> From: Quentin Colombet [mailto:qcolombet at apple.com

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

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

On Mar 18, 2008, at 6:12 PM, Dan Gohman wrote: > The new SUBREG target-independent instructions aren't getting > mayLoad/mayStore flags set correctly. > > For example, in the generated X86GenInstrInfo.inc file, > there is only one entry for INSERT_SUBREG: > > { 5, 4, 1, 0, "INSERT_SUBREG", 0, 0, NULL, NULL, > OperandInfo107 }, // Inst #5 =

> 1. copyRegToReg() won't be able to use register classes to pick a copy opcode. For instance, an XMM register will no longer be copied by MOVSS or MOVSD. Given just the physical register, MOVAPS will be used. Is that a problem? I haven't had time to really look into it, but have been playing around with the idea that instead of two register classes copyRegToReg and some of the load

On Mar 28, 2012, at 7:41 AM, Ivan Llopard <ivanllopard at gmail.com> wrote: > Hi, > > I'm facing a problem in my BE while trying to remove certain copies. > Here is a code snippet which I would like to optimize > > %vreg1<def> = READF32r; vRRegs:%vreg1 > %vreg2<def> = COPY %vreg1:rsub_h; iRSubRegs:%vreg2 vRRegs:%vreg1 > %vreg3<def> = COPY