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

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>

Correction:

The analysis I made regarding the callers knowledge of sign/zero
extension of return value is flawed. So I take it back. 

Never the less, I don't see how adding attributes would resolve this
problem either. 

 

Ali

 

________________________________

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
On Behalf Of Alireza.Moshtaghi at microchip.com
Sent: Sunday, May 18, 2008 6:33 PM
To: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] Troubling promotion of return value to Integer
...

 

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/20080519/39d4e072/attachment.html>

On Mon, 19 May 2008 Alireza.Moshtaghi at microchip.com
wrote:
> Correction:
>
> The analysis I made regarding the callers knowledge of sign/zero
> extension of return value is flawed. So I take it back.
>
> Never the less, I don't see how adding attributes would resolve this
> problem either.
Ok, I'm not sure what issue you mean.  Can you restate?

-Chris
> ________________________________
>
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu]
> On Behalf Of Alireza.Moshtaghi at microchip.com
> Sent: Sunday, May 18, 2008 6:33 PM
> To: llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] Troubling promotion of return value to Integer
> ...
>
>
>
> 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.
>
>
-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/