Re: Reinstate mips16/nomips16 attribute support

[Richard Sandiford <richard at codesourcery dot com>]

Nigel Stephens <nigel@mips.com> writes:
> Richard Sandiford wrote:
>> 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.

Right, that's what I meant.  That's what DJ wanted too.  In the MeP
case I mentioned, calls between "core" and non-line "vliw" functions
are also fine (and likewise with the attributes swapped round).  We just
didn't want to inline one mode into the other.

Richard