[LLVMdev] [PATCH][RFC] Add llvm.codegen Intrinsic To Support Embedded LLVM IR Code Generation

[dag at cray.com]

Justin Holewinski <justin.holewinski at gmail.com> writes:

>     I don't think the code base changes are all that bad.  We have a number
>     of them to support generating code one function at a time rather than a
>     whole module together.  They've been sitting around waiting for us to
>     send them upstream.  It would be an easy matter to simply annotate each
>     function with its target.  We don't currently do that because we never
>     write out such IR files but it seems like a simple problem to solve to
>     me.
>
> If such changes are almost ready to be up-streamed, then great!

Just to clariofy, the current changes simply allow a function to be
completely processed (including asm generation) before the next function
is sent to codegen.

> It just seems like a fairly non-trivial task to actually implement
> function-level target selection, especially when you consider function
> call semantics, taking the address of a function, etc.

For something like PTX, runtime calls take care of the call semantics so
it is either up to the user or the frontend to set up the runtime calls
correctly.  We don't need to completely solve this problem.  Yet.  :)

> If you have a global variable, what target "sees" it?  Does it need to
> be annotated along with the function?  

For a tool like llc, wouldn't it be simply a matter of changing
TheTarget and reconstituting the various passes?  The changes we have
waiting to upstream already allow us to reconstitute passes.  I
sometimes use this to turn on/off debugging on a function-level basis.

The way we've constructed our backend interface should just allow us to
switch the target and reinitialize everything.  I'm sure I'm glossing
over tons of details but I don't see a fundamental architectural problem
in LLVM that would prevent this.

> Can functions from two different targets share this pointer?  

Again, in the case of PTX it's the runtime's responsibility to ensure
this.  I agree passing pointers around complicates things in the general
case but I also think it's a solvable problem.

> For Yabin's use-case, the X86 portions need to be compiled to
> assembly, or even an object file, while the PTX portions need to be
> lowered to an assembly string and embedded in the X86 source (or
> written to disk somewhere).  

I think it's just a matter of switching to a different AsmWriter.  The
PTX runtime can load objects from files.  The code doesn't have to be a
string in the x86 object file.

> If you're targeting Cell, in contrast, you'd want to compile both down
> to object files.

I think we probably want to do that for PTX as well.

> For me, the bigger question is: do we extend the IR to support
> multiple targets, or do we keep the one-target-per-module philosophy
> and derive some other way of representing how the modules fit
> together?  I can see pros and cons for both approaches.

Me too.

> What if instead of per-function annotations, we implement something
> like module file sections?  You could organize a module file into
> logical sections based on target architecture.  I'm just throwing that
> out there.

Do we allow more than one Module per file?  If not, that seems like an
arbitrary limitation.  If we allowed that we could have each module
specify a different target.

                                 -Dave