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

> Supporting several modules in on LLVM-IR file may not be too difficult,
> but getting this in may still be controversial. The large amount of
> changes that I see are changes to the tools. At the moment all tools
> expect a single module coming from an LLVM-IR file. I pointed out the
> problems in llc and the codegen examples in my other mail.

I replied to that mail so I won't repeat it all here.  I don't think
there's any problem given current technology.  Since I don't know any
details (only speculation) about what's coming in the future, I can't
comment beyond that.

>> Again, we have many of the changes to make this possible.  I hope to
>> send them for review as we upgrade to 3.1.
>
> Could you provide a list of the changes you have in the pipeline and a
> reliable timeline on when you will upstream them? How much additional
> work from other people is required to make this a valuable replacement
> of the llvm.codegen intrinsic?

I'll try to recall the major bits.  I did this work 3-4 years ago...

I think the major issue was with the AsmPrinter.  There's global state
kept around that needs to be cleared between invocations.  The
initialization step needs to be re-run for each function but there are
some tricky bits that should not happen each run.  That is, most of
AsmPrinter is idempotent but not all.

Label names are a big issue.  A simple label counter (L0, L1, etc.) is
no longer sufficent because the counter gets reset between invocations
and you end up with multiple labels with the same name in the .s file.
We got around this by including the (mangled) function name in the label
name.

I had to tweak the mangling code a bit so that it would generate valid
label names.  I also consolidated it as there were at least two
different implementations in the ~2.5 codebase.  I don't know if that's
changed.

We don't use much of opt at all.  I'm sure there are some issues with
the interprocedural optimizations.  We didn't deal with those.  All of
our changes are in the llc/codegen piece.

As for getting it upstream, we're moving to 3.1 as soon as it's ready
and my intention is to push as much of our customized code upstream as
possible during that transition.  The above work would be a pretty high
priority as it is a major source of conflicts for us and I'd rather just
git rid of those.  :)

So expect to start seeing something within 1-2 months.  Unfortunately,
we have bureaucratic processes I have to go through here to get stuff
approved for public release.

> Where exactly do you see problems with this intrinsic? It is not meant
> to block further work in heterogeneous computing, but to allow us to
> gradually improve LLVM to gain such features. It especially provides a
> low overhead solution that adds working heterogeneous compute
> capabilities for major GPU targets to LLVM. This working solution can
> prepare the ground for closer integrated solutions.

It feels like a code generator bolted onto the side of opt, llc,
etc. with all of the details that involves.  It seems much easier to me
to just go through the "real" code generator.

                           -Dave