[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:

>     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.  :)
>
> But there has to be some interface that allows an LLVM IR function
> from one architecture to get at the code or name of a function from
> another architecture.  This could be handled in the front-end, but it
> seems like we could design some abstraction.

Doesn't LLVM support taking the address of a function in another address
space?  If not it probably should.

>     > If you have a global variable, what target "sees" it?  Does it need to
>     > be annotated along with the function?
>    
> Sorry, I meant global variables in the LLVM IR.  Are they valid for
> only one architecture in the IR module?

Ah.  It very much depends on the system architecture.  Since current PTX
targets run in an entirely separate address space globals would have to
be replicated and copied to/from the device.  This might require
target-specific modules.

For a system with shared memory, I would assume the globals could simply
be shared "as usual."  Otherwise, it wouldn't be shared memory.  In a
target-specific module design, one or the other would be an extern
reference.

>     > 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.
>
> Maybe, maybe not.  It may make sense to rely on run-time JIT'ing of the PTX.

That happens regardless.  There is no way to produce instructions "to
the metal" for NVIDIA targets.  I was referring to PTX object files
above.

>     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.
>
> That could work.

Given your questions about globals above, I think it might be a
requirement unless we want to require code for separate targets live in
separate files.  I think that's too restrictive because some opt pass
might want to extract kernels and put them on separate targets.

                              -Dave