[LLVMdev] Troubling promotion of return value to Integer ...

[Jonathan S. Shapiro]

On Fri, 2008-05-16 at 06:11 -0700, Chris Lattner wrote:

> To me, the solution to this is to have the C front-end insert an
> explicit extension of the appropriate type to the right size.

Opinion:

The front end should be responsible for introducing all necessary
promotions, sign extensions, or zero extensions. The absence of these
operations where required is a type error in the emitted IR, and should
be treated as such. The job of the back end is to reject ill-typed input
as malformed, not correct it. Therefore, the code generator should not
be inserting these promotions.

As a matter of implementation, an explicitly run decorating IR pass
might be a fine implementation that avoids invasive changes in current
front ends.

> If all return values were i32, we wouldn't know that the top 24 bits
> were sign/zero extended.  I think we can handle this by adding some
> new attributes, but this is marginally ugly.

The real issue here is that there is a divergence between the logical
type and the representation type, the back end needs to know both for
different purposes, and within the constraints of the current IR (absent
new annotations) information about one or the other is lost.

Is this a more general issue, or are annotations sufficient?


shap