This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Symtab cleanup 6/17: fix handling of constructors of aliases
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, gcc-patches at gcc dot gnu dot org
- Date: Mon, 17 Jun 2013 13:58:07 +0200
- Subject: Re: Symtab cleanup 6/17: fix handling of constructors of aliases
- References: <20130617095357 dot GA3276 at kam dot mff dot cuni dot cz> <CAFiYyc3NV89GkbAczZLc9g71T9BtN-7EggAWiqeP5nhM1vP=2Q at mail dot gmail dot com>
> On Mon, Jun 17, 2013 at 11:53 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
> > Hi,
> > this patch makes it possible to fold through aliases. It may seem unimportant, but we
> > run into those cases in C++ where extra name aliases may get used by devirtualization
> > machinery. The patch also fixes the following long standing bug:
> > jh@gcc10:~/trunk/build2/gcc$ cat t.c
> > static int a=4;
> > static int b __attribute__ ((alias("a")));
> > main()
> > {
> > return b+a;
> > }
>
> The gimple alias machinery also happily treats a and b as different decls
> btw (so does the PTA code). To fix that the lookups have to be fast
> (no hashtable query at least for the case where there is no alias).
Yep, I know. There are a lot more wrong code issues with aliases.
Basically things works on assumption that you nmever use original and the
alias together. This breaks badly with LTO.
I have hashtable lookup in my tree and it seems to not be bottleneck, but definitely
we either can finally move to have direct symtab pointer in decl node or have flag
if decl is an alias.
Honza