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

[Joern Rennecke]

Clarke, Stephen wrote:
> Gcc for sh64 applies the datalabel operator to all non-function
> symbol references.
> 
> This is unnecessary: the datalabel operator is only required in
> the rare circumstance that you require the true address of a code
> symbol, rather than the address plus the ISA encoded in the lowest
> bit.  In particular, it should never be necessary to apply
> datalabel to a data symbol.
> 
> The only places in gcc output I can think of where datalabel
> is truly necessary is in the code sequence generated for a case
> jump table, and for the address of a trampoline template.  Please
> tell me if there are others.
> 
> The many unnecessary uses of datalabel make the .s file larger
> and less readable.  They also require extra processing in the
> assembler and linker, and make symbol tables bigger in objects
> and dynamic objects.

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?

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?

> The attached file contains a patch to remove the generation of
> datalabel, except in the places it is needed.  It has been
> regression tested on sh64-elf/sh64-sim and sh-elf/sh-hms-sim.

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.

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.