This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Combine related fail of gcc.target/powerpc/ti_math1.c
- From: Alan Modra <amodra at gmail dot com>
- To: Segher Boessenkool <segher at kernel dot crashing dot org>
- Cc: gcc at gcc dot gnu dot org
- Date: Fri, 22 May 2015 11:48:42 +0930
- Subject: Re: [RFC] Combine related fail of gcc.target/powerpc/ti_math1.c
- Authentication-results: sourceware.org; auth=none
- References: <20150521103604 dot GK6140 at bubble dot grove dot modra dot org> <20150521123916 dot GA26096 at gate dot crashing dot org>
On Thu, May 21, 2015 at 07:39:16AM -0500, Segher Boessenkool wrote:
> On Thu, May 21, 2015 at 08:06:04PM +0930, Alan Modra wrote:
> > FAIL: gcc.target/powerpc/ti_math1.c scan-assembler-times adde 1
>
> It doesn't trigger on big-endian; what is different?
Register dependencies. One of the arguments is in r4,r5, the return
value in r3,r4. We calculate the low 64 bits first, which goes to r4
on big-endian, overlapping the argument.
> > Trying 18, 9 -> 24:
> > Failed to match this instruction:
> > (set (reg:DI 4 4 [+8 ])
> > (plus:DI (plus:DI (reg:DI 5 5 [ val+8 ])
> > (reg:DI 76 ca))
> > (reg:DI 169 [+8 ])))
>
> For some reason it has the CA reg not last.
simplify-rtx.c:simplify_plus_minus_op_data_cmp
> I think we should add to
> the canonicalisation rules so that fixed regs sort after other regs.
> That requires a lot of testing.
What if you have two hard regs as above? Which of reg 5 and reg 76
sorts first? If they are sorted by register number, then ca appears
in the wrong place. Reverse sorting hard regs might work for this
pattern on powerpc, but that seems an odd choice. And if you say hard
regs ought to keep their original order in rtl like the above, then it
is no more difficult to keep all regs in their original order
> > original costs 4 + 8 + 4 = 16
> > replacement costs 4 + 4 = 8
>
> Still need to fix the costs as well (but they work as-is; well enough
> that is).
Yes, I noticed that too.
> Are these copies guaranteed to (still) be in this basic block,
> after the passes before combine? Did those passes do anything to
> prevent moving it? I'm asking because it would be good to use the
> same conditions in that case.
Something I need to investigate. As I said, the patch was just a
quick hack.
--
Alan Modra
Australia Development Lab, IBM