On Sat, Nov 7, 2020 at 12:09 PM Luc Van Oostenryck
<luc.vanoostenryck@xxxxxxxxx> wrote:
>
> Yes, once the SEL(SEL(x,C,0),C,0) is handled this all simplify to
> .L0:
> <entry-point>
> select.32 %r6 <- %arg1, $0xffffffff, $0
> cbr %arg1, .L6, .L4
> .L4:
> call spin_lock
> # call %r4 <- errno, %r1
> call spin_unlock
> br .L6
> .L6:
> ret.32 %r6
>
> but to me, this seems a very very special case, so not much interesting.
Oh, ok, so just fixing the missing simplification does actually fix it.
And I'm not sure how special-case this is. Because I think we _do_
actually generally doing the if-conversion "later", even if it's not a
separate phase, simply because we end up doing it at the "OP_PHI"
instruction, which should always end up linearizing after the branches
that should have been simplified.
So sometimes the ordering can be simply due to the order we see and
react to instructions.
> > Have we done that if_convert_phi() simplification too early?
>
> Absolutely. I've often observed that it inhibits other simplifications
> related to conditionals. And, even when it doesn't, I think that many
> select simplifications would already be handled at SETxx + CBR level
> (like your previous SEL(x,x,0)).
Yeah, the problem with doing multiple passes, though, is that you
inevitably end up wanting to repeat them, because a later phase will
cause you to be able to then do earlier phases again.
So there's never any one "correct" order to do things in, and I think
you always end up with those "oh, unlucky, we did that one
simplification that then made another one harder" regardless of what
you do.
Although we do already have "passes" with some things clearly done
before others (like turning symbols into pseudos before doing any
other optimizations). But those tend to be very clear "convert the
tree into the proper format for the next stage", not this kind of "one
optimization then causes/hinders others".
Linus
