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

[Chris Lattner]

On May 16, 2008, at 12:19 PM, Jonathan S. Shapiro wrote:
> 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.

No problem, ideas are welcome.

> 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.

Ok, so these are basically "copies with assertions".  There are a  
couple of similar proposals for things like this (for example, with  
pointers you might want to make some assertion w.r.t. aliasing).

The downside of this sort of approach (vs attributes) is that it  
increases the size of the every caller of the function.  The advantage  
is that it is more explicit, potentially more general, and doesn't  
require new attributes for each size.  OTOH, some of these advantages  
go away if this gets extended for other properties: we end up having a  
copy with attributes on it :)

> 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.

Right.  If it's part of the ABI, it is fair (and important!) for the  
optimizer to be able to use this.

> 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.

Yep.

-Chris