[LLVMdev] ISRs for PIC16 [was [llvm]r79631 ...]

Sanjiv Gupta sanjiv.gupta at microchip.com
Sat Aug 22 00:00:05 PDT 2009


Chris Lattner wrote:
>
> On Aug 21, 2009, at 11:13 AM, Alireza.Moshtaghi at microchip.com wrote:
>
>>>> Add a pass to do call graph analyis to overlay the autos and frame
>>>> sections of
>>>> leaf functions. This pass will be extended to color other nodes of
>>>> the call tree
>>>> as well in future.
>>>
>>> Sanjiv, this commit, r79562 and r79563 are not the right way to tackle
>>> this problem, and are coming in the day of the release branch.  Please
>>> revert them and propose patches for these on llvmdev.
>>
>> Hi Chris
>>
>> The reason why we are doing these in backend is that cloning a function
>> is base on which functions call it and of course in frontend we don't
>> have the view of the entire call graph. We'll be happy to revert these,
>> but I would like to know exactly why in your view.
>
> We should discuss this on llvmdev, I think it came up before but there 
> was no conclusive plan that was proposed.
The approach that we thought to for for PIC16 can be described in a 
single line as below.

"Keep the functions called from ISR and main separate by cloning the  
shared ones".

>
> In short, I think that this sort of thing should be modeled as an 
> attribute on function definitions, not declarations.  I don't 
> understand why you need to clone entire call graphs, but this is best 
> discussed on llvmdev.
It isn't cloning the entire call graph. It's cloning only the shared 
ones as mentioned above.

The information that a function is ISR is encoded in the section string 
for the lack of a better attribute.

Plus we also wanted to encode some information to inform codegen about 
whether we are codegenerating an interrupt line function. Again the 
section string is used to encode the same. Probably annotations might be 
a better place but that does not work currently (and also, accessing 
them slower). This information is required so that the codegen can emit 
calls to appropriate intrinsics.

So, IMO, the approach is simple, but probably the implementation wasn't 
clean.

Ideas welcome.
>
> Trying to cram things into 2.6 at the last minute is not acceptable. 
> :)  For major things like this, it should have a real discussion about 
> the design and the way forward and the implementation should have 
> landed more than the day of the branch.
>
> -Chris
Agree. That was't a good thing on our part.

- Sanjiv






More information about the llvm-dev mailing list