[llvm-dev] [RFC] Heterogeneous LLVM-IR Modules

[Johannes Doerfert via llvm-dev]

On 7/30/20 10:01 AM, Renato Golin wrote:
 > On Thu, 30 Jul 2020 at 15:09, Johannes Doerfert
 > <johannesdoerfert at gmail.com> wrote:
 >> At this point I ask myself if it wouldn't be better to make the target
 >> cpu, features, and other "hidden parameters" explicit in the module 
itself.
 >> (I suggested part of that recently anyway[0].) That way we could 
create the
 >> proper target info from the IR, which seems to me like something
 >> valuable even in the current single-target setting.
 >
 > This is still not enough. Other driver flags exist, which have to do
 > with OS and environment issues (incl. user flags) that are not part of
 > the target description and can affect optimisation, codegen and even
 > ABI.
 >
 > Some of those options apply to some targets and not others. If they
 > apply to all targets you have, the user might want to apply to some
 > but not all, and then how will this work at cmdline side?

I can see that we want different command line options per target in the
module. Given that we probably want to allow one pass pipeline per
target, maybe we keep the options but introduce something like a
`--device=N` flag which will apply all following options to the "N'th"
pipeline. That way you could specify things like:
   ` ... --inline-threshold=1234 --device=2 --inline-threshold=5678`

For TTI and such, the driver would create the appropriate version for
each target and put it in the respective pipeline, as it does now, just
that there are multiple pipelines.

My idea in the last email was to put the relevant driver options
(optionally) into the IR such that you can generate TTI and friends from
the IR alone. As far as I know, this is not possible right now. Note
that this is somewhat unrelated to heterogeneous modules but would
potentially be helpful there. If we would manifest the options though,
you could ask the driver to emit IR with target options embedded, then
use `opt` and friends to work on the result (w/o repeating the flags)
while still being able to create the same TTI the driver would have
created for you in an "end-to-end" run. (I might not express this idea
properly.)


 > I don't know the extent of what you can combine from all of the
 > existing global options into IR annotations, but my wild guess is that
 > it would explode the number of attributes, which is not a good thing.

I mean, you can put the command line string that set the options into
the first place, right? That is as long as it initially was, or maybe I
am missing something.

To recap things that might "differ" from the original proposal:
   - We          want multiple target triples.
   - We probably want multiple data layouts.
   - We probably want multiple pass pipelines, with different (cmd
     line) options and such.
   - We might want to make modules self contained wrt. target options
     such that you can create TTI and friends w/o repeating driver
     options.

~ Johannes


 > --renato