This is the mail archive of the
mailing list for the GCC project.
Re: spec2000 regression
> > >>>>> "Jan" == Jan Hubicka <email@example.com> 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;
> *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.
Oops, update - I was calling incorrect 2.95
2.95 does get it:
current tree does not:
movl %esp, %ebp
movl a, %eax
andl $-16, %esp
movl $1, (%eax)
movl b, %eax
movw $2, (%eax)
movl a, %eax
movl (%eax), %eax
movl %ebp, %esp
so I would guess that something must be wrong... But it can be unrelated to your change of course.
> What I am missing?
> Thanks for reply,
> > Jason