Re: [PATCH ppc64,aarch64,alpha 00/15] Improve backend constant generation

[Segher Boessenkool <segher@kernel.crashing.org>]

On Wed, Aug 12, 2015 at 08:32:46AM -0700, Richard Henderson wrote:
> On 08/12/2015 01:31 AM, Segher Boessenkool wrote:
> > Is there something that makes the cache not get too big?  Do we
> > care, anyway?
> 
> No, nothing ever reduces the size of the cache.  I doubt we care, but I haven't
> instrumented to see how big it grows.
> 
> My intuition says the most important thing about managing this cache is not to
> put the most common trivial constants in, and I already do that.

Right.  And it seems to cache negative results too (the five-insn
sequence).

> >>     I did attempt to fix it, and got nothing for my troubles except
> >>     poorer code generation for AND/IOR/XOR with non-trivial constants.
> > 
> > Could you give an example of code that isn't split early enough?
> 
> I believe the examples I was seeing was in the libdecnumber code.  I'd have to
> go back and reproduce it now...

If you could, please do.

> >>     Perhaps there's some other predication or costing error that's
> >>     getting in the way, and it simply wasn't obvious to me.   In any
> >>     case, nothing in this patch set addresses this at all.
> > 
> > The instruction (set (reg) (const_int 0x12345678)) is costed as 4
> > (i.e. one insn).  That cannot be good.  This is alternative #5 in
> > *movsi_internal1_single (there are many more variants of that
> > pattern).
> 
> Yes, when I tried to fix it, I did adjust that costing, but still...

I misread it (it's alt #6, with cost 8).  Maybe Alan's patches would
fix this one?

> >>   * Constants are split *really* late.  In particular, after reload.
> > 
> > Yeah that is bad.  But I'm still not seeing it.  Hrm, maybe only
> > DImode ones?
> 
> Dunno.  I found it after I did add a recipe to use ADDI, which then triggered
> an ICE due to the r0 base register.

Ah!  Reload generates *new* addition insns out of thin air, and that
is exactly the case where ADDI won't work.  LRA works a bit better
there it seems (but it is still not the default for rs6000); if the
constraint ("b" in this case) would not match, it tries other things.

> > Have you looked at generated code quality?
> 
> I've looked at diffs of all of the object files in the target directory.  There
> were definite spots of improvement.  I wasn't able to spot any regressions.

[ I've looked now. ]

Some of the new combos help a bit, yes.  Total code size increased
a tiny bit; it looks to be all because of unfortunate scheduling and
less tail merging.  The usual.

32-bit code is identical, as it should be ;-)


Segher