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 Thu, Dec 29, 2011 at 5:24 PM, Richard Sandiford
<richard.sandiford@linaro.org> 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?

Yes.  The call of nonoverlapping_memrefs_p from write_dependence_p
may not dispatch to it.  I think we need to add a flag to distinguish this case.

Richard.

 ?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.
>
> Sorry if this is already a known problem...
>
> Richard


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