[cfe-dev] Passing StructType arguments directly

[David Meyer]

Devang,

The immediate benefits:

* Front-ends would no longer need to implement the ABIs for each
target architecture to get full ABI compliance. They would generate
high-level bitcode, and the ABI lowering knowledge would be contained
in LLVM.

* Bitcode-level ABI compatibility between different front-ends (for
LTO), since there would be a unique lowering from C signatures to
high-level bitcode.

* The high-level format could become the wire format for portable
applications (e.g. PNaCl)

* You could make the lower-level format even more lower-level, by, for
example, getting rid of struct. (turning struct into a high-level-only
type)

Longer-term benefits:

* Greater flexibility to control the bridge between the frontends and
backends. The frontends benefit from being able to emit a higher-level
IR, while LLVM's CodeGen and optimizers benefit from working with a
lower-level IR.

* Access to a higher-level representation may permit new kinds of
analysis for optimizations, research or debugging.

I hesitate to suggest another layer, but this seems to be what is
needed to achieve ABI neutrality. In this case, it's not a completely
new IR, but a set of extensions to the existing IR which can be
eliminated in a target-specific way.

...

I didn't mean for this thread to become an exposition of this idea. I
only recently started considering this idea. It is only half-baked.

- David


On Mon, Sep 19, 2011 at 5:54 PM, Devang Patel <dpatel at apple.com> wrote:
>
> On Sep 19, 2011, at 5:45 PM, David Meyer wrote:
>
>>>
>>> With this approach, you'd still be exposing all of the new type
>>> diversity to all LLVM IR consumers.
>>
>> Not necessarily. Imagine having two flavors of IR: high-level (with
>> extended types), and low-level (without extended types, identical to
>> bitcode today).
>>
>> Any IR consumer can choose which form it wants to handle. Given a
>> high-level module, you can apply the ABI lowering transformation to
>> get rid of the extended types, and get the low-level representation
>> instead.
>>
>> Frontends would only need to generate high-level bitcode, freeing them
>> of target-specific considerations.
>>
>> And the backends would only need to worry about processing low-level
>> bitcode. In particular, CodeGen/Analysis/Transforms wouldn't need to
>> know anything about the new type system, since the new types would be
>> eliminated before the bitcode reached them.
>
> Then, who is the intended consumer of this higher-level bitcode ? In my view, CodeGen/Analysis/Transforms pretty much sums up all LLVM IR consumers as Dan mentioned earlier.
>
> -
> Devang
>