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

>> But regardless, if those are your targets you don't need llvm.codegen at
>> all.
>
> Why is it not needed? I don't see anything that could currently
> replace it. How can I create a loadable optimizer module that creates
> embedded PTX code without the llvm.codegen intrinsic?

Embed the PTX as a string in the x86 object/executable.  This requires
that the AsmPrinter can be directed to multiple files but it doesn't
require any IR changes at all.  Actually, since your modules are
independent it doesn't even require AsmPrinter changes.

>> 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.
>
> OK. I am talking about something that is available within the next
> weeks in LLVM.

Then you don't need a special intrinsic.

>> I think it's completely unnecessary if your goal is to get something
>> working on current hardware.
>
> Again, why is it unnecessary?

See above.

>> 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.
>
> At least for CUDA/OpenCL the modules are entirely independent. Is such
> a fine granularity realy required?

If they're independent, no.  In our case the (to us) frontend extracts
kernels and send them to codegen they same way it sends x86 code.

Originally I did this for scalability purposes.  We could not compile
very large codes when LLVM insisted we keep all the IR around all the
time.  We had to get rid of that restriction which led to the
function-at-a-time model.  It just happens that it works well for
current accelerators.

                        -Dave