llvm dev - Aug 2012 - [LLVMdev] Register Coalescer does not preserve TargetFlag

Do you know any backend that implement instructions as a flag modifier in
instruction ?

Thank,
Vincent Lejeune



----- Mail original -----
> De : Jakob Stoklund Olesen <stoklund at 2pi.dk>
> À : Vincent Lejeune <vljn at ovi.com>
> Cc : "llvmdev at cs.uiuc.edu (LLVMdev at cs.uiuc.edu)"
<llvmdev at cs.uiuc.edu>
> Envoyé le : Lundi 6 août 2012 20h06
> Objet : Re: [LLVMdev] Register Coalescer does not preserve TargetFlag
> 
> 
> On Aug 6, 2012, at 11:00 AM, Vincent Lejeune <vljn at ovi.com> wrote:
> 
>>  Ok.
>> 
>>  I tried to do it using a pass after register allocation, lowering
NEG/ABS
> instructions.
>>  However I met a problem : apparently getNextOperandForReg() can
returns a
> MachineOperand before the one I'm processing.
>> 
>>  The following code snippet : 
>> 
>> 
>>  void R600ModifiersPropagation::substituteReg(MachineOperand
&def_MO,
> unsigned new_reg, unsigned char flag) {
>>    MachineOperand * MO = def_MO.getNextOperandForReg();
>>    while (MO && MO->isUse()) {
>>      MachineOperand *next_MO = MO->getNextOperandForReg();
>>      MO->dump();
>> 
>>      MO = next_MO;
>>    }
>>  }
>> 
>>  displays instructions that are before the one I'm passing as
def_MO.
> I'm not sure if I should call some Analysis pass to enforce
MachineOperand
> order or not.
> 
> We make no guarantees about the order of operands in the use-def chains,
and
> there are no analyses that can reorder them.
> 
> I would suggest that you read the code in other targets to see how things
are
> usually done.
> 
> /jakob
>

Vincent, 
 The AMDIL backend does this for custom swizzles for certain instructions(Vector
insert/extract).

Micah
> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu]
> On Behalf Of Vincent Lejeune
> Sent: Monday, August 06, 2012 11:13 AM
> To: Jakob Stoklund Olesen
> Cc: llvmdev at cs.uiuc.edu (LLVMdev at cs.uiuc.edu)
> Subject: Re: [LLVMdev] Register Coalescer does not preserve TargetFlag
> 
> Do you know any backend that implement instructions as a flag modifier
> in instruction ?
> 
> Thank,
> Vincent Lejeune
> 
> 
> 
> ----- Mail original -----
> > De : Jakob Stoklund Olesen <stoklund at 2pi.dk>
> > À : Vincent Lejeune <vljn at ovi.com>
> > Cc : "llvmdev at cs.uiuc.edu (LLVMdev at cs.uiuc.edu)"
> <llvmdev at cs.uiuc.edu>
> > Envoyé le : Lundi 6 août 2012 20h06
> > Objet : Re: [LLVMdev] Register Coalescer does not preserve TargetFlag
> >
> >
> > On Aug 6, 2012, at 11:00 AM, Vincent Lejeune <vljn at ovi.com>
wrote:
> >
> >>  Ok.
> >>
> >>  I tried to do it using a pass after register allocation, lowering
> NEG/ABS
> > instructions.
> >>  However I met a problem : apparently getNextOperandForReg() can
> returns a
> > MachineOperand before the one I'm processing.
> >>
> >>  The following code snippet :
> >>
> >>
> >>  void R600ModifiersPropagation::substituteReg(MachineOperand
> &def_MO,
> > unsigned new_reg, unsigned char flag) {
> >>    MachineOperand * MO = def_MO.getNextOperandForReg();
> >>    while (MO && MO->isUse()) {
> >>      MachineOperand *next_MO = MO->getNextOperandForReg();
> >>      MO->dump();
> >>
> >>      MO = next_MO;
> >>    }
> >>  }
> >>
> >>  displays instructions that are before the one I'm passing as
> def_MO.
> > I'm not sure if I should call some Analysis pass to enforce
> MachineOperand
> > order or not.
> >
> > We make no guarantees about the order of operands in the use-def
> chains, and
> > there are no analyses that can reorder them.
> >
> > I would suggest that you read the code in other targets to see how
> things are
> > usually done.
> >
> > /jakob
> >
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On Aug 6, 2012, at 11:12 AM, Vincent Lejeune <vljn at ovi.com> wrote:
> Do you know any backend that implement instructions as a flag modifier in
instruction ?
No, I am not aware that any of the targets in the tree do something like that.
TargetFlags is used by ARM to modify global symbol operands and such.

But I meant you should be looking at the coding style used in the other targets.
The getNextOperandForReg() function isn't used anywhere, see the
MachineRegisterInfo iterators instead.

/jakob

On Aug 6, 2012, at 11:16 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk>
wrote:
> 
> The getNextOperandForReg() function isn't used anywhere,
Should we remove it?

-Jim