Re: [PR51752] publication safety violations in loop invariant motion pass

[Torvald Riegel <triegel at redhat dot com>]

On Fri, 2012-03-09 at 15:48 -0600, Aldy Hernandez wrote:
> Torvald is this what you were thinking of?

Yes, but with an exit in the else branch or something that can cause x
not being read after the condition.  I _suppose_ that your original
example would be an allowed transformation but just because x would be
read anyway independently of flag's value; we can assume data-race
freedom, and thus we must be able to read x in a data-race-free way even
if flag is false, so flag's value actually doesn't matter.

What about modifying the example like below?  In this case, if flag2 is
true, flag's value will matter and we can't move the load to x before
it.  Will PRE still introduce "tmp = x + 4" in such an example?

Torvald

> +	       __transaction_atomic {
> +	         if (flag)
> +		   y = x + 4;
> +		 else
> +		   // stuff
                     if (flag2)
                       return;
> +		 z = x + 4;
> +	       }
> +
> +	     PRE can rewrite this into:
> +
> +	       __transaction_atomic {
> +	         if (flag) {
> +	           tmp = x + 4;
> +		   y = tmp;
> +		 } else {
> +		   // stuff
> +		   tmp = x + 4;
                     if (flag2)
                       return;
> +		 }
> +		 z = tmp;
> +	       }
> +
> +	     A later pass can move the now totally redundant [x + 4]
> +	     before its publication predicated by "flag":
> +
> +	       __transaction_atomic {
> +	         tmp = x + 4;
> +		 if (flag) {
> +		 } else {
> +		   // stuff
                     if (flag2)
                       return;
> +		 }
> +		 z = tmp;
> +	  */