On 5/15/19 8:08 PM, [email protected] wrote:
> From: Kugan Vivekanandarajah <[email protected]>
>
> This patch changes cse_insn to process parallel rtx one by one such that
> any destination rtx in cse list is invalidated before processing the
> next.
>
> gcc/ChangeLog:
>
> 2019-05-16 Kugan Vivekanandarajah <[email protected]>
>
> PR target/88834
> * cse.c (safe_hash): Handle VEC_DUPLICATE.
> (exp_equiv_p): Likewise.
> (hash_rtx_cb): Change to accept const_rtx.
> (struct set): Add field to record if uses of dest is invalidated.
> (cse_insn): For parallel rtx, invalidate register set by first rtx
> before processing the next.
>
> gcc/testsuite/ChangeLog:
>
> 2019-05-16 Kugan Vivekanandarajah <[email protected]>
>
> PR target/88834
> * gcc.target/aarch64/pr88834.c: New test.
I haven't dug into the code, so if my concerns are off base, just say so.
> (insn 19 18 20 3 (parallel [
> (set (reg:VNx4BI 93 [ next_mask_18 ])
> (unspec:VNx4BI [
> (const_int 0 [0])
> (reg:DI 95 [ _33 ])
> ] UNSPEC_WHILE_LO))
> (set (reg:CC 66 cc)
> (compare:CC (unspec:SI [
> (vec_duplicate:VNx4BI (const_int 1 [0x1]))
> (reg:VNx4BI 93 [ next_mask_18 ])
> ] UNSPEC_PTEST_PTRUE)
> (const_int 0 [0])))
> ]) 4244 {while_ultdivnx4bi}
RTL semantics in case of a PARALLEL are that all the inputs are
consumed, then all outputs are generated. So for the example insn reg93
is read in the second set before it's set in the output of the first set.
So the ordering you're using for processing/invaliding seems unexpected.
jeff
