Re: post_inc mem in parallel rtx

[Jeff Law <law at redhat dot com>]

On 11/22/13 09:43, BELBACHIR Selim wrote:
> Hi,
>
> I encountered a bug in cselib.c:2360 using gnat7.1.2 (gcc4.7.3)
>
>          /* The register should have been invalidated.  */
>            gcc_assert (REG_VALUES (dreg)->elt == 0);                <<== assert(false)
>
>
> I investigated the dump and found that the crash occurred during 207r.dse2 pass.
>
> Here is what I saw in the previous dump (206r.pro_and_epilogue) :
>
> (insn 104 47 105 7 (parallel [
>              (set (reg:CC_NOOV 56 $CCI)
>                  (compare:CC_NOOV (minus:SI (reg/f:SI 22 $R6 [orig:133 D.3274 ] [133])
>                          (mem/f:SI (post_inc:SI (reg:SI 2 $R2 [orig:140 ivtmp.363 ] [140])) [0 MEM[base: D.4517_59, offset: 0B]+0 S4 A32]))
>                      (const_int 0 [0])))
>              (set (reg:SI 16 $R0 [153])
>                  (minus:SI (reg/f:SI 22 $R6 [orig:133 D.3274 ] [133])
>                      (mem/f:SI (post_inc:SI (reg:SI 2 $R2 [orig:140 ivtmp.363 ] [140])) [0 MEM[base: D.4517_59, offset: 0B]+0 S4 A32])))
>          ])
>
> Note the post_inc MEM on $R2 appearing twice
>
> This rtl match my pattern (predicate and contraint ok) below :
>
> (define_insn "subsi3_compare0"
>    [(set (reg:CC_NOOV CCI_REG)
>          (compare:CC_NOOV
>            (minus:SI
>              (match_operand:SI 1 "general_operand" "g")
>              (match_operand:SI 2 " general_operand " " g"))
>            (const_int 0)))
>     (set (match_operand:SI 0 "register_operand" "=r ")
>          (minus:SI
>            (match_dup 1)
>            (match_dup 2)))]
>
> But I think It may be an error to authorize post_inc MEM in this parallel rtx in operand 1 & 2.
> When I put a more restrictive constraint which forbid the use of post_inc, the crash in cselib.c disappear.
>
> Question : What does GCC understand when the md describes a pattern allowing the same post_inc MEM in 2 slot of a parallel rtx ?
> Is it forbidden ? the MEM address is supposed to be incremented twice ?
I think the semantics are defined by the PARALLEL.  Namely that the uses 
are evaluated, then side effects are performed.  So both sets use the 
value before incrementing.

The only question is what is the resulting value, and given the 
fundamental nature of PARALLEL, I think a single visible side effect is 
the most obvious answer.

Now having said that, there's a distinct possibility various passes 
don't handle this properly.

jeff