This is the mail archive of the 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: [RFA/PATCH]: sh64: Unnecessary use of datalabel operator

> From: Joern Rennecke [] 
> Sent: Thursday, August 08, 2002 3:19 PM

> Do we document anywhere that the selection of SHmedia code vs. data
> and SHcompact (where applicable) addresses is made by default
> depending on the contents of the target?

The selection is made based on the attributes of the symbol
being referenced.

It's documented in

> Is it safe to assume that no implmentation of the GOT will use
> code fragments at the start (maybe even embedding the plt for
> small programs), thus making references to the got
> defaulting to use a code address?

Shouldn't be a problem.   Provided you give the correct
attributes to the symbol marking the base of the GOT it
would work fine.

i.e. the symbol _GLOBAL_OFFSET_TABLE_ should be considered a
data symbol, and should not be given the STO_SH5_ISA32 attribute,
even if there is SHmedia code at the base of the GOT.

If you did have code at the start of the GOT, you may well
want to have a symbol marking it, and have branches to that symbol.
If _GLOBAL_OFFSET_TABLE_ is a data symbol, it would not be
possible to use it for these branches.
You'd need to have another symbol marking the start of the
GOT, which has the STO_SH5_ISA32 attribute set iff the code at the
start of the GOT was SHmedia code.  References that need to treat
the start of the GOT as code would have to use this other symbol.

An alternative would be to keep the datalabel decoration
on references to _GLOBAL_OFFSET_TABLE_ just in case someone
puts code there, but to me that seems messier: notionally
_GLOBAL_OFFSET_TABLE_ is a data symbol.

> While it makes sense to wrap CONST around an UNSPEC, it does not
> make sense to do so for SYMBOL_REF or LABEL_REF, and doing so
> means creating un-canonical rtl.
> So, instead of making the working code grok this uncanonical rtl,
> you should make sure that it is not generated in the first place.

Okay, I wasn't aware of that ... I'll work on this change.

> Depending on how straightforward this check and/or fix is, and
> how confident you feel that it will stay fixed, you might want to
> put sanity checks into the print_operand* functions.

Okay, I'll take a look at that.


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