This is the mail archive of the gcc@gcc.gnu.org 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: Lingering tbaa in anti_dependence?


On Fri, Dec 30, 2011 at 6:53 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Thu, Dec 29, 2011 at 04:24:31PM +0000, Richard Sandiford wrote:
>> AIUI, the outcome of PR38964 was that we can't use TBAA for testing an
>> anti_dependence between a load X and store Y because Y might be defining
>> a new object in the same space as the object that was being read by X.
>> But it looks like we still use component-based disambiguation
>> (nonoverlapping_component_refs_p) in this case. ?Is it true that
>> that's also a problem? ?E.g. for:
>>
>> ? ? struct s { int f; float g; };
>> ? ? struct t { int header; struct s s; };
>>
>> ? ? float foo (struct t *newt, struct s *olds, int x, int y)
>> ? ? {
>> ? ? ? float ret = olds[x * y].g;
>> ? ? ? newt->header = 0;
>> ? ? ? newt->s.f = 1;
>> ? ? ? newt->s.g = 1.0;
>> ? ? ? return ret;
>> ? ? }
>>
>> we can (and on ARM Cortex A8, do) move the store to newt->s.f above
>> the load from olds[...].g. ?If we view the assignment to newt
>> as defining a new object in the same space as the now-defunct olds,
>> and if x * y happens to be zero, then the accesses might well be
>> to the same address.
>
> You would need a placement new in between the read from olds[x * y].g
> and newt->* stores, without that it is definitely valid to move it
> ahead of the store.
> IMHO we should keep placement new in the IL in some form, and decide how
> conservative we need to be based on whether the current function
> or current loop etc. contains (or could contain) a placement new or not.

I disagree.  Any representation of placement new would pessimize code
more than it is pessimized now.  You also will lose the advantage that
the current implementation of our TBAA semantics integrate nicely
with the type-punning through union stuff which you'd otherwise have
to make explicit (thus, lower to the proposed placement-new style), too.

Also consider placement new in a function (it would be pure/const),
also consider that placement new is simply an inline function returning
its argument.

> E.g. if a loop doesn't contain placement new anywhere, we could be less
> conservative in optimizing that loop, do more vectorization on it etc.

For loops we can just do more proper dependence analysis.

Richard.

> ? ? ? ?Jakub


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