Re: [PATCH] Tree SRA and atomicity/volatility

[Mark Mitchell <mark at codesourcery dot com>]

Richard Guenther wrote:
> On 1/23/07, Mark Mitchell <mark@codesourcery.com> wrote:
>> Eric Botcazou wrote:
>>
>> > 2007-01-06  Eric Botcazou  <ebotcazou@adacore.com>
>> >
>> >       * tree-sra.c (sra_walk_fns) <ldst>: Document new restriction.
>> >       (sra_walk_modify_expr) <rhs_elt>: Treat the reference as a use
>> >       if the lhs has side-effects.
>> >       <lhs_elt>: Treat the reference as a use if the rhs has
>> side-effects.
>> >
>> > :ADDPATCH Tree-SRA:
>>
>> I've read through this thread, and I think Eric's patch makes sense.  (I
>> think Richard G. eventually came to the same conclusion, so I'm not
>> claiming this is some brilliant insight on my part.)  Even in C, keeping
>> volatile accesses "more atomic" seems like a good thing.  And,
>> certainly, any possible pessimization by not doing individual accesses
>> to move data out of volatile structures is going to be insignificant, to
>> overall program runtime.
> 
> I agreed to fix the (possible) regression on the branches with Eric's
> patch.
> I didn't agree to put the same fix on the mainline until we first had a
> precise definition of what constraints the Ada frontend (seems to) put on
> the middle-end.  And with the further conversation it looks to me what
> the Ada frontend does/wants isn't what it communicates to the middle-end.
> 
> So I'm against applying the patch to the mainline without proper texi
> documentation of what Ada does here (it should make little sense, too,
> of course).

If we don't want the patch on the mainline, then we may not want it on
the branches either.  It's a bad idea to fix a bug on a release branch
without fixing it on mainline too, as it's creating a future regression.

I understand Daniel's comments about wanting to make sure that we're
checking the right flags, but the basic issue seems entirely independent
of Ada.  If there's an assignment of a volatile object to a non-volatile
object, I think we should avoid splitting the copy, in order to reduce
the chances that we're accessing volatile words multiple times.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713