Generating RTL for function call sequences from GIMPLE

Generating RTL for function call sequences from GIMPLE

[Dave Korn]

    Evening all, just a quick question:

[ ref: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31513, "
[4.2/4.3 Regression] Miscompilation of Function Passing Bit Field Value to
Function" ]


  Should promotion of function arguments be explicitly represented in GIMPLE,
or should it be performed when generating the corresponding RTL?  It doesn't
appear to be taking place correctly for the <unnamed type>s used to represent
bitfields.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: Generating RTL for function call sequences from GIMPLE

[Richard Guenther]

On 4/9/07, Dave Korn <dave.korn@artimi.com> wrote:
>
>
>     Evening all, just a quick question:
>
> [ ref: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31513, "
> [4.2/4.3 Regression] Miscompilation of Function Passing Bit Field Value to
> Function" ]
>
>
>   Should promotion of function arguments be explicitly represented in GIMPLE,
> or should it be performed when generating the corresponding RTL?  It doesn't
> appear to be taking place correctly for the <unnamed type>s used to represent
> bitfields.

There is a conversion missing on the tree level.  See also PR31136.

Richard.

Re: Generating RTL for function call sequences from GIMPLE

[Richard Henderson]

On Mon, Apr 09, 2007 at 07:37:31PM +0100, Dave Korn wrote:
>   Should promotion of function arguments be explicitly represented in GIMPLE,
> or should it be performed when generating the corresponding RTL?

There are two things here:

 (1) Promotion of arguments to their devlared types, should
     be at the tree level.

 (2) Promotion of arguments to wider types, as specified by
     the abi, should be done when generating rtl.

The problem you're tracking is in (1).


r~

RE: Generating RTL for function call sequences from GIMPLE

[Dave Korn]

On 09 April 2007 22:12, Richard Henderson wrote:

> On Mon, Apr 09, 2007 at 07:37:31PM +0100, Dave Korn wrote:
>>   Should promotion of function arguments be explicitly represented in
>> GIMPLE, or should it be performed when generating the corresponding RTL?
> 
> There are two things here:
> 
>  (1) Promotion of arguments to their devlared types, should
>      be at the tree level.
> 
>  (2) Promotion of arguments to wider types, as specified by
>      the abi, should be done when generating rtl.
> 
> The problem you're tracking is in (1).
> 
> 
> r~


  Thanks, I think you're right on there.  The comments on PR31136 make it
fairly clear what's wrong; perhaps the best solution might be for
STRIP_SIGN_NOPS to mask out the high bits when it's discarding a size-reducing
NOP_EXPR?  Or perhaps fold_unary should simplify it before passing to
STRIP_SIGN_NOPS for minimal peturbation?

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: Generating RTL for function call sequences from GIMPLE

[Richard Henderson]

On Mon, Apr 09, 2007 at 11:55:14PM +0100, Dave Korn wrote:
>   Thanks, I think you're right on there.  The comments on PR31136 make it
> fairly clear what's wrong; perhaps the best solution might be for
> STRIP_SIGN_NOPS to mask out the high bits when it's discarding a size-reducing
> NOP_EXPR?  Or perhaps fold_unary should simplify it before passing to
> STRIP_SIGN_NOPS for minimal peturbation?

I think STRIP_NOPS, and STRIP_SIGN_NOPS, should not consider the 
mode to be the same when the precision doesn't match.  Indeed,
perhaps the mode is largely irrelevant, and it should only be
checking the precision....


r~