thr3ads.net - llvm dev - [LLVMdev] promotion of return value. [Mar 2009]

If this information is useful, please help other people find it:
Share via:

Alireza.Moshtaghi at microchip.com

2009-Mar-04 18:41 UTC

[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

Chris Lattner

2009-Mar-09 21:38 UTC

head link

[LLVMdev] promotion of return value.

On Mar 4, 2009, at 10:41 AM, Alireza.Moshtaghi at microchip.com wrote:
> 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...
Great!  I think that this is still the best plan, thanks for tackling  
it!

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

Alireza.Moshtaghi at microchip.com

2009-Mar-12 17:38 UTC

head link

[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 --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 6877 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090312/0ed3616f/attachment.bin>

Rafael Espindola

2009-Mar-12 17:49 UTC

head link

[LLVMdev] promotion of return value.

>> 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
You might want to look at bug http://llvm.org/bugs/show_bug.cgi?id=3779.

If I understand what you are proposing, it is exactly the opposite of
what gcc does, which would be annoying for someone trying to link gcc
and llvm compiled code.

Cheers,
-- 
Rafael Avila de Espindola

Google | Gordon House | Barrow Street | Dublin 4 | Ireland
Registered in Dublin, Ireland | Registration Number: 368047

Duncan Sands

2009-Mar-12 18:15 UTC

head link

[LLVMdev] promotion of return value.

On Thursday 12 March 2009 18:38:33 Alireza.Moshtaghi at microchip.com
wrote:> 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?
Since the LLVM IR supports arbitrary precision integers,
shouldn't there be zero_ext_from_i17 as well?  At least
zero_ext_from_i1?

Ciao,

Duncan.

PS: What is the problem this is trying to solve?

Rafael Espindola

2009-Mar-12 18:25 UTC

head link

[LLVMdev] promotion of return value.

>> 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)
>
I am a bit lost, but if we are going to do what gcc does (only extent
in the caller) I don't thin we need this. We can compile

char foo() {
   char c = ...
   return c;
}

into

define i8 @foo() {
     ...
   %tmp = ....
     ret i8 %tmp
}

and if a caller wants a 32 bit value it can extend it according to the
c/c++ prototype of the function.

In theory I think we could also do this for passing arguments to
functions, but I am not sure how this would
interact with existing code compiled with gcc.

Cheers,
-- 
Rafael Avila de Espindola

Google | Gordon House | Barrow Street | Dublin 4 | Ireland
Registered in Dublin, Ireland | Registration Number: 368047

Andrew Haley

2009-Mar-12 18:31 UTC

head link

[LLVMdev] promotion of return value.

Rafael Espindola wrote:>>> 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
> 
> You might want to look at bug http://llvm.org/bugs/show_bug.cgi?id=3779.
> 
> If I understand what you are proposing, it is exactly the opposite of
> what gcc does, which would be annoying for someone trying to link gcc
> and llvm compiled code.
That's right.  In gcc we used to do this in the front-ends but we
stopped.  This required quite a lot of discussion with the Linux ABI
standardization people.

Andrew.

Alireza.Moshtaghi at microchip.com

2009-Mar-31 18:46 UTC

head link

[LLVMdev] promotion of return value.

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>

Possibly Parallel Threads

Search for more possibly parallel threads

llvm dev - Mar 2009 - [LLVMdev] promotion of return value.

[LLVMdev] promotion of return value.

[LLVMdev] promotion of return value.

[LLVMdev] promotion of return value.

[LLVMdev] promotion of return value.

[LLVMdev] promotion of return value.

[LLVMdev] promotion of return value.

[LLVMdev] promotion of return value.

[LLVMdev] promotion of return value.

Possibly Parallel Threads