llvm dev - May 2008 - [LLVMdev] Troubling promotion of return value to Integer ...

To me, this "optimization" problem doesn't seem to be a
consequence of
doing the promotion differently than what is currently being done in
llvm. 

Anyways, I don't agree that the information is completely lost.
Shouldn't an llvm pass be able to figure out if the truncated value is
coming from a function call, and since it is aware of calling
convention, it should be able to deduce that tmp2 can really take its
value from function call?

 

So the pass will modify 

 

define i32 @bar() {

  ; call

  %tmp = call i32 @foo()

  %x = trunc i32 %tmp to i8

 

  ; return

  %tmp2 = sext i8 to i32

  ret i32 %tmp2

}

 

To

 

define i32 @bar() {

  ; call

  %tmp = call i32 @foo()

  %tmp2 = %tmp

  %x = trunc i32 %tmp to i8

 

  ; return

  ret i32 %tmp2

}

 

Meanwhile, the FrontEnd is consistent with the calling convention and
produce the correct IR with necessary promotions.

 

Ali

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20080516/0c14573c/attachment.html>

On May 16, 2008, at 4:07 PM, <Alireza.Moshtaghi at microchip.com> wrote:
> To me, this “optimization” problem doesn’t seem to be a consequence  
> of doing the promotion differently than what is currently being done  
> in llvm.
> Anyways, I don’t agree that the information is completely lost.  
> Shouldn’t an llvm pass be able to figure out if the truncated value  
> is coming from a function call, and since it is aware of calling  
> convention, it should be able to deduce that tmp2 can really take  
> its value from function call?
No, because the callee and caller may be in different translation units.

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20080516/847ac366/attachment.html>

But they both follow the same calling convention. There are two
possibilities in the caller:

1) Call node returns sizeof(int) or larger: in this case there is no
truncation.

2) Call node returns smaller than sizeof(int): in this case callee
always has to return an int so it has to consistently either sign extend
or zero extend because int is either signed or unsigned consistently for
that port. Assuming that caller and callee follow the same calling
convention, caller always knows (hence the llvm pass knows) that, if the
return value of the called function is being truncated, it is because of
return value promotion. It also knows the calling convention, so it
knows whether it is sign or zero extended. This is regardless of
translation unit where the callee is in.

 
>No, because the callee and caller may be in different translation
units.

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20080518/010a51ba/attachment.html>