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

[Justin Holewinski]

On Tue, May 1, 2012 at 8:22 AM, <dag at cray.com> wrote:

> 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.  :)
>

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.


>
> > 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.
>

Sorry, I meant global variables in the LLVM IR.  Are they valid for only
one architecture in the IR module?


>
> > 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.
>

Maybe, maybe not.  It may make sense to rely on run-time JIT'ing of the PTX.


>
> > 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.
>

That could work.


>
>                                 -Dave
>



-- 

Thanks,

Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120501/b3638e1a/attachment.html>