Re: [RFC 5/5] Always completely replace constant pool entries

[Richard Biener <richard.guenther@gmail.com>]

On Tue, Aug 25, 2015 at 9:54 PM, Jeff Law <law@redhat.com> wrote:
> On 08/25/2015 05:06 AM, Alan Lawrence wrote:
>>
>> I used this as a means of better-testing the previous changes, as it
>> exercises
>> the constant replacement code a whole lot more. Indeed, quite a few tests
>> are
>> now optimized away to nothing on AArch64...
>>
>> Always pulling in constants, is almost certainly not what we want, but we
>> may
>> nonetheless want something more aggressive than the usual --param, e.g.
>> for the
>> ssa-dom-cse-2.c test. Thoughts welcomed?
>
> I'm of the opinion that we have too many knobs already.  So I'd perhaps ask
> whether or not this option is likely to be useful to end users?
>
> As for the patch itself, any thoughts on reasonable heuristics for when to
> pull in the constants?  Clearly we don't want the patch as-is, but are there
> cases we can identify when we want to be more aggressive?

Well - I still think that we need to enhance those followup passes to directly
handle the constant pool entry.  Expanding the assignment piecewise for
arbitrary large initializers is certainly a no-go.  IIRC I enhanced FRE to do
this at some point.  For DOM it's much harder due to the way it is structured
and I'd like to keep DOM simple.

Note that we still want SRA to partly scalarize the initializer if
only few elements
remain accessed (so we can optimize the initializer away).  Of course
that requires
catching most followup optimization opportunities before the 2nd SRA run.

Richard.

> jeff
>
>