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~
