Hi Hal, On 07/06/2012 09:57, Chandler Carruth wrote:> On Wed, Jun 6, 2012 at 10:37 PM, Hal Finkel <hfinkel at anl.gov > <mailto:hfinkel at anl.gov>> wrote: > > I am working on cleaning up some PPC code generation. Two questions: > > 1. Which pass is responsible for cleaning up self-moves: > 0x00000000100057c0 <+208>: mr r3,r3 >and the RA should eliminate trivial copies.> > 2. Which pass is responsible for cleaning up unconditional jumps that > should be fall-throughs: > 0x0000000010005d88 <+1688>: b 0x10005d8c <._Z11sfoo+1692> > 0x0000000010005d8c <+1692>: ld r3,-32056(r2) > > > This should be handled by the MachineBlockPlacement (among others). Do > you have a reduced est case? > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120607/301f5f05/attachment.html>
> and the RA should eliminate trivial copies.Most probably PPC backend misses some hooks / descriptions... -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
On Thu, 07 Jun 2012 10:34:03 +0200 Ivan Llopard <ivanllopard at gmail.com> wrote:> Hi Hal, > > On 07/06/2012 09:57, Chandler Carruth wrote: > > On Wed, Jun 6, 2012 at 10:37 PM, Hal Finkel <hfinkel at anl.gov > > <mailto:hfinkel at anl.gov>> wrote: > > > > I am working on cleaning up some PPC code generation. Two > > questions: > > > > 1. Which pass is responsible for cleaning up self-moves: > > 0x00000000100057c0 <+208>: mr r3,r3 > > > > and the RA should eliminate trivial copies.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? Thanks again, Hal> > > > > 2. Which pass is responsible for cleaning up unconditional > > jumps that should be fall-throughs: > > 0x0000000010005d88 <+1688>: b 0x10005d8c > > <._Z11sfoo+1692> 0x0000000010005d8c <+1692>: ld r3,-32056(r2) > > > > > > This should be handled by the MachineBlockPlacement (among others). > > Do you have a reduced est case? > > > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory
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. 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. /jakob
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?What is this pattern trying to achieve? Is the OR actually necessary at all, or can you use an EXTRACT_SUBREG instead? --Owen