[LLVMdev] promotion of return value.

[Alireza.Moshtaghi at microchip.com]

Any thoughts on this? 

I would like to get it right before jumping into the nuts and bolts of
it....

 

Thanks

 

________________________________

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
On Behalf Of Alireza.Moshtaghi at microchip.com
Sent: Thursday, March 12, 2009 10:39 AM
To: llvmdev at cs.uiuc.edu
Subject: RE: [LLVMdev] promotion of return value.

 

Previously we talked about adding new attributes to function to identify
the promotion class. 

>   sign_ext_from_i8, sign_ext_from_i16
>   zero_ext_from_i8, zero_ext_from_i16

Aren't these attributes more applicable to return value? of course then
the question would be if they are also applicable to parameters too?
(because we use same attributes for parameters and return value)? or
should we disallow then on parameters?

 

Thoughts?

 

A.

 

________________________________

From: llvmdev-bounces at cs.uiuc.edu on behalf of
Alireza.Moshtaghi at microchip.com
Sent: Wed 3/4/2009 11:41 AM
To: llvmdev at cs.uiuc.edu
Subject: [LLVMdev] promotion of return value.

Below I have pasted the latest design that we discussed...
Now we would like to pick it up and do the implementation.
1) Is there any last change that we would like to add?
2) Has anyone been working on it? I haven't seen any thing new in the
code so I assume the answer is no...

Thanks

Alireza Moshtaghi
Senior Software Engineer
Development Systems, Microchip Technology

Subject:
Troubling promotion of return value to Integer ...
On May 29, 2008, at 10:30 AM, <Alireza.Moshtaghi at ...>
<Alireza.Moshtaghi at ...
 > wrote:

> Let me summarize what we discussed so far:
>
> 1) The return value promotion will be removed from llvm backend and
>   implemented in both front-ends (clang and llvm-gcc)
>
> 2) The promotions are only applied to the return value in the body
>   of the function.
>   Return value of function definition and declaration will not be
> promoted
>
>   Example for a Target with 32-bit int type:
>
>   char foo() {
>     char c = ...
>     return c;
>   }
>
>   Is translated to:
>
>   define i8 @foo() {
>      ...
>      %tmp = sext i8 ... to i32
>      ret i32 %tmp
>   }

Close.  The return value of declarations also has to be promoted.  foo

should be translated to:

   define i32 @foo() sign_ext_from_i8 {
      ...
      %tmp = sext i8 ... to i32
      ret i32 %tmp
   }

> 3) Return value promotion is the default behavior, however,
>   hooks will be provided to allow the Target to disable it
>   and emit diagnostics.

Sure, the front-end can do that.


> 4) There will be 4 new function attributes:
>   sign_ext_from_i8, sign_ext_from_i16
>   zero_ext_from_i8, zero_ext_from_i16
>   These attributes will be placed on the function CALL node by
> front-end
>   to inform the backend about such promotions and enable optimization
> of
>   return value. This should be sufficient for direct and indirect  
> call.
>   (syntax of these attributes to be defined)

They also go on the function definition, as above.

> Am I capturing everything?

Yep!  The place to start with this is introducing the new attributes.  
Given the new attributes, we can mock up .ll code that uses them and  
improve the optimizers to use them.  When everything there is correct,

we can move each front-end over to start using them.

-Chris


_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090331/9c1b306c/attachment.html>