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

[Sanjiv Gupta]

Jim Grosbach wrote:
> Hi Ali,
>
> Thanks for bringing this up. You're definitely under very tight design 
> constraints from the hardware. I can certainly sympathize.
Jim,
First of all, thank you very much for understanding every detail of the 
problem at our hand and coming up with a solution that addresses every 
aspect of it. IMO, given the constraints, this is probably the best 
design we can implement. In this email, my queries/observations mostly 
relate to the implementation details.
> To straightforwardly create parallel call trees, one for the mainline 
> and one for the ISR, I believe it will be best to create two versions 
> of every function that's compiled very early in the process, before 
> any lowering of frames to static addresses or anything of that sort is 
> done.The ISR-tree functions should be flagged as such and have their 
> names mangled to reflect. Any call instructions in the ISR-tree 
> function should be modified to call the equivalent ISR-tree function 
> of the callee. 
In our earlier patch, we tried to do the same thing by writing an 
llvm-ld pass. There we could clone the shared functions, their arguments 
frames and local frames to construct parallel call trees. But now it 
looks that clang will be a better place to do the same. For that, clang 
will need the appropriate TargetInfo interfaces to allow precisely the 
following things:
1. Allow targets to emit an ISR version of a function.
2. Allow targets to detect that they are emitting code for an ISR 
version, so that call sites/goto sites can be modified.
And I assume that the DebugInfo for the renamed functions will 
automatically fall in place.

My first choice would be clang to do it but was just curious to know if 
there are some inherent limitations with the llvm-ld pass approach?
> When it comes time to allocate static memory space for the call 
> frames, we simply have to do it twice. Once for the mainline 
> functions, and once for the ISR functions. We can assert that nothing 
> can overlap between the trees since we know that the trees are 
> disjoint except via the ISR itself. Thus, we don't overlay anything 
> from one tree with anything from the other tree. 
True. To overlay within these two separate trees we used an llvm-ld pass 
again. Though we overlaid only the leaf nodes in that pass but I think 
using a runOnSCC we can extend this approach to overlay sections in such 
a way that a function and any of its predecessor have separate memory 
areas. Does that approach sound ok?
> User assembly throws a big wrench into the works, but it's not 
> irreconcilable. I suggest requiring the user to flag assembly 
> functions as being either for mainline or for ISR code. Doing so via a 
> naming convention would likely tie in the easiest with the function 
> cloning done above. With the convention being sufficiently magic 
> (read: not legal C identifiers so as to avoid collisions), the 
> assembler can issue diagnostics if a call instruction is seen that 
> references a function not in the proper tree. That is, the 
> disjointness of the trees will be enforceable even in user assembly 
> with a bit of cooperation from the assembler.
We used this in the AsmPrinter to rename intrinsics called from ISR 
code. As, codgen currently ties the libcall names in ISelLowering 
constructors and then doesn't allow changing the name dynamically. So 
we'll still need to handle the same in AsmPrinter.

Thanks
- Sanjiv