Re: Infrastructural change for ENCODE_SECTION_INFO

[Alexandre Oliva <aoliva at redhat dot com>]

On Dec 18, 2000, Richard Henderson <rth@redhat.com> wrote:

> The problem I see is that (unspec [(symbol_ref "foo")] 1) appears
> to be performing some operation on the address of foo.

And that's exactly the case on multi-ISA platforms: we want to protect
certain kinds of references to symbols from having the ISA bit set, or
make it clear that other references should have the ISA bit set.
That's the problem I'm getting at right now.

> Perhaps we could add a "0" int field to the symbol_ref that would be
> free for backends to put whatever in.

Could it be an arbitrary piece of RTL?  Then, we don't risk ever
running out of bits in a const_int.

But then, a lot of places might have to be changed to take this
different bit into account.  For example, it would not always be
correct to unify, in CSE, symbol_refs that have this additional value
different.

> Perhaps we should add a link from the symbol_ref back to the tree
> decl.

How about symbol_refs that don't have a tree decl, but when we still
want to tell data references from code references?  (constant pool
entries and switch tables come to mind)

> All in all I don't consider mangling the symbol string to be
> entirely horrible.

It's not horrible, indeed.  But it takes some effort to encode section
info properly when the symbol name is protected with a `*', for
example.  Or maybe I'm just doing something wrong, because I failed to
get the information I needed at the point I needed it.

Anyway, I thought encoding the differences in RTL, instead of in
strings, would make GCC more efficient.  Maybe I'm mistaken?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me