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
