RE: [RFA/PATCH]: sh64: Unnecessary use of datalabel operator

["Clarke, Stephen" <stephen dot clarke at superh dot com>]

> From: Alexandre Oliva [mailto:aoliva@redhat.com] 
> Sent: Tuesday, August 13, 2002 2:05 PM
> 
> On Aug 13, 2002, "Clarke, Stephen" <stephen.clarke@superh.com> wrote:
> 
> > Looking over it again, that document talks about "SHmedia symbols",
> > i.e. symbols with the STO_SH5_ISA32 attribute, without ever defining
> > what an "SHmedia symbol" is.
> 
> Hmm...  I assumed a SHmedia symbol was supposed to be read as any
> symbol defined while SHmedia mode was in effect.

A justifiable assumption, given the information available to you ;-)
Though that's not what gas does: for example, gas does not give the
STO_SH5_ISA32 attribute to symbols defined in data sections.
 
> It's not clear to me how expensive it actually is,
> other than for additional assembly code.  Do you have any benchmarks
> on how much savings you get, in terms of build time and object size,
> after you install your patch?  (This is not meant as a requirement to
> get the patch in, I'm just curious).

Sorry, I don't have any performance information.  If I can think of a
big link to try it out on, I'll take some measurements of the effect on
object size and link time.

There is a comment in bfd/elf32-sh64.c that suggests there may be a 
potential performance problem, but it also suggests a way to fix this.

> However, we might as well somehow specify a set of defined cases and
> rule that anything else invokes undefined behavior.  Or perhaps do it
> the other way round.  Say, if you reference a external symbol assuming
> it is a data symbol, but not using DATALABEL, and it turns out to be
> untyped and part of an executable section, you lose.  This is already
> true with the current implementation, but since we're relaxing the
> rules about when you have to use datalabel, we'd better list at least
> situations in which behavior may change if you omit datalabel.

Okay.

I've been wondering recently about how datalabel references should
be represented in dynamic symbol tables.  Currently there's no
support for this at all.  I guess they can be represented in
the same way as they are in normal symbol tables, but I would think
that ld could remove almost all the unnecessary dynamic datalabel
references because it can determine that they are to data symbols.

I'm assuming that changing the code/data type of a symbol
defined in a shared object would constitute an interface
change, so ld can assume it's the same at static link time as
it is at dynamic link time.

However, I don't see that changing the STO_SH5_ISA32 attribute
of a symbol in a shared object (for instance by recompiling it
for the other ISA) would be an interface change.

> But then, since behavior may change in situations the compiler can't
> control, I think I'd rather still have the compiler emit datalabel all
> over, even if redundant, just to make sure its code references symbols
> the way it intends.  Of course, this doesn't stop us from making the
> assembler smarter as to marking symbols as STO_SH5_ISA or not.  Does
> this sound reasonable?

It seems like you want to give defined behaviour to a
situation that I consider to be undefined.

I think it's okay for the compiler to use datalabel in controlled
circumstances, in ways that aren't exposed in a high-level
language.

But it seems like you want the compiler to cope with the possibility
that the type of a symbol (code or data) is lied about at the
high-level language level?  For example, that a data declaration
may actually be a function in another module?
This scenario sounds problematic in other ways: for example, alias
analysis can assume that function and data symbols do not alias.

Steve.