Re: interest for ARM/thumb multiversionning ?

[Christian Bruel <christian dot bruel at st dot com>]

to clarify, my use case was slightly more different than the x86 that
requires a runtime cpu-check builtin. I was more focused on a link time
problem (so we don't even need to go thu a function ptr)

Christian

On 04/30/2015 08:45 AM, Christian Bruel wrote:
> 
> 
> On 04/29/2015 05:36 PM, Ramana Radhakrishnan wrote:
>>
>>
>> On 29/04/2015 09:24, Christian Bruel wrote:
>>> Hi Ramana, Richard
>>>
>>> After playing with the attritute ((target ("[thumb,arm]")), during the
>>> pending review, I added the "default" selector to neutralize
>>> -mflip-thumb for the setjmp/longjmp based tests.
>>>
>>> I was wondering it there would be an interest leverage on this to
>>> implement multiprocessing, like on the x86 ?
>>>
>>
>> You mean multiversioning ? How would the dispatcher work in this case ?
> 
> not sure what you mean, the fonction's name will need to be mangled with
> the target specialization. The dispatching would be made based on the
> caller mode.
> 
> Could it  be also a direction to help LTOization with the proper FPU
> flags (follow bz target/65837) given at link time.
> 
> My concern is that this is limited to C++ for x86. I haven't checked the
> details, just ideas.
> 
> Cheers
> 
> Christian
> 
>> Ramana
>>
>>> something that would allow (from the x86 doc)
>>>
>>> __attribute__ ((target ("default")))
>>> int foo ()
>>> {
>>>    asm("...");
>>> return 0;
>>> }
>>>
>>> __attribute__ ((target ("thumb")))
>>> int foo ()
>>> {
>>>    asm("...");
>>> }
>>>
>>> int main ()
>>> {
>>> int (*p)() = &foo;
>>> assert ((*p) () == foo ());
>>> return 0;
>>> }
>>>
>>> I had initially not planned to do it, but this is a simple extension of
>>> the attribute target, if someone find a use for this I can implement it
>>> on the fly.
>>>
>>> Best Regards,
>>>
>>> Christian
>>>