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

[Richard Henderson <rth at redhat dot com>]

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.

>>     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...

>>     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...

>>   * 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.

> 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.


r~