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

[Aldy Hernandez <aldyh at redhat dot com>]

On 03/10/12 08:14, Torvald Riegel wrote:
> 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;
> > +	       }

Hmmm, by adding the exit, PRE introduces the read of "x + 4" correctly 
*after* the read of flag2, so something like this:

__transaction_atomic {
	if (flag) {
		tmp = x + 4;
		y = tmp;
	} else {
		if (flag2)
			return;
		tmp = x + 4;
	}
	z = tmp;

So... by your logic, this is allowed because the read of "x" would 
happen anyway (it is not inserted in the "flag2 != 0" case).

I'm back to having no testcase, so perhaps I should drop this patch 
until we can come up with a PRE testcase that actually triggers a 
publication safety violation.

Richi, you mentioned partial PRE inserting code into code paths that 
previously did not have reads.  Do you have an example?  As much as I 
tried, I could not trigger a partial PRE, but that may be because I 
don't understand the algorithm very well.

Thanks guys.
Aldy