Re: using scratchpads to enhance RTL-level if-conversion: revised patch

[Bernd Schmidt <bschmidt@redhat.com>]

> _Potentially_ so, yes.  However, GCC is free to put the allocation into
> an otherwise-unused part of the stack frame.

Well, I looked at code generation changes, and it usually seems to come 
with an increase in stack frame size - sometimes causing extra 
instructions to be emitted.

>> However, why do we need to allocate anything in the first place?
>  > If you want to store something that will be thrown away,
>  > just pick an address below the stack pointer.
>
> Because allocating a scratchpad should work on all relevant targets.  We
> do not have the resources to test on all GCC-supported
> CPU ISAs and on all GCC-supported OSes, and we would like to have an
> optimization that works on as many targets as makes sense
> [those with cmove-like ability and withOUT full-blown conditional
> execution].

Yeah, but if you put in a new facility like this, chances are 
maintainers for active targets will pick it up and add the necessary 
hooks. That's certainly what happened with shrink-wrapping. So I don't 
think this is a concern.

> I agree that your suggestion of having one global default scratchpad
> allocation policy plus per-target
> overrides that are more efficient _is_ a good one, but it will have to
> wait a while for implementation
> if that`s to be done by me.  In the meantime, the existing allocation
> policy is compatible with
> multiple targets and costs very little space in the stack frame, if and
> when any at all.

I'm afraid I'll have to reject the patch then, on these grounds:
  * it may pessimize code
  * it does not even estimate costs to attempt avoiding this
  * a much simpler, more efficient implementation is possible.

>>> +        MEM_NOTRAP_P (mem) = true;
>> So I'm still not entirely sure which cases you are trying to optimize
>> and which ones not,
>
> The current patch focuses entirely on half-hammock writes with stores to
> addresses
> about which GCC "feels nervous", i.e. "may trap or fault"; for example:
>
>    if (condition)
>      *pointer = 9;
>    // no "else" or "else if"
>
>
>> but couldn't this technique allow a trapping store here?
>
> The purpose of the new if-conversion is to take a may-trap-or-fault
> store and replace it with a store
> that will be OK if the original program was OK with respect to the
> current execution`s inputs,
> environment, PRNG results, etc.  For example, the only way the
> if-converted code would dereference a
> null pointer is if/when the original program would have done the same
> thing under the same conditions.

Yeah, but it could still trap if the original program had an error. So I 
don't think setting MEM_NOTRAP_P is right.


Bernd