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]

Re: spec2000 regression


> >>>>> "Jan" == Jan Hubicka <jh@suse.cz> writes:
> 
> > So remaining patch I can't analyze completely is yours to alias.c
> > I've failed to find the corresponding email at gcc-patches mailing list
> > (even when I believe I've went across it in the pass)
> 
> The subject line is "PATCH to get_alias_set".  There were two messages.
I got it already.  Thanks.
I was putting an mixture of both changelog entries to the search, that
caused it to fail.
> 
> > so please can you double-check the patch and try to explain me what
> > exactly it is shooting for?
> 
> It's trying to avoid recalculating the alias set for a variable.  I suppose
> it could cause a performance regression if the initial alias set were
> wrong, but I would expect that to cause other problems as well.
Can it get wrong in conservative way?
For example if it is uninitilalized (0), it can just alias everything.

Hmm, I will need to figure out how those alias sets works exactly finally.

I've done simple test:
long long *a;
short *b;
main()
{
  *a = 1;
  *b = 2;
  return *a;
}

I would expect gcc to be able to get the idea that *b=2 can not change a nor *a,
but it don't get any of these strict-aliasing or not. Hmm 2.95 neighter, but
it is somewhat strange. All alias sets appears to be 0.

What I am missing?

Thanks for reply,
Honza
> 
> Jason


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