This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PR51752] publication safety violations in loop invariant motion pass

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:

     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.


Attachment: curr
Description: Text document

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]