[LLVMdev] LLVM and Interrupt Service Routines.

Sanjiv Gupta sanjiv.gupta at microchip.com
Mon Jul 27 10:27:06 PDT 2009


Alireza.Moshtaghi at microchip.com wrote:
>> If you have to generate two copies of the function with different
>> entrypoints, the *front-end* should handle the duplication.  This is
>> just like C++ constructors.
>>
>> One really old patch that apple guys experimented in the past was a
>> "slow and fast call" attribute, which you could stick on function
>> declarations.  If you added it to a function, the frontend would
>> generate an entry point with a standard calling convention as well as
>> one with a faster in-register ABI.  Direct calls would use the fast
>> entry point, but if you took the address, you'd get the address of the
>> normal one.
>>
>> All of this was handled by the front-end, and works fine.  I think the
>> patch eventually got ripped out of the compiler for other reasons
>> though.
>>     
>
>
> I see 2 problems with this approach:
> 1 - Front end does not know which functions need to be cloned. The
> cloned functions are the ones that are called both from ISR thread and
> main thread; and this information is not available until all compilation
> units are merged. We collect this information in a pass at the end of
> llvm-ld.
> 2- Based on what you propose, for example the ISR thread would need to
> make indirect call to cloned function; and main thread make direct call
> to original function. Apart from the performance issue on PIC16 in
> relation to indirect function calls, if the main thread already makes
> indirect call to the function, then the same function would be called
> from both threads, and the original problem is still there
>
> A.
>
>   
And the third problem, which I mentioned earlier is about intrinsics 
(libcalls); because the front-end won't have any idea of those.

- Sanjiv

>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>   




More information about the llvm-dev mailing list