+2895,10 @@ (define_insn "*jump_pic"
}
[(set_attr "type" "branch")])
+;; Micro-architecture unconditionally treats a "jr $ra" as "return
from subroutine",
+;; non-returning indirect jumps through $ra would interfere with
both subrouti
garch.md | 8 ++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/gcc/config/loongarch/loongarch.md
> > b/gcc/config/loongarch/loongarch.md
> > index 816a943d155..b37e070660f 100644
> > --- a/gcc/config/loongarch/loongarc
ngarch.md
+++ b/gcc/config/loongarch/loongarch.md
@@ -2895,6 +2895,10 @@ (define_insn "*jump_pic"
}
[(set_attr "type" "branch")])
+;; Micro-architecture unconditionally treats a "jr $ra" as "return from subroutine",
+;; non-returning indirect jumps through
[(set_attr "type" "branch")])
+;; Micro-architecture unconditionally treats a "jr $ra" as "return from
subroutine",
+;; non-returning indirect jumps through $ra would interfere with both
subroutine
+;; return prediction and the more general indirect br
Ping patch.
| Date: Fri, 19 Nov 2021 09:53:14 -0500
| From: Michael Meissner
| Subject: [PATCH 1/3] Add power10 zero cycle moves for switches & indirect
jumps
| Message-ID:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585005.html
Note, I will on-line through December 20th. I
On Mon, Nov 22, 2021 at 10:36:13AM -0600, Bill Schmidt wrote:
> Hi Mike,
>
> Thanks for this patch!
> > --- a/gcc/config/rs6000/rs6000.md
> > +++ b/gcc/config/rs6000/rs6000.md
> > @@ -12988,15 +12988,34 @@ (define_expand "indirect_jump"
> > emit_jump_insn (gen_indirect_jump_nospec (Pmode, ope
Hi Mike,
Thanks for this patch!
On 11/19/21 8:53 AM, Michael Meissner wrote:
> Add power10 zero cycle moves for switches.
>
> Power10 will fuse adjacenet 'mtctr' and 'bctr' instructions to form zero
> cycle moves. This code exploits this fusion opportunity.
>
> I have built bootstrapped compiler
Add power10 zero cycle moves for switches.
Power10 will fuse adjacenet 'mtctr' and 'bctr' instructions to form zero
cycle moves. This code exploits this fusion opportunity.
I have built bootstrapped compilers with this patch on little endian power9 and
power10 systems with no regressions. Can I
On Feb 6, 2018, at 10:33 AM, Segher Boessenkool
wrote:
>
> Hi Bill,
>
> On Mon, Feb 05, 2018 at 12:28:34PM -0600, Bill Schmidt wrote:
>> It's been determined that we won't recommend use of the recently added
>> undocumented option -mno-speculate-indirec
Hi Bill,
On Mon, Feb 05, 2018 at 12:28:34PM -0600, Bill Schmidt wrote:
> It's been determined that we won't recommend use of the recently added
> undocumented option -mno-speculate-indirect-jumps. This patch provides
> a warning indicating that the option is deprecated. We wi
Hi,
It's been determined that we won't recommend use of the recently added
undocumented option -mno-speculate-indirect-jumps. This patch provides
a warning indicating that the option is deprecated. We will leave the
code in place for potential emergency use (not expected), and plan to
Hi!
On Fri, Jan 19, 2018 at 09:46:27PM -0600, Bill Schmidt wrote:
> Segher had previously requested some cleanups in
> https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01605.html.
> Due to time pressures, I delayed those, but they are ready now. Here they
> are,
> bootstrapped and tested on powerp
Hi,
Segher had previously requested some cleanups in
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01605.html.
Due to time pressures, I delayed those, but they are ready now. Here they are,
bootstrapped and tested on powerpc64le-linux-gnu and powerpc64-linux-gnu. Is
this okay for trunk? I don'
ked up on a respin
anyway. So I should have the fix in place before that happens.
Bill
>
> Thanks, David
>
> On Tue, Jan 16, 2018 at 9:08 PM, Bill Schmidt
> wrote:
>> Hi,
>>
>> This patch supercedes and extends
>> https://gcc.gnu.org/ml/gcc-patches/2018-01/msg0
On Fri, Jan 19, 2018 at 10:01:50AM -0700, Sandra Loosemore wrote:
>
> I see no documentation for the new option here :-(
+;; -mno-speculate-indirect-jumps adds deliberate misprediction to indirect
+;; branches via the CTR.
+mspeculate-indirect-jumps
+Target Undocument
incorrect. I am going
to try testing with "$" in trunk.
GCC 7.3 must be re-spun.
Thanks, David
On Tue, Jan 16, 2018 at 9:08 PM, Bill Schmidt
wrote:
> Hi,
>
> This patch supercedes and extends
> https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01479.html,
> adding the remaini
On 01/15/2018 04:09 PM, Bill Schmidt wrote:
[gcc]
2018-01-15 Bill Schmidt
* config/rs6000/rs6000.c (rs6000_opt_vars): Add entry for
-mspeculate-indirect-jumps.
* config/rs6000/rs6000.md (*call_indirect_elfv2): Disable
for -mno-speculate-indirect-jumps
On Tue, Jan 16, 2018 at 08:08:57PM -0600, Bill Schmidt wrote:
> This patch supercedes and extends
> https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01479.html,
> adding the remaining big-endian support for -mno-speculate-indirect-jumps.
> This includes 32-bit support for indirect calls
Hi,
This patch supercedes and extends
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01479.html,
adding the remaining big-endian support for -mno-speculate-indirect-jumps.
This includes 32-bit support for indirect calls and sibling calls, and
64-bit support for indirect calls. The endian
Hi,
This patch fills in a gap from the previous -mno-speculate-indirect-jumps
patch. That patch didn't provide support for indirect calls using ABI_AIX
as the default ABI. This fills in that missing support and changes the
one related powerpc64le-only test case to be compiled for all subta
f we have any knobs to tune we
>> should probably
>> tweak them away from the indirect jump using variants with
>> -mno-speculate-indirect-jumps,
>> right?
>
> We can generate indirect jumps for other situations so this patch will
> still be needed.
Also, I'm
Hi!
On Mon, Jan 15, 2018 at 05:09:06PM -0600, Bill Schmidt wrote:
> @@ -12933,9 +12974,27 @@
>""
> {
>if (TARGET_32BIT)
> -emit_jump_insn (gen_tablejumpsi (operands[0], operands[1]));
> +{
> + if (rs6000_speculate_indirect_jumps)
> + emit_jump_insn (gen_tablejumpsi (opera
rect jump using variants with
> -mno-speculate-indirect-jumps,
> right?
We can generate indirect jumps for other situations so this patch will
still be needed.
> Performance optimization, so shouldn't block this patch - I just
> thought I should probably
> mention this.
Yeah let's get this done first :-)
Segher
e have any knobs to tune we
should probably
tweak them away from the indirect jump using variants with
-mno-speculate-indirect-jumps,
right?
Performance optimization, so shouldn't block this patch - I just
thought I should probably
mention this.
Richard.
> Thanks,
> Bill
>
sions. Is this okay for trunk?
Thanks,
Bill
[gcc]
2018-01-15 Bill Schmidt
* config/rs6000/rs6000.c (rs6000_opt_vars): Add entry for
-mspeculate-indirect-jumps.
* config/rs6000/rs6000.md (*call_indirect_elfv2): Disable
for -mno-speculate-indi
On Mon, Jan 15, 2018 at 11:54:41AM -0600, Bill Schmidt wrote:
> > I think we settled on calling the option -mmispredict-indirect-jumps;
> > please let me know if you still agree with that. Or have thought of a
> > better name :-)
>
> Looks like we are now looking at -
Hi Segher,
Thanks for the quick review!
> On Jan 15, 2018, at 10:38 AM, Segher Boessenkool
> wrote:
>
> Hi!
>
> On Sat, Jan 13, 2018 at 10:53:57PM -0600, Bill Schmidt wrote:
>> This patch adds a new option for the compiler to produce only "safe" indirect
On Jan 15, 2018, at 11:05 AM, Segher Boessenkool
wrote:
>
> Hi!
>
> On Sun, Jan 14, 2018 at 11:34:06AM -0600, Bill Schmidt wrote:
>> It was pointed out off-list that I should add some executable tests for
>> the new -msafe-indirect-jumps implementation. This patch add
Hi!
On Sun, Jan 14, 2018 at 11:34:06AM -0600, Bill Schmidt wrote:
> It was pointed out off-list that I should add some executable tests for
> the new -msafe-indirect-jumps implementation. This patch adds three
> such tests to demonstrate correct behavior.
>
> Tested on powerpc6
Hi!
On Sat, Jan 13, 2018 at 10:53:57PM -0600, Bill Schmidt wrote:
> This patch adds a new option for the compiler to produce only "safe" indirect
> jumps, in the sense that these jumps are deliberately mispredicted to inhibit
> speculative execution. For now, this option is
he assembly code produced by that patch (bad
>> memory on my account of how to spell "crset eq"). I've also increased the
>> function provided; see below.]
>>
>> This patch adds a new option for the compiler to produce only "safe" indirect
>>
;crset eq"). I've also increased the
> function provided; see below.]
>
> This patch adds a new option for the compiler to produce only "safe" indirect
> jumps, in the sense that these jumps are deliberately mispredicted to inhibit
> speculative execution. For n
Hi,
It was pointed out off-list that I should add some executable tests for
the new -msafe-indirect-jumps implementation. This patch adds three
such tests to demonstrate correct behavior.
Tested on powerpc64-linux-gnu and powerpc64le-linux-gnu. Are these tests
okay for trunk after the other
Hi,
This is now superceded by
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01204.html.
Sorry for the noise.
Thanks,
Bill
> On Jan 12, 2018, at 4:33 PM, Bill Schmidt wrote:
>
> Hi,
>
> This patch adds a new option for the compiler to produce only "safe" indirect
&
is patch adds a new option for the compiler to produce only "safe" indirect
jumps, in the sense that these jumps are deliberately mispredicted to inhibit
speculative execution. For now, this option is undocumented; this may change
at some future date. It is intended eventually for the
Hi,
This patch adds a new option for the compiler to produce only "safe" indirect
jumps, in the sense that these jumps are deliberately mispredicted to inhibit
speculative execution. For now, this option is undocumented; this may change
at some future date. It is intended eventual
On 08/25/15 15:10, Jeff Law wrote:
On 08/25/2015 08:11 AM, Nathan Sidwell wrote:
We could emulate by creating a new stack frame and shoving the target of the
branch into the stack, then executing a return. However, I don't think that's
worth doing ;-)
And wouldn't work for PTX anyway -- all
On 08/25/2015 08:11 AM, Nathan Sidwell wrote:
Ptx is one of those rare (unique?) machines that doesn't have an
indirect branch. optabs is prepared for such a target and emits a
sorry when an indirect branch is needed. However it then goes on to try
and emit such an instruction and ends up I
===
--- gcc/optabs.c (revision 227128)
+++ gcc/optabs.c (working copy)
@@ -4488,11 +4488,13 @@ emit_indirect_jump (rtx loc)
{
if (!targetm.have_indirect_jump ())
sorry ("indirect jumps are not available on this target");
-
- struct expand_operand ops[1];
- create_addr
While testing something else, I noticed a couple compilation errors like:
/tmp/ccCxOOoN.s: Assembler messages:
/tmp/ccCxOOoN.s:164: Error: r31 cannot be used with jmp; use ret instead
The assembler is correct in rejecting this code, since this is a
documented restriction of the JMP instruction.
On 11/04/2014 04:32 PM, Bernd Schmidt wrote:
> On 10/20/2014 04:19 PM, Bernd Schmidt wrote:
>> ptx doesn't have indirect jumps, so CODE_FOR_indirect_jump may not be
>> defined. Add a sorry.
>
> Looking back through all the mails it turns out this one wasn't approved yet.
> Ping?
Ok.
r~
On 10/20/2014 04:19 PM, Bernd Schmidt wrote:
ptx doesn't have indirect jumps, so CODE_FOR_indirect_jump may not be
defined. Add a sorry.
Looking back through all the mails it turns out this one wasn't approved
yet. Ping?
Bernd
On Wed, Oct 22, 2014 at 12:02:16PM +0200, Richard Biener wrote:
> > I'm not sure that's what you're suggesting, but at least on non-shared
> > memory offloading devices, you can't switch arbitrarily between
> > offloading device(s) and host-fallback, for you have to do data
> > management between t
On Wed, Oct 22, 2014 at 10:34 AM, Thomas Schwinge
wrote:
> Hi!
>
> On Wed, 22 Oct 2014 10:18:49 +0200, Richard Biener
> wrote:
>> On Tue, Oct 21, 2014 at 11:32 PM, Bernd Schmidt
>> wrote:
>> > On 10/21/2014 11:30 PM, Jakub Jelinek wrote:
>> >>
>> >> At least for OpenMP, the best would be if th
Hi!
On Wed, 22 Oct 2014 10:18:49 +0200, Richard Biener
wrote:
> On Tue, Oct 21, 2014 at 11:32 PM, Bernd Schmidt
> wrote:
> > On 10/21/2014 11:30 PM, Jakub Jelinek wrote:
> >>
> >> At least for OpenMP, the best would be if the #pragma omp target regions
> >> and/or #pragma omp declare target fu
On Wed, Oct 22, 2014 at 10:18:49AM +0200, Richard Biener wrote:
> On Tue, Oct 21, 2014 at 11:32 PM, Bernd Schmidt
> wrote:
> > On 10/21/2014 11:30 PM, Jakub Jelinek wrote:
> >>
> >> At least for OpenMP, the best would be if the #pragma omp target regions
> >> and/or #pragma omp declare target fun
On Tue, Oct 21, 2014 at 11:32 PM, Bernd Schmidt wrote:
> On 10/21/2014 11:30 PM, Jakub Jelinek wrote:
>>
>> At least for OpenMP, the best would be if the #pragma omp target regions
>> and/or #pragma omp declare target functions contain anything a particular
>> offloading accelerator can't handle,
On 10/21/2014 11:30 PM, Jakub Jelinek wrote:
At least for OpenMP, the best would be if the #pragma omp target regions
and/or #pragma omp declare target functions contain anything a particular
offloading accelerator can't handle, instead of failing the whole
compilation perhaps just emit some at l
On Tue, Oct 21, 2014 at 11:00:35PM +0200, Bernd Schmidt wrote:
> On 10/21/2014 08:26 PM, Jeff Law wrote:
> >>* optabs.c (emit_indirect_jump): Test HAVE_indirect_jump and emit a
> >>sorry if necessary.
> >So doesn't this imply no hot-cold partitioning since
On 10/21/2014 08:26 PM, Jeff Law wrote:
* optabs.c (emit_indirect_jump): Test HAVE_indirect_jump and emit a
sorry if necessary.
So doesn't this imply no hot-cold partitioning since we use indirect
jumps to get across the partition? Similarly doesn't this imply other
missin
On 10/20/14 14:19, Bernd Schmidt wrote:
ptx doesn't have indirect jumps, so CODE_FOR_indirect_jump may not be
defined. Add a sorry.
Bernd
001-indjumps.diff
gcc/
* optabs.c (emit_indirect_jump): Test HAVE_indirect_jump and emit a
sorry if necessary.
So doesn&#
ptx doesn't have indirect jumps, so CODE_FOR_indirect_jump may not be
defined. Add a sorry.
Bernd
gcc/
* optabs.c (emit_indirect_jump): Test HAVE_indirect_jump and emit a
sorry if necessary.
Index: gcc/opt
52 matches
Mail list logo
