[LLVMdev] Register Coalescer does not preserve TargetFlag

Villmow, Micah Micah.Villmow at amd.com
Mon Aug 6 11:16:12 PDT 2012


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






More information about the llvm-dev mailing list