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

In this thread I'm trying to merge two email threads into one, because
both discuss the same problem that's troubling us and I would like to
reach a conclusion on what would be the best approach.

To minimize the size of this thread I only mention the subject of the
other two threads:

(1)    [LLVMdev] Integer promotion of return node operand
(initiated by Sachin)

(2)    [LLVMdev] trouble with 32-bit promotion of return value
(initiated by myself)

 

To summarize:

Evan has replied to thread (1) and suggested to add a calling convention
and check for it in visitRet

Dan replied to thread (2) and suggested to add a new field to the
TargetLowering class, and then let each target specify the minimum
integer type to promote return types to

 

Either way, I think we all agree that the root of the problem is the
FIXME in SelectionDAGLowering::visitRet()

 

But what is the preferred method?

 

Thanks

Ali

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20080514/32e4e5d1/attachment.html>

> Either way, I think we all agree that the root of the problem is the
> FIXME in SelectionDAGLowering::visitRet()
What I would like to know is if the promotion of return values to
integer is specified by the C language standard, or if it is specified
by the (target specific) ABI.

Ciao,

Duncan.

On May 14, 2008, at 10:43 AM, Alireza.Moshtaghi at microchip.com wrote:
> In this thread I’m trying to merge two email threads into one,  
> because both discuss the same problem that’s troubling us and I  
> would like to reach a conclusion on what would be the best approach.
> To minimize the size of this thread I only mention the subject of  
> the other two threads:
> (1)    [LLVMdev] Integer promotion of return node operand         
> (initiated by Sachin)
> (2)    [LLVMdev] trouble with 32-bit promotion of return value    
> (initiated by myself)
>
> To summarize:
> Evan has replied to thread (1) and suggested to add a calling  
> convention and check for it in visitRet
> Dan replied to thread (2) and suggested to add a new field to the  
> TargetLowering class, and then let each target specify the minimum  
> integer type to promote return types to
>
> Either way, I think we all agree that the root of the problem is the  
> FIXME in SelectionDAGLowering::visitRet()
>
> But what is the preferred method?
Both. :-)

If you are using a non-C ABI, then you may not need to do the  
promotion at all. However, if you do need to do the promotion, you  
need to know the type of "int". It's not entirely clear to me what
is
the best way to accomplish. To me, I don't think TargetLowering is the  
right place to add the hook. How about TargetData.h ? There is a  
getIntPtrType(), perhaps we need a getIntType()?

Evan
>
> Thanks
> Ali
> _______________________________________________
> 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/20080515/58d8b356/attachment.html>

>If you are using a non-C ABI, then you may not need to do the promotion
at all. However, if you do need to do the ....

Our port is for C language, however, on an 8-bit platform priorities
shift a little bit.

Really the natural size of int must be 8 bit, however, 8 bit is too
small for most calculations so we have to choose 16, but there is no
16-bit register available. And that is where the whole problem starts
because promoting the return of char to int becomes too expensive; so we
don't want to do it.

 

Being able to turn the promotion off is going to solve our problem, but
currently there is no hook for that in target specific classes. 

 

Ali.

 

________________________________

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
On Behalf Of Evan Cheng
Sent: Thursday, May 15, 2008 11:11 AM
To: LLVM Developers Mailing List
Subject: Re: [LLVMdev] Troubling promotion of return value to Integer
...

 

 

On May 14, 2008, at 10:43 AM, Alireza.Moshtaghi at microchip.com wrote:





In this thread I'm trying to merge two email threads into one, because
both discuss the same problem that's troubling us and I would like to
reach a conclusion on what would be the best approach.

To minimize the size of this thread I only mention the subject of the
other two threads:

(1)    [LLVMdev] Integer promotion of return node operand
(initiated by Sachin)

(2)    [LLVMdev] trouble with 32-bit promotion of return value
(initiated by myself)

 

To summarize:

Evan has replied to thread (1) and suggested to add a calling convention
and check for it in visitRet

Dan replied to thread (2) and suggested to add a new field to the
TargetLowering class, and then let each target specify the minimum
integer type to promote return types to

 

Either way, I think we all agree that the root of the problem is the
FIXME in SelectionDAGLowering::visitRet()

 

But what is the preferred method?

 

Both. :-)

 

If you are using a non-C ABI, then you may not need to do the promotion
at all. However, if you do need to do the promotion, you need to know
the type of "int". It's not entirely clear to me what is the best
way to
accomplish. To me, I don't think TargetLowering is the right place to
add the hook. How about TargetData.h ? There is a getIntPtrType(),
perhaps we need a getIntType()?

 

Evan





 

Thanks

Ali

_______________________________________________
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/20080515/e443bf31/attachment.html>

Hi Evan,
> If you are using a non-C ABI, then you may not need to do the  
> promotion at all. However, if you do need to do the promotion, you  
> need to know the type of "int".
how does this work for parameters.  Suppose I have an i1 parameter.
The AMD64 ABI says it is passed in one of %rsi, %rdx, %rcx, %r8 and
%r9 registers.  In the case of _Bool (i1) it says that the upper 63
bits will be zero.  How does this work?  I thought i1 would be legalized
to i8 (which is legal, right?).  Due to being marked zext, the upper
7 bits of the i8 will be zero.  But where does it get extended to
an i64 with upper 63 bits zero?

