Hello Jakub,
On 17 Feb 17:46, Jakub Jelinek wrote:
> Hi!
>
> As I wrote in the PR, fwprop is able to forward CONST0_RTX back into
> instructions even if CSE optimized them, but the problem in that case is
> that for vector_move_operand "0C" operands if they appear inside of
> (vec_select ... (parallel [(const_int 0) ... ])) the result is also
> simplified, so one gets instead another CONST0_RTX (in the mode of
> the VEC_SELECT). Because the patterns expect a vec_select and "C" operand
> inside of it, it is therefore not matched, it maybe attached as REG_EQUAL
> note. I went through other vector_move_operand "0C" and "0C,0" operands
> and I don't think they suffer from similar problem, if fwprop or cprop etc.
> attempts to propagate a constant into them, it shouldn't be possible it will
> be simplified into something different.
>
> Anyway, the fix IMHO is to just duplicate the affected 8 define_insns
> with the simplification applied. IMHO once we know it is {z}, it is worth
> to keep it as {z}, there is no benefit to allow the RA to use "0"
> operand instead.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, on both fixes
> the testcases that started failing with r233133, ok for trunk?
Patch is ok for trunk. Thanks a lot for fixing this!
--
Regards, K
