[LLVMdev] Troubling promotion of return value to Integer ...

[Alireza.Moshtaghi at microchip.com]

Chris,

Regardless of the optimization problem that we had discussions before, I
think we all agreed that promotion of return value should take place in
the front-end...

Now I have a suggestion:

In the message below you laid out the suggested IR for "char foo()" when
its return value is promoted to i32 in front-end.

You have applied the promotion both at the definition of function and
its return statement. This leaves no way for backend to differentiate
"char foo()" from "int foo()". 

Currently in llvm, promotion affects only the return value but function
definition is not promoted, and that is helpful because in LowerRET() I
can look at the return size from the function definition and
differentiate a promoted return statement from a non-promoted one and
accordingly do the desired lowering for my port.

I would like to suggest that when the promotion is done in the
Front-end, we do the same and only promote the return value and the
function definition does not get promoted:

So for:

 

char foo() {

  char c = ...

  return c;

} 

 

We will have:

 

define i8 @foo() {

   ...

   %tmp = sext i8 ... to i32

   ret i32 %tmp

} 

 

And for 

 

int foo() {

  char c = ...

  return c;

} 

 

We will have:

 

define i32 @foo() {

   ...

   %tmp = sext i8 ... to i32

   ret i32 %tmp

} 

 

Is this acceptable?

 

Cheers

Ali

________________________________

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

 

 

Assume we make the change I suggested.  This means that this C function
(on x86-32):

 

char foo() { 

  char c = ...

  return c;

}

 

would compile to something like:

 

define i32 @foo() {

   ...

   %tmp = sext i8 ... to i32

   ret i32 %tmp

} 

 

Since "char" is sign extend to 32 bits on this target, there would be an
explicit sign extension.  This is goodness.  The problem is that now you
have a caller:

 

 ...

char bar() {

  char x = foo()

  return char;

}

 

This would get compiled (by the front-end to something like this:

 

define i32 @bar() {

  ; call

  %tmp = call i32 @foo()

  %x = trunc i32 %tmp to i8

 

  ; return

  %tmp2 = sext i8 to i32

  ret i32 %tmp2

}

 

The problem with this is that we now have a trunc+sext instruction that
cannot be eliminated.  The loss here is that while foo returns an i32
value, we lost the fact that the top 25 bits all have the same value
(i.e. that it is a sign extended 8-bit value).  Because of this, we
can't eliminate the trunc+sext pair in bar, pessimizing code (and in a
very common case!).  I am just saying that we should have some attribute
(or something) on foo that indicates its result is actually sign
extended, allowing the optimizer to zap the trunc+sext in bar.

 





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.

 

Right, I agree this should be fixed.





 

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 ...)

 

Sure.  The other good thing about exposing this extensions in the IR is
that interprocedural optimizations can eliminate them.  This gives the
optimizer the ability to actually eliminate the extensions and
truncations completely.

 

-Chris

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