Re: [RFC] Tweak reload to const propagate into matching constraint output

[Richard Henderson <rth at redhat dot com>]

On 06/27/2012 01:45 AM, Richard Guenther wrote:
>> > Of course, this fires for normal integer code as well.
>> > Some cases it's a clear win:
>> >
>> > -:      41 be 1f 00 00 00       mov    $0x1f,%r14d
>> > ...
>> > -:      4c 89 f1                mov    %r14,%rcx
>> > +:      b9 1f 00 00 00          mov    $0x1f,%ecx
>> >
>> > sometimes not (increased code size):
>> >
>> > -:      41 bd 01 00 00 00       mov    $0x1,%r13d
>> > -:      4d 89 ec                mov    %r13,%r12
>> > +:      41 bc 01 00 00 00       mov    $0x1,%r12d
>> > +:      41 bd 01 00 00 00       mov    $0x1,%r13d
> I suppose that might be fixed if instead of
> 
> +  /* Only use the constant when it's just as cheap as a reg move.  */
> +  if (set_src_cost (c, optimize_function_for_speed_p (cfun)) == 0)
> +    return c;
> 
> you'd unconditionall use size costs?
> 

For one, without x86 cost changes that wouldn't affect anything.
For another, unconditionally using size costs, locally, would then
exchange the missed optimization from the second case to the first.

> We have an inverse issue elsewhere in that we don't CSE a propagated constant
> but get
> 
>    mov $0, %(eax)
>    mov $0, 4%(eax)
> ...
> 
> instead of doing one register clearing and then re-using that as zero.  But I
> suppose reload is not exactly the place to fix that ;)

That would be exactly because x86 doesn't model immediate costs properly.

My patch trying to un-cse in exactly the spot where the value is about
to be clobbered.  While we could give a go at this in a pre-reload pass,
it would be just a guess until register allocation does or does not
assign a hard reg to the constant, and does or does not choose an
alternative that requires the constant match an output.

Having reviewed more of the cc1 asm diff, the vast majority of cases are:
  * the cx input to string insns,
  * (1 << n).
These results are certainly skewed by the kind of stuff we do in gcc, but
it makes a fair amount of sense.


r~