From: Segher Boessenkool <segher@kernel.crashing.org>
To: Nicholas Piggin <npiggin@gmail.com>
Cc: linux-kernel@vger.kernel.org, Paul Mackerras <paulus@samba.org>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v2 1/2] powerpc/bug: Remove specific powerpc BUG_ON() and WARN_ON() on PPC32
Date: Thu, 26 Aug 2021 10:30:48 -0500 [thread overview]
Message-ID: <20210826153048.GD1583@gate.crashing.org> (raw)
In-Reply-To: <1629989540.drlhb24t2w.astroid@bobo.none>
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
> >> 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.
> >
> > (s/dispatched/issued/)
>
> ?
Dispatch is from decode to the issue queues. Issue is from there to
execution units. Dispatch is in-order, issue is not.
> >> How could it validate prediction without issuing? It wouldn't know when
> >> sources are ready.
> >
> > In the backend. But that is just how it worked on older cores :-/
>
> Okay. I don't know about older cores than POWER9. Backend would normally
> 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.
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.
> But that would be horrible for mispredict penalty.
See the previous point. Also, any insn known to be mispredicted can be
flushed immediately anyway.
> >> >> The first problem seems like the show stopper though. AFAIKS it would
> >> >> need a special builtin support that does something to create the table
> >> >> 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 instruction
> >> >> following the trap.
> >> >
> >> > I'm not quite sure what this means. Can't you always just put a
> >> >
> >> > bla: asm("");
> >> >
> >> > in there, and use the address of "bla"?
> >>
> >> Not AFAIKS. Put it where?
> >
> > After wherever you want to know the address after. You will have to
> > make sure they stay together somehow.
>
> I still don't follow.
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;
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.
> If you could give a built in that put a label at the address of the trap
> instruction that could be used later by inline asm then that could work
> too:
>
> __builtin_labeled_trap("1:");
> asm (" .section __bug_table,\"aw\" \n\t"
> "2: .4byte 1b - 2b \n\t"
> " .previous");
How could a compiler do anything like that?!
Segher
WARNING: multiple messages have this Message-ID (diff)
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Nicholas Piggin <npiggin@gmail.com>
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>
Subject: Re: [PATCH v2 1/2] powerpc/bug: Remove specific powerpc BUG_ON() and WARN_ON() on PPC32
Date: Thu, 26 Aug 2021 10:30:48 -0500 [thread overview]
Message-ID: <20210826153048.GD1583@gate.crashing.org> (raw)
In-Reply-To: <1629989540.drlhb24t2w.astroid@bobo.none>
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
> >> 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.
> >
> > (s/dispatched/issued/)
>
> ?
Dispatch is from decode to the issue queues. Issue is from there to
execution units. Dispatch is in-order, issue is not.
> >> How could it validate prediction without issuing? It wouldn't know when
> >> sources are ready.
> >
> > In the backend. But that is just how it worked on older cores :-/
>
> Okay. I don't know about older cores than POWER9. Backend would normally
> 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.
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.
> But that would be horrible for mispredict penalty.
See the previous point. Also, any insn known to be mispredicted can be
flushed immediately anyway.
> >> >> The first problem seems like the show stopper though. AFAIKS it would
> >> >> need a special builtin support that does something to create the table
> >> >> 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 instruction
> >> >> following the trap.
> >> >
> >> > I'm not quite sure what this means. Can't you always just put a
> >> >
> >> > bla: asm("");
> >> >
> >> > in there, and use the address of "bla"?
> >>
> >> Not AFAIKS. Put it where?
> >
> > After wherever you want to know the address after. You will have to
> > make sure they stay together somehow.
>
> I still don't follow.
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;
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.
> If you could give a built in that put a label at the address of the trap
> instruction that could be used later by inline asm then that could work
> too:
>
> __builtin_labeled_trap("1:");
> asm (" .section __bug_table,\"aw\" \n\t"
> "2: .4byte 1b - 2b \n\t"
> " .previous");
How could a compiler do anything like that?!
Segher
next prev parent reply other threads:[~2021-08-26 15:34 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-13 16:38 [PATCH v2 1/2] powerpc/bug: Remove specific powerpc BUG_ON() and WARN_ON() on PPC32 Christophe Leroy
2021-04-13 16:38 ` Christophe Leroy
2021-04-13 16:38 ` [PATCH v2 2/2] powerpc/bug: Provide better flexibility to WARN_ON/__WARN_FLAGS() with asm goto Christophe Leroy
2021-04-13 16:38 ` Christophe Leroy
2021-08-13 6:19 ` Nicholas Piggin
2021-08-13 6:19 ` Nicholas Piggin
2021-08-15 3:49 ` Michael Ellerman
2021-08-15 3:49 ` Michael Ellerman
2021-08-25 21:25 ` Nathan Chancellor
2021-08-25 21:25 ` Nathan Chancellor
2021-08-26 3:21 ` Michael Ellerman
2021-08-26 3:21 ` Michael Ellerman
2021-08-26 6:37 ` Christophe Leroy
2021-08-26 6:37 ` Christophe Leroy
2021-08-26 13:47 ` Segher Boessenkool
2021-08-26 13:47 ` Segher Boessenkool
2021-08-26 14:45 ` Michael Ellerman
2021-08-26 14:45 ` Michael Ellerman
2021-08-26 14:53 ` Christophe Leroy
2021-08-26 14:53 ` Christophe Leroy
2021-08-26 14:12 ` Segher Boessenkool
2021-08-26 14:12 ` Segher Boessenkool
2021-08-26 18:54 ` Nathan Chancellor
2021-08-26 18:54 ` Nathan Chancellor
2021-08-26 23:55 ` Nathan Chancellor
2021-08-26 23:55 ` Nathan Chancellor
2021-08-27 7:53 ` Michael Ellerman
2021-08-27 7:53 ` Michael Ellerman
2021-08-13 6:08 ` [PATCH v2 1/2] powerpc/bug: Remove specific powerpc BUG_ON() and WARN_ON() on PPC32 Nicholas Piggin
2021-08-13 6:08 ` Nicholas Piggin
2021-08-18 15:06 ` Segher Boessenkool
2021-08-18 15:06 ` Segher Boessenkool
2021-08-26 3:26 ` Nicholas Piggin
2021-08-26 3:26 ` Nicholas Piggin
2021-08-26 12:49 ` Segher Boessenkool
2021-08-26 12:49 ` Segher Boessenkool
2021-08-26 13:57 ` Nicholas Piggin
2021-08-26 13:57 ` Nicholas Piggin
2021-08-26 14:37 ` Segher Boessenkool
2021-08-26 14:37 ` Segher Boessenkool
2021-08-26 15:04 ` Nicholas Piggin
2021-08-26 15:04 ` Nicholas Piggin
2021-08-26 15:30 ` Segher Boessenkool [this message]
2021-08-26 15:30 ` Segher Boessenkool
2021-08-27 1:28 ` Nicholas Piggin
2021-08-27 1:28 ` Nicholas Piggin
2021-08-18 13:38 ` Michael Ellerman
2021-08-18 13:38 ` Michael Ellerman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210826153048.GD1583@gate.crashing.org \
--to=segher@kernel.crashing.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=npiggin@gmail.com \
--cc=paulus@samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.