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

[Abe <abe_skolnik@yahoo.com>]

[Bernd wrote:]

> Obviously this increases the size of the stack frame,

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


> The patch does not appear to attempt to estimate costs.

There is nothing new relating to cost estimation in my patch, that`s true.

As some of you already know, James Greenhalgh has been working on cost analysis in "ifcvt.c" recently,
as can be seen, for example, here:  https://gcc.gnu.org/ml/gcc-patches/2015-09/msg01971.html


> 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].  In other words, we chose to "play it safe".
We considered the "just past the stack pointer" technique early on in this project, but judged it as too risky to apply
to all targets w/o testing either on those targets or at least on an emulator/simulator of those targets.

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.


Thanks for your [Bernd`s] other feedback, not copied here; I have applied lots of corrections and improvements as a result.


>> +        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.


Regards,

Abe