Re: RFA: Remove TARGET_SWITCHES from the SH port

Re: RFA: Remove TARGET_SWITCHES from the SH port

[Joern RENNECKE]

Alexandre Oliva wrote:

>On May 15, 2005, Richard Sandiford <rsandifo@redhat.com> wrote:
>
>  
>
>>Also, superh.h and superh64.h define something called
>>TARGET_PROCESSOR_SWITCHES.  This macro doesn't seem to be used
>>anywhere, and as far as I can tell, the headers themselves aren't
>>included by any configuration.  The patch simply deletes them.
>>Is that OK?
>>    
>>
>
>I'll leave that for Joern to explain.  I didn't know about these
>headers myself.
>  
>

These headers are supposed to be included by the sh-superh-elf / 
sh64-superh-elf
configurations.  However, we can't do this right now, because some more 
merge
issues need to be resolved, and we also need to fix some problems in gas, ld
and libgloss.  The -m4-100 / -m4-200 options would also make sense to 
select the
cache associativity in the used ic_invalidate_array.

I think we should address the gas / ld issues first, because gcc depends 
on the features
there.  the align_load_span optimization is applied when relaxing unless

(elf_elfheader (abfd)->e_flags & EF_SH_MACH_MASK) == EF_SH4)
- that test is in elf32-sh.c:sh_elf_relax_section - or
(abfd->arch_info->mach == bfd_mach_sh4)
- that test is in coff-sh.c:_bfd_sh_align_load_span .

When using -mrelax for an SH4 target, the compiler passes -isa=sh4 to 
the assembler.
Now, this is incompatible with -m4-400i, which  passes -isa=sh4-nommu-nofpu,
and-m4-500, which passes -isa=sh4-nofpu to the assembler.

To make this work properly, for -mrelax we should pass 
-isa=sh4-nommu-nofpu-up,
make the assembler merge multiple -isa options when they are compatible, and
make the linker elide the align_load_span transformation for the entire 
sh4 mach
family.  Sould we also elide it for the sh2a and sh4a families?

If that is the case, we can do the test in the linker as requiring that 
one of
the bits  arch_sh1_base, arch_sh2_base, arch_sh2a_sh3_base and arch_sh3_base
is set in the internal arch representation.  Of course we'd like to wrap 
this in
a sh-opc.h macro to avoid exposing too much of the internals.