PATCH: mips16 function attributes, version N+1

[Nigel Stephens]

Richard Sandiford wrote:
> Nigel Stephens <nigel@mips.com> writes:
>   
>> Richard Sandiford wrote:
>>     
>>>> I tried this, and yes, it does cause about half a dozen of the tls tests 
>>>> to fail with -mflip-mips16.  Rather than trying to mess with 
>>>> conditionalizing those, how about if I just leave the sorry message in, 
>>>> and document that this is one of the things that doesn't work yet?  In 
>>>> extend.texi I've already written:
>>>>
>>>>    Mixed MIPS16 and non-MIPS16 code may interact badly with some GCC
>>>>    extensions such as @code{__builtin_apply} (@pxref{Constructing
>>>>    Calls}).
>>>>
>>>> so I could just add:
>>>>
>>>>    and thread-local variables (@pxref{Thread-Local}).
>>>>     
>>>>         
>>> My understanding is that __builtin_apply is only going to be troublesome
>>> for calls between non-MIPS16 and MIPS16 hard-float code.  Each side is
>>> abiding by the correct ABI for its own mode, but the linker's stubs
>>> support can't help us.  Although it is of course a solvable problem,
>>> it's not a particularly worrying one, since __builtin_apply is one of
>>> those things we keep meaning to get rid of...
>>>
>>> TLS is different because emultls is not supposed to be used for MIPS
>>> at all.  
>>>       
>> Although it shouldn't be required for Linux configurations, I imagine 
>> that it could be useful to support emutls for bare-iron /RTOS 
>> configurations. But it's a new feature for SDE and not yet on the 
>> required feature list, so this is something that we can revisit at a 
>> later date.
>>     
>
> It's a separate issue to the mips16/nomips16 patch anyway.  

Yes, and as I said, I don't consider it to be part of this current contract.

> If certain
> configurations want to force the use of emultls, they can do it regardless
> of this patch.  I don't see how it would interfere with your decision.
> (If anything, the change I suggested should make it even easier to force
> have_tls to false for certain configurations, as nothing in mips.c will
> mess with it.  And the sorry() would only trigger when emultls is _not_
> used.)
>
> Out of interest: -mno-abicalls already selects local-exec-style accesses
> for all TLS variables.  Wouldn't it be more efficient to use those instead?
> Especially for parts that implement the "rdhwr...$29" in h/w.  

Of course, for non-MIPS16 code, and for those processors that actually 
implement RDHWR 29 that's true, but currently that's only a couple of 
our newest (not yet released) core revisions. We'd also need to be sure 
that any RTOS was going to context switch the value in HWR 29 -- not 
terribly hard, but if it doesn't support TLS already then there would be 
work there. I guess I thought that emutls would "just work" on any OS 
that support pthreads-style thread local data, and was therefore valuable.

Bit of a problem that MIPS16 doesn't have rdhwr, I suppose MIPS16 could 
just emit a libcall to fetch the thread pointer, or just fall back to 
local-dynamic and use a call to __tls_get_addr

> You could
> always get the linker to stash size of the thread-local data in some
> well-known variable, so that you don't need access to the TLS segment
> at runtime.  

Good idea.
> Or is it a requirement to use an unmodified thread library?
>
>   

I guess it depends on the OS. For some we have access to the source 
code; for those where we don't it might be useful to have libgcc fill 
the gap.

Nigel