[LLVMdev] Troubling promotion of return value to Integer ...
Alireza.Moshtaghi at microchip.com
Alireza.Moshtaghi at microchip.com
Wed May 28 11:53:16 PDT 2008
Hi Chris, please read below:
> In many cases that is true, but for indirect calls (calls through a
> function pointer) it isn't.
>
> > All that is needed is to add some kind of sign attribute to the
> > definition of callee function which will be set by the front-end and
> > eventually saved in Function class.
>
> Sure. Adding an attribute is what we need to do. To handle the
> indirect call case, llvm puts attributes both on the function
> definitions and on the calls to those functions.
That makes a lot of sense
>
> Ok. We already have this, with the 'signext' attribute. This code:
>
> signed char g();
> signed char foo(){
> return g();
> }
>
> compiles into:
>
> define i8 @foo() signext nounwind {
> entry:
> %tmp1 = tail call i8 (...)* @g( ) signext nounwind
; <i8>
> [#uses=1]
> ret i8 %tmp1
> }
>
> declare i8 @g(...) signext
>
> Note that the 'signext' attribute is on all of foo, the call to G, and
> the G declaration itself.
>
OK, so you are giving a new meaning to signext attribute, where in
addition to parameters, now it would also be applicable to return value
of function.
(BTW I think it's a typo that you didn't promote the return value of foo
:)
I take it from your reply that, by using signext and implementing the
two helper methods, which I mentioned before, there would be no need to
add any new function attributes; right?
> > In both cases DAG.getReturnValueRegisterSizeInBits(...) returns 32
> > (on a
> > 32 bit architecture)
> >
> > The caveat here is when we don't have a prototype for callee in
which
> > case "int ()" is considered, hence known values are returned and no
> > optimization will take effect.
>
> The IR is already capturing this much information. If you want to go
> this route, it seems simple to parameterize (in target data?) the size
> of int, and have the code generator extend to that size, instead of
> forcing extension to i32.
Yes, I meant the same...
Regards
Ali
More information about the llvm-dev
mailing list