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
