[LLVMdev] Instruction Cleanup Questions

Hal Finkel hfinkel at anl.gov
Thu Jun 7 14:34:34 PDT 2012


On Thu, 07 Jun 2012 14:09:53 -0700
Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote:

> 
> On Jun 7, 2012, at 1:42 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> 
> > On PPC, normal moves are encoded as OR instructions where the two
> > operands being ORed together are the same. These self moves, as it
> > turns out, come from things like this:
> > 
> > %vreg18<def> = OR8To4 %vreg16, %vreg16; GPRC:%vreg18 G8RC:%vreg16
> > 
> > This is generated from the pattern:
> > 
> > def : Pat<(i32 (trunc G8RC:$in)),
> >          (OR8To4 G8RC:$in, G8RC:$in)>;
> > 
> > So, as far as RA is concerned, this is a "real" operation (a binary
> > OR which truncates the result to 32-bits (from 64-bit inputs)). In
> > effect, however, this is just a self copy. 
> > 
> > How can I fix this?
> 
> def : Pat<(i32 (trunc G8RC:$in)),
>           (EXTRACT_SUBREG G8RC:$in, sub_32)>;
> 
> This exposes the copies to the register coalescer and
> VirtRegMap::rewrite() which eliminates identity copies. You can
> probably lose the OR8To4 pseudo after that.

Thanks!

> 
> I assume there will be no problems with 32-bit instructions using the
> low part of 64-bit registers without clearing the high part first.

I don't think so, the high part of the register is not separately
addressable. I can certainly imagine ways in which this could cause
problems, but I think that in practice it is okay because the 32-bit
adds, subs, cmps, etc. are all separate instructions -- and, in any
case, I did not write this, so I'm hoping that whoever did thought
this through ;)

 -Hal

> 
> /jakob
> 



-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory



More information about the llvm-dev mailing list