Reinstate mips16/nomips16 attribute support

Nigel Stephens nigel@mips.com
Fri Sep 14 14:38:00 GMT 2007



Richard Sandiford wrote:
> Nigel Stephens <nigel@mips.com> writes:
>   
>> Richard Sandiford-3 wrote:
>>     
>>>   3) Turning "mips16" and "nomips16" attributes into decl attributes
>>>      (as per (1)) prevented inlining.  The question is whether this is
>>>      good or not.  It seems natural to disallow the attributes on
>>>      always_inline functions in particular, because it doesn't make
>>>      sense to specify a mode on a function that is never compiled
>>>      out-of-line.  However:
>>>
>>>       (a) That would clash with the strict rules for nested functions.
>>>           glibc in particular has nested always_inline functions,
>>>           and that shouldn't stop the user from adding a mips16 or
>>>           nomips16 attribute to both the nested function and its parent.
>>>
>>>       (b) Normal inline functions _might_ be compiled out-of-line, and it
>>>           seems reasonable for the attributes to control how such an
>>>           out-of-line copy is compiled.
>>>
>>>      So I think we should allow these attributes on inline functions.
>>>      The patch defines TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P accordingly.
>>>       
>> Hmm, I'm not so sure about this. You would have problems if your were using
>> the mips16/nomips16 attribute on a function which included an "asm"
>> instruction which was specific to that particular ISA mode. You would be
>> happy for that to be inlined into another function of the same ISA mode, but
>> not into the other. Could you somehow prevent inlining of functions
>> containing an asm?
>>     
>
> I don't think there's a way of doing specifically that, no.
>
> I think the more general idea is similar to what DJ wanted to do
> for MeP.  There we want to allow "core" inline functions and "vliw"
> inline functions, but only allow "core" functions to call "core"
> inline functions and only allow "vliw" functions to call "vliw"
> inline functions.  I'm not sure we support that either yet.
>   

Well, we don't mind a mips16 function calling a nomips16 function, but 
in general we probably don't want to inline an explicitly nomips16 
function into a mips16 one. As well as asm() there are things like DSP 
builtins that wouldn't work if they got inlined into a mips16 function. 
That was why the original implementation of this feature made any 
function with such an attribute non-inlinable.

Really what we need is for the tree inliner code to call a target hook 
with a pair of fndecl arguments -- caller and callee -- so that a target 
backend could check that the two functions had compatible modes for 
inlining.

Nigel



More information about the Gcc-patches mailing list