On Fri, Nov 6, 2020 at 2:19 PM Luc Van Oostenryck
<luc.vanoostenryck@xxxxxxxxx> wrote:
>
> On Fri, Nov 06, 2020 at 11:44:00AM -0800, Linus Torvalds wrote:
> > On Fri, Nov 6, 2020 at 11:05 AM Song Liu <songliubraving@xxxxxx> wrote:
> > (a) the conditional following for the return value:
> >
> > select.32 %r4 <- %arg1, $0xffffffff, $0
> > select.32 %r6 <- %r4, $0xffffffff, $0
> >
> > Note how it doesn't trigger CSE, because it's not the same instruction
> > (%arg1 vs %r4), but sparse *could* see that a select that depends on a
> > previous select that has constant arguments can be simplified to be
> > conditional on the original select value instead, so it *could* be
> > CSE'd into one single thing.
> >
> > So the second "select" could be optimized away by realizing that it
> > really gets the same value as the first one. That *should* be trivial
> > to do in sparse by just having a simple pattern for select
> > simplification.
> >
> > And once that optimization is in place, the second optimization would be
>
> I think I may even have already this in an half-polished form.
Ugh. I tried to see what I can do, and it does simplify, but not the
way I expected.
The attached patch looks superficially sane (but probably is broken),
and results in one less "select" statement:
.L0:
<entry-point>
cbr %arg1, .L5, .L4
.L4:
call spin_lock
br .L5
.L5:
# call %r4 <- errno, %r1
select.32 %r6 <- %arg1, $0xffffffff, $0
cbr %arg1, .L6, .L2
.L2:
call spin_unlock
br .L6
.L6:
ret.32 %r6
but note how it removed not the select statement I expected, so you
don't actually end up with a branch to a branch anyway.
Oh well. It's close. That "select" could be anywhere, so the branch
following could know that.
And my patch may be garbage too. I just decided to take a look at how
easy the "combine select conditional" might be.
(In fact, my patch *IS* garbage, because it should do the same for
"OP_SET_NE" as an def to the select too)
Linus
Attachment:
patch
Description: Binary data
