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

On 7/30/20 8:48 AM, Renato Golin wrote:
> On Thu, 30 Jul 2020 at 13:59, Johannes Doerfert via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> FWIW, I would expect that we split the module *before* the codegen
stage
>> such that the back end doesn't have to deal with heterogeneous
models
>> (right now).
> Indeed. Even if the multiple targets are all supported by the same
> back-end (ex. different Arm families), the target info decisions are
> too ingrained in how we created the back-ends to be easy (or even
> possible) to split.
Right, and I don't see the need to generate code "together" ;)

>> I'm not sure about cost models and such though. As far as I know,
we
>> don't do global decisions anywhere but I might be wrong. Put
>> differently, I hope we don't do global decisions as it seems quite
easy
>> to disturb the result with unrelated code changes.
> Target info (ex. TTI) are dependent on triple + hidden parameters
> (passed down from the driver as target options), which are global.
>
> As I said before, having multiple target triples in the source will
> not change that, and we'll have to create multiple groups of driver
> flags, applicable to different triples. Or we'll need to merge modules
> from different front-ends, in which case this looks more and more like
> LTO.
>
> This will not be trivial to map and the data layout does not reflect
> any of that.
So in addition to multiple target triples and DLs we would probably want 
multiple target info objects, correct?

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.

I mean, wouldn't that allow us to make `clang -emit-llvm` followed by 
`opt` behave more like a single `clang` invocation?

If so, that seems desirable ;)


~ Johannes



[0] https://reviews.llvm.org/D80750#2180284

>
> cheers,
> --renato

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 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.

--renato

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