similar to: [LLVMdev] Remove subreg copies

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

Hi Jakob, Thanks for your reply. > > The <undef> flag goes on NewMI_1 because the virtual register B isn't live > before that instruction. > > But you probably shouldn't be doing this yourself. Your NewMI code isn't in > SSA form because B has multiple definitions. Just use a REG_SEQUENCE > instruction, and let the register allocator do the transformation

On Jul 4, 2012, at 10:45 PM, Pranav Bhandarkar <pranavb at codeaurora.org> wrote: > Hi, > > This question relates to the undef flag in the context of sub-register def > operands. > > 1) Firstly, the documentation (comments in the source code) says that in a > sub-register def operand, the "IsUndef" flag refers to the part of the > register that is not

Hi, This question relates to the undef flag in the context of sub-register def operands. 1) Firstly, the documentation (comments in the source code) says that in a sub-register def operand, the "IsUndef" flag refers to the part of the register that is not written. 2) Further, the documentation about readsReg() states that a sub-register def implicitly reads the other parts of the

Hi Jakob, > New_MI_1:: Vreg1 = 0 ; Vreg1 and Vreg2 > are 32 bit virt. regs. > New_MI_2:: Vreg2 = COPY C:lo_sub_reg. > New_MI_3:: B= REG_SEQUENCE<Vreg1, hi_sub_reg, Vreg2, lo_sub_reg> ; B > is a > 64 bit virt reg. I used this approach and it worked find until I hit, what I believe is, a bug in the register coalescer. When the register

Le 07/03/2012 17:36, Jim Grosbach a écrit : > On Mar 7, 2012, at 6:23 AM, Ivan Llopard<ivanllopard at gmail.com> wrote: > >> Hi Jim, >> >> Thanks for your response. >> >> Le 06/03/2012 22:54, Jim Grosbach a écrit : >>> Hi Ivan, >>> On Mar 3, 2012, at 4:48 AM, Ivan Llopard<ivanllopard at gmail.com> wrote: >>>

On Mar 14, 2012, at 7:07 AM, Ivan Llopard wrote: > Le 07/03/2012 17:36, Jim Grosbach a écrit : >> On Mar 7, 2012, at 6:23 AM, Ivan Llopard<ivanllopard at gmail.com> wrote: >> >>> Hi Jim, >>> >>> Thanks for your response. >>> >>> Le 06/03/2012 22:54, Jim Grosbach a écrit : >>>> Hi Ivan, >>>> On Mar 3,

On Mar 7, 2012, at 6:23 AM, Ivan Llopard <ivanllopard at gmail.com> wrote: > Hi Jim, > > Thanks for your response. > > Le 06/03/2012 22:54, Jim Grosbach a écrit : >> Hi Ivan, >> On Mar 3, 2012, at 4:48 AM, Ivan Llopard<ivanllopard at gmail.com> wrote: >> >>> Hi, >>> >>> I'm facing a problem in llvm while porting it

Hi Jim, Thanks for your response. Le 06/03/2012 22:54, Jim Grosbach a écrit : > Hi Ivan, > On Mar 3, 2012, at 4:48 AM, Ivan Llopard<ivanllopard at gmail.com> wrote: > >> Hi, >> >> I'm facing a problem in llvm while porting it to a new target and I'll >> need some support. >> We have 2 kind of register, one for general purposes (i.e.

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

> > > That sounds like a bug, probably adjustCopiesBackFrom needs to check > ACopyMI->isFullCopy(). > > Do you have a test case for this? > > Yes and No. Yes because the example is from a unit testcase that I have. No because it manifests itself only with my half baked pass that I was talking about earlier in this thread. Pranav -------------- next part --------------

On Jul 6, 2012, at 7:30 AM, Pranav D Bhandarkar <pranav.bhandarkar at utexas.edu> wrote: > That sounds like a bug, probably adjustCopiesBackFrom needs to check ACopyMI->isFullCopy(). > > Do you have a test case for this? > > > Yes and No. Yes because the example is from a unit testcase that I have. No because it manifests itself only with my half baked pass that I

<dag at cray.com> writes: > For reaching definitions I think simply tracking definitions via super > registers should be sufficient. Even if a definition defines a > subregister I can consider it to define the "most super" register. This > will be pessimistic for cases like x86 AH/AL, but I hardly care about > those at the moment. :) I did a big *facepalm*

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

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 = INSERT_SUBREG THe sixth field is zero, which means it doesn't have the the

On Jul 5, 2012, at 6:01 PM, "Pranav Bhandarkar" <pranavb at codeaurora.org> wrote: > Hi Jakob, > >> New_MI_1:: Vreg1 = 0 ; Vreg1 and Vreg2 >> are 32 bit virt. regs. >> New_MI_2:: Vreg2 = COPY C:lo_sub_reg. >> New_MI_3:: B= REG_SEQUENCE<Vreg1, hi_sub_reg, Vreg2, lo_sub_reg> ; B >> is a >> 64 bit

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