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

[Jonathan S. Shapiro]

On Fri, 2008-05-16 at 11:42 -0700, Chris Lattner wrote:
> This would get compiled (by the front-end to something like this:
> 
> 
> define i32 @bar() {
>   ; call
>   %tmp = call i32 @foo()
>   %x = trunc i32 %tmp to i8
> 
> 
>   ; return
>   %tmp2 = sext i8 to i32
>   ret i32 %tmp2
> }
> 
> 
> The problem with this is that we now have a trunc+sext instruction
> that cannot be eliminated...

Chris:

In an attempt to avoid adding distraction, I withheld the following
thought earlier. It may be equivalent to your annotation idea, but I
want to throw it out in case it provokes something useful.

Extension and promotion is a peculiar case. If an

   %x = sext i8 %y to i32

has already been performed, then there is no harm (in the sense that no
value is changed) by executing it redundantly on the low field of the
result register, as in:

   %z = sext i8 %x to i32

I'm giving an input %x that is known to be an i32 here intentionally.

This prompts me to the following thought, which may not be helpful.
Perhaps we might introduce something like the following two
pseudo-instructions in the IR:

   resext   sign extend on a quantity that the front end asserts has
            already been sign extended.

   rezext   zero extend on a quantity that the front end asserts has
            already been zero extended.

These instructions serve to advise the caller-side optimizer that the
required extend has been done, which tells us what we need to know for
optimizations. If they inadvertently make it to the back end, they
peephole away as a NO-OP.

Since we are already trusting the front end to introduce the correct
extension in the callee, I don't see any harm in trusting it to advise
us that it did so at the caller return site. The outcome is certainly no
worse than a front end that simply generates IR that is wrong, and
omission of the advisory instruction merely results in loss of an
optimization opportunity rather than any error of computational
semantics.

Like I say, not sure if this is helpful.


shap