[Patch/rtl-expand] Take tree range info into account to improve LSHIFT_EXP expanding
Jeff Law
law@redhat.com
Fri Apr 24 02:23:00 GMT 2015
On 04/16/2015 05:04 AM, Jiong Wang wrote:
>
> This is a rework of
>
> https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01998.html
>
> After second thinking, I feel it's better to fix this in earlier stage
> during RTL expand which is more generic, and we also avoid making the
> already complex combine pass complexer.
>
> Currently gcc expand wide mode left shift to some generic complex
> instruction sequences, while if we have known the high part of wide mode
> all comes from sign extension, the expand logic could be simplifed.
>
> Given the following example,
>
> T A = (T) B << const_imm_shift
>
> We know the high part of A are all comes from sign extension, if
>
> * T is the next wider type of word_mode.
>
> For example, for aarch64, if type T is 128int (TImode), and B is with
> type SImode or DImode, then tree analyzer know that the high part of
> TImode result all comes from sign extension, and kept them in range info.
>
> |< T >|
> | high | low |
> |<- sizel ->|
>
> For above example, we could simplify the expand logic into
> 1. low = low << const_imm_shift;
> 2. high = low >> (sizel - const_imm_shift) */
>
> We can utilize the arithmetic right shift to do the sign
> extension. Those reduntant instructions will be optimized out later.
>
> For actual .s improvement,
>
> AArch64
> =======
>
> __int128_t
> foo (int data)
> {
> return (__int128_t) data << 50;
> }
>
> old:
> sxtw x2, w0
> asr x1, x2, 63
> lsl x0, x2, 50
> lsl x1, x1, 50
> orr x1, x1, x2, lsr 14
>
> new:
> sxtw x1, w0
> lsl x0, x1, 50
> asr x1, x1, 14
>
>
> ARM (.fpu softvfp)
> ===========
>
> long long
> shift (int data)
> {
> return (long long) data << 20;
> }
>
> old:
> stmfd sp!, {r4, r5}
> mov r5, r0, asr #31
> mov r3, r0
> mov r0, r0, asl #20
> mov r1, r5, asl #20
> orr r1, r1, r3, lsr #12
> ldmfd sp!, {r4, r5}
> bx lr
>
> new:
> mov r1, r0
> mov r0, r0, asl #20
> mov r1, r1, asr #12
> bx lr
>
> Test
> ====
>
> x86 bootstrap OK, regression test OK.
> AArch64 bootstrap OK, regression test on board OK.
>
> Regards,
> Jiong
>
> 2015-04-116 Jiong.Wang <jiong.wang@arm.com>
>
> gcc/
> * expr.c (expand_expr_real_2): Take tree range info into account when
> expanding LSHIFT_EXPR.
>
> gcc/testsuite
> * gcc.dg/wide_shift_64_1.c: New testcase.
> * gcc.dg/wide_shift_128_1.c: Ditto.
> * gcc.target/aarch64/ashlti3_1.c: Ditto.
> * gcc.target/arm/ashldisi_1.c: Ditto.
Funny, I find myself wanting this transformation in both places :-)
Expansion time so that we generate efficient code from the start and
combine to catch those cases which are too complex to see at expansion,
but due to other optimizations become visible in the combiner.
Sadly, it's been fairly common practice for targets to define
double-word shift patterns which catch a variety of special cases.
Ports will have to choose between using those patterns and exploiting
your work. I'd be tempted to generate a double-word shift by the given
constant and check its cost vs the single word shifts.
What happens if there's an overlap between t_low and low? Won't the
lshift clobber low and thus we get the right value for the rshift in
that case?
Note that expand_variable_shift may not honor your request for putting
the result in the TARGET target parameter you pass in.
Thus:
temp = expand_variable_shift (...)
temp = expand_variable_shift (...)
Can't be right. You probably need something like
temp = expand_variable_shift (...)
if (temp != t_low)
emit_move_insn (t_low, temp);
temp = expand_variable_shift (...)
if (temp != t_high)
emit_move_insn (t_high, temp);
return target;
So I generally like where you're going with this, but I have concerns
about its correctness, particularly in cases where there's an overlap or
when expand_variable_shift returns its value in something other than the
passed in target.
Jeff
More information about the Gcc-patches
mailing list