On Aug 27, 2009, at 2:02 PM, Alireza.Moshtaghi at microchip.com
wrote:> Extended thanks to the llvm community for feedback in advance, and
> especially thanks to Jim for laying out a solution that captures all
> aspects of the problems that we are facing. After some discussions
> with
> our team, we have decided to do the following, but to avoid further
> conflict with llvm standards, I would like to get the blessing of llvm
> community, and in particular, Chris who at some point expressed
> concerns
> about cloning the entire function hierarchy ...
Ok, fwiw, I think that Jim's outlined approach is a good one.
> Here I'm trying to stick to implementation and solicit your feedback
> regarding whether we are doing them in the right place.
>
> In summary, the discussion is comprised of three topics:
> 1) Separating the context of main vs isr functions
> 2) Function frame Overlay (function coloring)
> 3) Handling of Intrinsics for non-native operations
>
> Implementation for (1)
> I see Jim's suggestion - to duplicate all functions - at the center of
> the solution. I think doing this in the front-end (clang) makes the
> problem too widespread. An llvm-ld pass keeps the logic and
> implementation all at one place which is more manageable; so we prefer
> llvm-ld pass. Naturally by adopting a naming convention, there will be
> no need to add information to section attribute.
> With minor modification of what Jim suggested regarding function
> pointer
> descriptors, code alterations for function pointers can be done either
> in the same llvm-ld pass or while custom lowering CALL node. I prefer
> the former because we have to modify all call sites in the duplicated
> functions anyways; why not extend it to do the indirect calls as well?
Seems reasonable to me.
> Implementation for (2)
> This wouldn't be much different from what we did in the patch we sent:
> Add an llvm-ld pass to color the functions (same color function frames
> will be overlaid). The pass will add the color information to the
> section attribute of the function, and this information will be used
> by
> AsmPrinter to construct appropriate section information in assembly
> output.
Ok.
> Implementation for (3)
> Conceptually speaking, similar to (1) we have to separate the
> context of
> intrinsic functions for mainline vs ISR. But in practice we can't take
> the same approach as (1). Front-end does not generate custom calls for
> non-native operations; so we generate calls to intrinsics while
> lowering.
Right.
> We provide two sets of intrinsic functions in the port
> specific library and appropriate function call will be generated
> depending on whether we are in ISR or mainline code. The right way of
> doing this is to keep all the logic in legalizer - use the existing
> infrastructure and customize the library calls for each non-native
> operation; however, this requires a patch on llc to allow
> customization
> of soft floating point library calls. This patch currently breaks ARM
> port so until we find time to refactor ARM, we will keep the
> implementation in AsmPrinter (a little more work, but it is already
> done).
I don't really understand your proposal here, what exactly would
change to support this?
-Chris