[PR51752] publication safety violations in loop invariant motion pass

[Aldy Hernandez <aldyh at redhat dot com>]

In this PR we have a publication safety violation in a transaction.  The 
loop invariant motion pass hoists a load out of a loop, creating a load 
data race.  Those unfamiliar with load data races in transactions, 
please see the PR, as this has been confusing to most (me included).

In the snippet below, we are not allowed to hoist DATA out unless it 
will be loaded on every path out of the loop:

 __transaction_atomic
   {
     for (i = 0; i < 10; i++)
       if (x[i])
         x[i] += DATA;
     // OK to hoist DATA above out if also loaded here:
     // blah = DATA;
   }

rth gave me the evil eye on a previous incantation of this patch, and 
I'm sure this one is not totally devoid of grime.

The main problem is how to record all loads in a given function in an 
efficient manner, so we can properly tease the information out in 
every_path_out_of_loop_has_load().  In my first revision I had some data 
flow equations that calculated loads on different paths, and rth just 
about hit me.  Instead now I save all loads in a function and iterate 
through them in a brute force way.  I'd like to rewrite this into a hash 
of some sort, but before I go any further I'm interested to know if the 
main idea is ok.

FYI, it has been suggested to use the mem_ref_p information already 
available in the pass, but I need information on all loads, not just 
those occurring inside loops.

BTW, this only fixes the loop invariant motion pass.  I'm sure there are 
other passes that will need equally painful fixes.

Aldy

Attachment: curr
Description: Text document