[PING^2][PATCH][2 of 2] RTL expansion for zero sign extension elimination with VRP

Richard Biener rguenther@suse.de
Wed Jan 8 10:40:00 GMT 2014


On Wed, 8 Jan 2014, Kugan wrote:

> 
> On 07/01/14 23:23, Richard Biener wrote:
> > On Tue, 7 Jan 2014, Kugan wrote:
> 
> [snip]
> 
> 
> > Note that VIEW_CONVERT_EXPR is wrong here.  I think you are
> > handling this wrong still.  From a quick look you want to avoid
> > the actual promotion for
> > 
> >   reg_1 = ....
> > 
> > when reg_1 is promoted and thus the target is (subreg:XX N).
> > The RHS has been expanded in XXmode.  Dependent on the value-range
> > of reg_1 you want to set N to a paradoxical subreg of the expanded
> > result.  You can always do that if the reg is zero-extended
> > and else if the MSB is not set for any of the values of reg_1.
> 
> Thanks Richard for the explanation. I just want to double confirm I
> understand you correctly before I attempt to fix it. So let me try this
> for the following example,
> 
> for a gimple stmt of the following from:
> unsigned short _5;
> short int _6;
> _6 = (short int)_5;
> 
> ;; _6 = (short int) _5;
> target = (subreg/s/u:HI (reg:SI 110 [ D.4144 ]) 0)
> temp = (subreg:HI (reg:SI 118) 0)
> 
> So, I must generate the following if it satisfies the other conditions.
> (set (reg:SI 110 [ D.4144 ]) (subreg:SI temp ))
> 
> Is my understanding correct?

I'm no RTL expert in this particular area but yes, I think so.  Not
sure what paradoxical subregs are valid, so somebody else should
comment here.  You could even generate

  (set (reg:SI 110) (reg:SI 118))

iff temp is a SUBREG of a promoted var, as you require that for the
destination as well.

> 
> > I don't see how is_assigned_exp_fit_type reflects this in any way.
> >
> 
> 
> What I tried doing with the patch is:
> 
> (insn 13 12 0 (set (reg:SI 110 [ D.4144 ])
>         (zero_extend:SI (subreg:HI (reg:SI 118) 0))) c5.c:8 -1
>      (nil))
> 
> If the values in register (reg:SI 118) fits HI mode (without
> overflowing), I assume that it is not necessary to just drop the higher
> bits and zero_extend as done above and generate the following instead.
> 
> (insn 13 12 0 (set (reg:SI 110 [ D.4144 ])
>         (((reg:SI 118) 0))) c5.c:8 -1
>      (nil))
> 
> is_assigned_exp_fit_type just checks if the range fits (in the above
> case, the value in eg:SI 118 fits HI mode) and the checks before
> emit_move_insn (SUBREG_REG (target), SUBREG_REG (temp)); checks the
> modes match.
> 
> Is this wrong  or am I missing the whole point?

is_assigned_exp_fit_type is weird - it looks at the value-range of _5,
but as you want to elide the extension from _6 to SImode you want
to look at the value-range from _5.  So, breaking it down and applying
the promotion to GIMPLE it would look like

   unsigned short _5;
   short int _6;
   _6 = (short int)_5;
   _6_7 = (int) _6;

where you want to remove the last line representing the
assignment to (subreg:HI (reg:SI 110)).  Whether you can
do that depends on the value-range of _6, not on the
value-range of _5.  It's also completely independent
on the operation performed on the RHS.

Well.  As far as I understand at least.

Richard.



More information about the Gcc-patches mailing list