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.
