Reinstate mips16/nomips16 attribute support

Richard Sandiford
Fri Sep 14 15:18:00 GMT 2007

Nigel Stephens <> 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.


More information about the Gcc-patches mailing list