[llvm-dev] [RFC] Heterogeneous LLVM-IR Modules (original) (raw)

Johannes Doerfert via llvm-dev llvm-dev at lists.llvm.org
Thu Jul 30 08:56:56 PDT 2020

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

More information about the llvm-dev mailing list