Thanks,

Duncan.

On May 14, 2008, at 10:43 AM, <Alireza.Moshtaghi at microchip.com>
<Alireza.Moshtaghi at microchip.com
 > wrote:
> In this thread I’m trying to merge two email threads into one,  
> because both discuss the same problem that’s troubling us and I  
> would like to reach a conclusion on what would be the best approach.
> To minimize the size of this thread I only mention the subject of  
> the other two threads:
> (1)    [LLVMdev] Integer promotion of return node operand         
> (initiated by Sachin)
> (2)    [LLVMdev] trouble with 32-bit promotion of return value    
> (initiated by myself)
>
> To summarize:
> Evan has replied to thread (1) and suggested to add a calling  
> convention and check for it in visitRet
> Dan replied to thread (2) and suggested to add a new field to the  
> TargetLowering class, and then let each target specify the minimum  
> integer type to promote return types to
>
> Either way, I think we all agree that the root of the problem is the  
> FIXME in SelectionDAGLowering::visitRet()
Hi Ali,

I think there are two sides to this issue.  The ultimate problem is  
that the code generator has a builtin assumption that sizeof(int) = 32  
bits.  IIRC, this comes into play in two places:

1. Arguments to calls are known to be sign/zero extended to int in  
certain cases.
2. The return value of functions is implicitly promoted.

Lets talk about #2 first, because it is the simplest case.  Here the  
front-end types the function as (f.e.) returning i8, and then has the  
code generator insert the extension to (for example) i32.  The  
attribute on the function tells the code generator whether to sign or  
zero extend it.

To me, the solution to this is to have the C front-end insert an  
explicit extension of the appropriate type to the right size.  This  
would mean that the code generator would now never insert the  
extension.  Since the C front-end knows the size of int, on your  
target, you could have it extend to 16 or 8 bits, as appropriate.   
This is also good, because the extension is exposed to the mid-level  
optimizer, allowing it to be eliminated more aggressively.

The bad thing about doing this is that, on the caller side, we lose  
information.  With the current approach, the caller knows that the  
value is (for example) 8 bits but sign or zero extended as  
appropriate.  This allows the caller side to do optimizations based on  
this fact.  If all return values were i32, we wouldn't know that the  
top 24 bits were sign/zero extended.  I think we can handle this by  
adding some new attributes, but this is marginally ugly.

What do you think?

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

On Fri, 2008-05-16 at 06:11 -0700, Chris Lattner wrote:
> To me, the solution to this is to have the C front-end insert an
> explicit extension of the appropriate type to the right size.
Opinion:

The front end should be responsible for introducing all necessary
promotions, sign extensions, or zero extensions. The absence of these
operations where required is a type error in the emitted IR, and should
be treated as such. The job of the back end is to reject ill-typed input
as malformed, not correct it. Therefore, the code generator should not
be inserting these promotions.

As a matter of implementation, an explicitly run decorating IR pass
might be a fine implementation that avoids invasive changes in current
front ends.
> If all return values were i32, we wouldn't know that the top 24 bits
> were sign/zero extended.  I think we can handle this by adding some
> new attributes, but this is marginally ugly.
The real issue here is that there is a divergence between the logical
type and the representation type, the back end needs to know both for
different purposes, and within the constraints of the current IR (absent
new annotations) information about one or the other is lost.

Is this a more general issue, or are annotations sufficient?


shap

Chris,

I did not quite understand the "The bad thing about ..." part of your
argument. I'm not sure which of the two scenarios are you comparing
(promoting in FrontEnd vs BackEnd) or (promotion to int vs i32)

 

Regardless, I agree with you and shap that promotions should take place
in the FrontEnd and this is my reason:

The standard allows calling a function without prototype and assumes
"int" return value; and I realize that this is the primary reason why
the return value is being promoted. This ties this promotion to int type
and not the size of any register in target, which in turn makes it a
language issue rather than code generation issue; hence FrontEnd must
take care of it.

 

Now for our port, things are different. In most (sane) ports, the target
provides an integer class for int... however, things are different in
our (insane) port. We only have an 8-bit data bus but we also want
16-bit int type. So this promotion will make char return values (which
are used heavily in many application in 8-bit environment) quite
inefficient. So we need a way to turn off this promotion all together
and deal with default function prototype in a different way (perhaps
issue a diagnostic ...)

 

Cheers

Ali

 

 
>The bad thing about doing this is that, on the caller side, we lose
information.  With the current approach, the caller knows that the value
is (for example) 8 >bits but sign or zero extended as appropriate.  This
allows the caller side to do optimizations based on this fact.  If all
return values were i32, we wouldn't >know that the top 24 bits were
sign/zero extended.  I think we can handle this by adding some new
attributes, but this is marginally ugly.
> 
>What do you think?
> 
>-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20080516/6df42317/attachment.html>