This is the mail archive of the gcc-patches@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: Allow cgraph nodes to change name


> Jan Hubicka <hubicka@ucw.cz> writes:
> 
> > > Geoff Keating <geoffk@geoffk.org> writes:
> > > 
> > > >> > I think a better approach would be to ensure that function's assembler
> > > >> > names are set exactly once, rather than being set (to the wrong value)
> > > >> > and then changed later.  I fixed a bunch of places where this was done
> > > >> > recently, and so far as I know this is the last place.
> > > >> 
> > > >> It may be also possible to simply produce RTL name before we insert the
> > > >> node, but I was under impression that for C++ it is expensive to produce
> > > >> it and that is why we do so lazily on demand.
> > > >
> > > > This won't work if the RTL name is wrong.  The problem here is that
> > > > even in C, when you have
> > > >
> > > > extern void foo (void) asm ("bar");
> > > >
> > > > then DECL_ASSEMBLER_NAME starts off by being set to "foo", and then
> > > > later is changed to "bar".  Naturally, this confuses the cgraph code
> > > > (and intermodule analysis, and weak symbols, and everywhere else that
> > > > tries to look at the assembler name).
> > > 
> > > Probably the best solution is to generate DECL_ASSEMBLER_NAME
> > > extremely lazily or else when forcibly set, as is currently done for
> > > DECL_RTL.
> > > 
> > > I suspect this works better if unit-at-a-time mode is always on.
> > 
> > In unit-at-a-time mode I use DECL_ASSEMBLER_NAME at the time function is
> > inserted into the database that usually happens at first reference or
> > definition of it, so it is not lazy enought.
> > 
> > Another alternative is that in fact I don't need the hashtables.
> > Only what I use it for is to convert DECL nodes into cgraph nodes.  The
> > problem is that cgraph nodes are unique for function while DECL nodes
> > are not, but perhaps frontends already have some capability of tracking
> > this down.  Do you think it would be possible to add a direct pointer
> > into the nodes and track it down using it?
> 
> This adds an extra pointer to the tree nodes, which is discouraged
> when there is an easy alternative.

Well, I am not sure whether putting the decls into hash table is any
cheaper, but I agree that this can be dealt with separately.
> 
> As I said before,
> 
> > I think a better approach would be to ensure that function's assembler
> > names are set exactly once, rather than being set (to the wrong value)
> > and then changed later.
> 
> and I believe this is easy and will work.  I don't see how it matters
> whether the name is generated lazily or not, so long as it doesn't
> change once it's set.

I am still not too familiar with the frontend, but I believe the problem
is that the declaration actually may change it's name during the parsing
(by forward declaration followed by another one with assembler name
attribute set and such) or not?  Can you please slightly more explain me
how this can be done?

Honza
> 
> -- 
> - Geoffrey Keating <geoffk@geoffk.org>


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