Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Fri, 27 Aug 2021 11:28:27 +1000
From:   Nicholas Piggin <npiggin@gmail.com>
Subject: Re: [PATCH v2 1/2] powerpc/bug: Remove specific powerpc BUG_ON() and
 WARN_ON() on PPC32
To:     Segher Boessenkool <segher@kernel.crashing.org>
Cc:     Benjamin Herrenschmidt <benh@kernel.crashing.org>,
        Christophe Leroy <christophe.leroy@csgroup.eu>,
        linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
        Michael Ellerman <mpe@ellerman.id.au>,
        Paul Mackerras <paulus@samba.org>
References: <b286e07fb771a664b631cd07a40b09c06f26e64b.1618331881.git.christophe.leroy@csgroup.eu>
        <1628834356.pr4zgn1xf1.astroid@bobo.none>
        <20210818150653.GJ1583@gate.crashing.org>
        <1629946707.f6ptz0tgle.astroid@bobo.none>
        <20210826124901.GY1583@gate.crashing.org>
        <1629983260.5jkx2jf0y8.astroid@bobo.none>
        <20210826143708.GC1583@gate.crashing.org>
        <1629989540.drlhb24t2w.astroid@bobo.none>
        <20210826153048.GD1583@gate.crashing.org>
In-Reply-To: <20210826153048.GD1583@gate.crashing.org>
MIME-Version: 1.0
Message-Id: <1630026648.b7bpnt3hrh.astroid@bobo.none>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Excerpts from Segher Boessenkool's message of August 27, 2021 1:30 am:
> On Fri, Aug 27, 2021 at 01:04:36AM +1000, Nicholas Piggin wrote:
>> Excerpts from Segher Boessenkool's message of August 27, 2021 12:37 am:
>> >> No, they are all dispatched and issue to the BRU for execution. It's=20
>> >> trivial to construct a test of a lot of not taken branches in a row
>> >> and time a loop of it to see it executes at 1 cycle per branch.
>> >=20
>> > (s/dispatched/issued/)
>>=20
>> ?
>=20
> Dispatch is from decode to the issue queues.  Issue is from there to
> execution units.  Dispatch is in-order, issue is not.

I know what those mean, I wonder what your s/dispatched/issued means.
I was saying they are dispatched in response to you saying they never
hit the issue queue.

>=20
>> >> How could it validate prediction without issuing? It wouldn't know wh=
en
>> >> sources are ready.
>> >=20
>> > In the backend.  But that is just how it worked on older cores :-/
>>=20
>> Okay. I don't know about older cores than POWER9. Backend would normally=
=20
>> include execution though.
>> Only other place you could do it if you don't
>> issue/exec would be after it goes back in order, like completion.
>=20
> You do not have to do the verification in-order: the insn cannot finish
> until it is no longer speculative, that takes care of all ordering
> needed.

Branches *can* finish out of order and speculative as they do in P9 and=20
P10. Are you talking about these CPUs or something else which can=20
verify branches without issuing them?

>=20
>> But that would be horrible for mispredict penalty.
>=20
> See the previous point.  Also, any insn known to be mispredicted can be
> flushed immediately anyway.

The point is it has to know sources (CR) to verify (aka execute) the=20
branch prediction was right, and if it needs sources then it needs to=20
either issue and execute in the out of order part, or it needs to wait
until completion which would seem to be prohibitively expensive. I am
interested to know how it works.

>=20
>> >> >> The first problem seems like the show stopper though. AFAIKS it wo=
uld=20
>> >> >> need a special builtin support that does something to create the t=
able
>> >> >> entry, or a guarantee that we could put an inline asm right after =
the
>> >> >> builtin as a recognized pattern and that would give us the instruc=
tion
>> >> >> following the trap.
>> >> >=20
>> >> > I'm not quite sure what this means.  Can't you always just put a
>> >> >=20
>> >> > bla:	asm("");
>> >> >=20
>> >> > in there, and use the address of "bla"?
>> >>=20
>> >> Not AFAIKS. Put it where?
>> >=20
>> > After wherever you want to know the address after.  You will have to
>> > make sure they stay together somehow.
>>=20
>> I still don't follow.
>=20
> some_thing_you_want_to_know_the_address_after_let_us_call_it_A;
> empty_asm_that_we_can_take_the_address_of_known_as_B;
>=20
> You have to make sure the compiler keeps A and B together, does not
> insert anything between them, does put them in the assembler output in
> the same fragment, etc.

How does all this help our problem of putting the address of the trap=20
into the table?

>=20
>> If you could give a built in that put a label at the address of the trap=
=20
>> instruction that could be used later by inline asm then that could work
>> too:
>>=20
>>     __builtin_labeled_trap("1:");
>>     asm ("    .section __bug_table,\"aw\"  \n\t"
>>          "2:  .4byte 1b - 2b               \n\t"
>>          "    .previous");
>=20
> How could a compiler do anything like that?!

How could it add a label at the trap instruction it generates? It didn't=20
seem like an outlandish thing to do, but I'm not a compiler writer. It was=20
just a handwaving idea to show what we want to be able to do.

Thanks,
Nick