[cfe-dev] Passing StructType arguments directly

Renato Golin rengolin at systemcall.org
Thu Sep 22 04:17:01 PDT 2011


On 22 September 2011 09:51, David Chisnall <csdavec at swan.ac.uk> wrote:
> They are not contradictory.  He wants target-independent IR from the front end.  Then he wants a target-specific lowering pass to transform it into IR for the target ABI.  This isn't an unusual requirement, which is why it was a design goal for TENDRA and the SGI compiler suite.


Hi David,

I agree with you that the statements are not contradictory, but one
has to weight the value of wanting a target-independent IR.

First, you have language independent and target independent IR, and
they are neither mutually exclusive nor linearly independent.
Bit-fields, unions, C++ ABI, OpenCL special semantic can really stress
how you produce IR that is both correct and compatible with IR
generated from other languages. And that can be represented in
multiple ways for different targets. In some cases, it's not even
meaningful to merge them together.

My original assumption, and what has been done to a certain level by
Jun-Gu Kang (http://llvm.org/devmtg/2011-09-16/) was to represent IR
in different levels, both in the front-end level (language semantics
and ABI) and back-end level (target-dependent transformations). But
that has numerous costs: you have to create multiple sub-languages in
IR, or extend the current IR to express every semantic variation (and
make sure each set of extensions is still consistent), which is
non-trivial and lead to a bloated IR definition.

That said, I agree that there has to be some kind of interoperability
between different sources. The Native Client had, I believe, could
benefit from it at an IR level. Platforms like ARM could benefit to
generate IR once and have that used to multiple architectures (like
library code or shared modules in a JIT environment), without having
to specify PCS, VFP, etc (but relying on the back-end and possibly
re-compiling at run-time).

But the biggest impediment, AFAICS, is to make sure each of those
changes won't break every other front-/back-end.



-- 
cheers,
--renato

http://systemcall.org/




More information about the cfe-dev mailing list