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]

Re: [PR tree-optimization/52558]: RFC: questions on store data race

On 05/16/12 07:53, Richard Guenther wrote:
On Mon, 7 May 2012, Aldy Hernandez wrote:

[Sorry for the delay; I was on vacation.]

I am forgoing the load avoidance code altogether to simplify things. Thanks.

+  /* Emit the load code into the latch, so that we are sure it will
+     be processed after all dependencies.  */
+  latch_edge = loop_latch_edge (loop);

inserting code into the latch block is bad - the vectorizer will
be confused by non-empty latches.

The code as is on trunk inserts the load on the latch. That's why I also inserted the supporting flag checking code there. Do you want me to put the supporting code somewhere else?

Your ChangeLog mentions changes that are no longer necessary
(the target hook).

Whoops. Fixed.

I didn't quite get the store order issue - we _do_ preserve store ordering right now, do we? So how come introducing the flags change that?

The current scheme on trunk works because it inserts one load with gsi_insert_on_edge() and subsequent ones get appended correctly, whereas my patch has to split the edge (which happens at the top of the block), so subsequent code inserts happen in reverse order (at the top). If I remember correctly, that is... I can look again and report if it's still unclear.

New patch attached. Tested on x86-64 Linux. No regressions.


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]