Re: improved RTL-level if conversion using scratchpads [half-hammock edition]

[Bernd Schmidt <bschmidt at redhat dot com>]

On 11/10/2015 10:35 PM, Abe wrote:
> I wrote:
> > What I'm saying is I don't see a reason for a "definitely always
> > unsafe" state.
> > Why would any access not be made safe if a scratchpad is used?
>
> Because the RTL if-converter doesn`t "know" how to convert
> {everything that can be made safe using a scratchpad and is unsafe
> otherwise}. My patch is only designed to enable the conversion of
> half-hammocks with a single may-trap store.

Yeah, but how is that relevant to the question of whether a MEM is safe? 
The logic should be
 if mem is safe and we are allowed to speculate -> just do it
 otherwise mem is unsafe, so
   if we have prereqs like conditional moves -> use scratchpads
   otherwise fail

I don't see how a three-state property for a single MEM is necessary or 
helpful, and the implementation in the patch just roughly distinguishes 
between two different types of trap (invalid address vs. readonly 
memory). That seems irrelevant both to the question of whether something 
is safe or not, and to the question of whether we know how to perform 
the conversion.

You might argue that something that is known readonly will always fail 
if written to at runtime, but that's no different from any other kind of 
invalid address, and using a scratchpad prevents the write unless it 
would have happened without if-conversion.

> In summary, the 3 possible analysis outcomes are something like this:
>
>    * safe even without a scratchpad
>
>    * only safe with    a scratchpad, and we _do_ know how to convert it
> safely
>
>    * currently unsafe because we don`t yet       know how to convert it
> safely

This could be seen as a property of the block being converted, and is 
kind of implicit in the algorithm sketched above, but I don't see how it 
would be a property of the MEM that represents the store.

> > Do you have performance numbers anywhere?
>
> I think my analysis work so far on this project is not yet complete
> enough for public review, mainly because it does not include the
> benefit of  profiling.

I think performance numbers are a fairly important part of a submission 
like this where the transformation isn't an obvious improvement (as 
opposed to removing an instruction or suchlike).


Bernd