Re: RFC: allowing fwprop to propagate subregs

[Richard Sandiford <richard dot sandiford at linaro dot org>]

"H.J. Lu" <hjl.tools@gmail.com> writes:
> On Wed, Sep 14, 2011 at 8:24 AM, Richard Sandiford
> <rdsandiford@googlemail.com> wrote:
>> At the moment, fwprop will propagate constants and registers
>> even if no further rtl simplifications are possible:
>>
>> Âif (REG_P (new_rtx) || CONSTANT_P (new_rtx))
>> Â Âflags |= PR_CAN_APPEAR;
>>
>> What do you think about extending this to subregs? ÂThe reason for
>> asking is that on NEON, vector loads like vld4 are represented as a load
>> of a single monolithic register followed by subreg extractions of each
>> vector:
>>
>> Â(set (reg:OI FULL) (...))
>> Â(set (reg:V2SI V0) (subreg:V2SI (reg:OI FULL) 0))
>> Â(set (reg:V2SI V1) (subreg:V2SI (reg:OI FULL) 16))
>> Â(set (reg:V2SI V2) (subreg:V2SI (reg:OI FULL) 32))
>> Â(set (reg:V2SI V3) (subreg:V2SI (reg:OI FULL) 48))
>>
>> Nothing ever propagates these subregs, so the separate moves
>> survive until IRA. ÂThis has three problems:
>>
>> Â- We generally want the registers allocated to V0...V3 to be the same
>> Â Âas FULL, so that the four subreg moves become nops. ÂAnd this often
>> Â Âhappens in simple examples. ÂBut if register pressure is relatively
>> Â Âhigh, these moves can sometimes cause IRA to spill in cases where
>> Â Âit doesn't if the subregs are used instead of each Vi.
>>
>> Â- Perhaps related, register pressure becomes harder to estimate.
>>
>> Â- These moves can interfere with pre-reload scheduling.
>>
>> In combination with the MODES_TIEABLE_P patch that I posted here:
>>
>> Â Âhttp://gcc.gnu.org/ml/gcc-patches/2011-09/msg00626.html
>>
>> this patch significantly improves the code generated for several libav
>> loops. ÂUnfortunately, I don't have a setup that can do meaningful
>> x86_64 performance measurements, but a diff of the before and after
>> output for libav showed many cases where the patch removed moves.
>>
>> What do you think? ÂAlternatives include propagating in lower-subreg,
>> or maybe only in the second fwprop pass.
>>
>> Richard
>>
>>
>> gcc/
>> Â Â Â Â* fwprop.c (propagate_rtx): Also set PR_CAN_APPEAR for subregs.
>>
>> Index: gcc/fwprop.c
>> ===================================================================
>> --- gcc/fwprop.c    Â2011-08-26 09:58:28.829540497 +0100
>> +++ gcc/fwprop.c    Â2011-08-26 10:14:03.767707504 +0100
>> @@ -664,7 +664,7 @@ propagate_rtx (rtx x, enum machine_mode
>> Â Â return NULL_RTX;
>>
>> Â flags = 0;
>> - Âif (REG_P (new_rtx) || CONSTANT_P (new_rtx))
>> + Âif (REG_P (new_rtx) || CONSTANT_P (new_rtx) || GET_CODE (new_rtx) == SUBREG)
>> Â Â flags |= PR_CAN_APPEAR;
>> Â if (!for_each_rtx (&new_rtx, varying_mem_p, NULL))
>> Â Â flags |= PR_HANDLE_MEM;
>>
>
> A SUBREG may not be REG nor CONSTANT. Don't you need
> to check REG_P/CONSTANT_P on SUBREG?

Yeah, good point.  There should be a "&& REG_P (SUBREG_REG (new_rtx))"
in there.  Probably also worth checking for non-paradoxical subregs.

Richard