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

[Johannes Doerfert via llvm-dev]

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