Graham Stott <graham.st...@btinternet.com> writes:
> Not sure if that working.
>
> I created some rtl using TRAP_IF to represent the TEQ and emiited via an
> expander
>
> The TRAP_IF rtl make ait all the way though the rtl optimizers which are
> run after expand
> even though it should be possible to determine is false.
>
>
> (insn 7 3 20 2 (set (reg:SI 2 $2 [201])
> (const_int 27 [0x1b])) bug.c:67 289 {*movsi_internal}
> (expr_list:REG_EQUIV (const_int 27 [0x1b])
> (nil)))
>
> (insn 20 7 21 2 (trap_if (eq:SI (reg:SI 2 $2 [201])
> (const_int 0 [0]))
> (const_int 7 [0x7])) bug.c:68 8 {*conditional_trapNsi_if_zero}
> (nil))
>
> I grepped the RTL code for any code handling TRAP_IF that looked like it
> might remove the TRAP_IF but
> only found some code is final_scan which only applied to CC0 backends.
>
> Is using a conditional trap (TRAP_IF) the right way to go?
For TEQ, yes, but perhaps we don't optimise TRAP_IF as much as branches.
Have you already tried the -mmdivide-breaks version too, which I think
ought to be a separate branch and trap at the rtl level? Does the branch
get optimised away? If so, perhaps we should extend that pass to handle
TRAP_IF too. (I'm being deliberately vague because I'm not sure without
trying it myself whether cse, combine, or something else is likely to
catch it first. But there is rtl code to track nonzeroness, so I'd be
surprised if every pass missed it.)
Thanks,
Richard
