On Wed, May 7, 2014 at 9:48 PM, Alan Modra <amo...@gmail.com> wrote:
> On powerpc64, to set a large loop count we have code like the
> following after split1:
>
> (insn 67 14 68 4 (set (reg:DI 160)
> (const_int 99942400 [0x5f50000])) /home/amodra/unaligned_load.c:14 -1
> (nil))
> (insn 68 67 42 4 (set (reg:DI 160)
> (ior:DI (reg:DI 160)
> (const_int 57600 [0xe100]))) /home/amodra/unaligned_load.c:14 -1
> (expr_list:REG_EQUAL (const_int 100000000 [0x5f5e100])
> (nil)))
>
> and then test for loop exit with:
>
> (jump_insn 65 31 45 5 (parallel [
> (set (pc)
> (if_then_else (ne (reg:DI 160)
> (const_int 1 [0x1]))
> (label_ref:DI 42)
> (pc)))
> (set (reg:DI 160)
> (plus:DI (reg:DI 160)
> (const_int -1 [0xffffffffffffffff])))
> (clobber (scratch:CC))
> (clobber (scratch:DI))
> ]) /home/amodra/unaligned_load.c:15 800 {*ctrdi_internal1}
> (int_list:REG_BR_PROB 9899 (nil))
> -> 42)
>
> The jump_insn of course is meant for use with bdnz, which implies a
> strong preference for reg 160 to live in the count register. Trouble
> is, the count register doesn't do arithmetic.
>
> So, use a new psuedo for intermediate results. On looking at this,
> I noticed the !TARGET_POWERPC64 code in rs6000_emit_set_long_const was
> broken, apparently expecting c1 and c2 to be the high and low 32 bits
> of the constant. That's no longer true, so I've fixed that as well.
> Bootstrapped and regression tested powerpc64-linux. OK for mainline
> and branches?
>
> PR target/61098
> * config/rs6000/rs6000.c (rs6000_emit_set_const): Remove unneeded
> params and return value. Simplify. Update comment.
> (rs6000_emit_set_long_const): Remove unneeded param and return
> value. Correct !TARGET_POWERPC64 handling of constants > 2G.
> If we can, use a new pseudo for intermediate calculations.
Alan,
The history is 32 bit HWI.
The ChangeLog does not mention the changes to rs6000.md nor rs6000-protos.h.
Please do not remove all of the comments from the two functions. The
comments should provide some documentation about the different
purposes of the two functions other than setting DEST to a CONST.
Why did you remove the test for NULL dest?
- if (dest == NULL)
- dest = gen_reg_rtx (mode);
That could occur, at least it used to occur.
I think that the way you rearranged the invocations of copy_rtx() in
rs6000_emit_set_long_const() is okay, but it would be good for someone
else to double check.
Thanks, David
