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

[dag at cray.com]

Tobias Grosser <tobias at grosser.es> writes:

>> Doesn't LLVM support taking the address of a function in another address
>> space?  If not it probably should.
>
> Hi Dave,
>
> I highly appreciate your idea of integrating heterogeneous computing
> features directly into LLVM-IR. I believe this can be a way worth
> going, but I doubt now is the right moment for it. I don't share your
> opinion that it is easy to move LLVM-IR in this direction, but I
> rather believe that this is an engineering project that will take
> several months of full time work. Possibly not the implementation
> itself, but designing it, discussing it, implementing it and ensuring
> that the new feature does not increase run-time and memory footprint
> or reduce maintainability of LLVM. Due to the large amount of changes
> that would be needed all over LLVM, I really think we should first get
> some experience in this area, before we burn this feature into
> LLVM-IR.

I'm not advocating that we rush into this by any means.  I'm well aware
that the discussions and experiments will take quite a while to plow
through.  I think a small set of enhancements will go a long way.  I'd
like to avoid hacking in special intrinsics like llvm.codegen that feel
so very much in opposition to the rest of the LLVM design.

> The llvm.codegen intrinsic seems the perfect match to build up such
> experience. It requires no changes to LLVM-IR itself and only very
> local changes to the generic back end infrastructure. It may possibly
> not be as generic as other solutions, but it is far from being an ugly
> hack. Quite in contrast, it is a close match for OpenCL like run times
> and works well with the existing PTX back end.

I'll bite my tongue on the designs of OpenCL and CUDA.  :)

But regardless, if those are your targets you don't need llvm.codegen at
all.

> Do you have definitiv plans to add heterogeneous computing
> capabilities to LLVM-IR within the next couple (3-4) months? Will
> these capabilities superseed the llvm codegen intrinsic?

No specific plans to change the IR.  We have not found a need such
changes on current architectures as the runtimes provided with those
architectures handles the ugly details.  I am thinking further into the
future and what might be needed there.

> In case such plans do not exist, what do you think about adding the
> llvm.codegen() intrinsic for now? If mid-term plans exist for
> heterogeneous extensions to LLVM-IR, we can document them along the
> intrinsic.

I think it's completely unnecessary if your goal is to get something
working on current hardware.

We do have certaint structural/software engineeering changes to the
implementation of LLVM's code generator that would be useful.  This
primarily is the ability to completely process one function before
moving onto the next.  This is important when dealing with heterogeneous
systems as one has to for example write out different asm for the
various targets at a function granularity.  But that doesn't require any
IR changes whatsoever.

                                   -Dave