Re: Patch ping (was Re: [PATCH] Oprimize stack_protect_set_1_ followed by a move to the same register (PR target/92841))

2019-12-19 Thread Uros Bizjak
On Fri, Dec 20, 2019 at 12:26 AM Jakub Jelinek wrote: > > On Thu, Dec 19, 2019 at 06:23:59PM +0100, Jakub Jelinek wrote: > > On Thu, Dec 19, 2019 at 04:50:40PM +0100, Jan Hubicka wrote: > > > Outputting the move as RIP relative movq would work. > > > LC12 is string "s" and has nothing to do with

Re: Patch ping (was Re: [PATCH] Oprimize stack_protect_set_1_ followed by a move to the same register (PR target/92841))

2019-12-19 Thread Jakub Jelinek
On Thu, Dec 19, 2019 at 06:23:59PM +0100, Jakub Jelinek wrote: > On Thu, Dec 19, 2019 at 04:50:40PM +0100, Jan Hubicka wrote: > > Outputting the move as RIP relative movq would work. > > LC12 is string "s" and has nothing to do with stack protecting. > > This should fix it by doing more carefully

Re: Patch ping (was Re: [PATCH] Oprimize stack_protect_set_1_ followed by a move to the same register (PR target/92841))

2019-12-19 Thread Jakub Jelinek
On Thu, Dec 19, 2019 at 04:50:40PM +0100, Jan Hubicka wrote: > Outputting the move as RIP relative movq would work. > LC12 is string "s" and has nothing to do with stack protecting. This should fix it by doing more carefully what *movdi_internal does. Will bootstrap/regtest it tonight.

Re: Patch ping (was Re: [PATCH] Oprimize stack_protect_set_1_ followed by a move to the same register (PR target/92841))

2019-12-19 Thread Jan Hubicka
> On Thu, Dec 19, 2019 at 04:01:31PM +0100, Jan Hubicka wrote: > > I now get build failure of Firefox with LTO due to: > > > > movabsq $.LC12, %rax > > > > which is output by: > > > > (insn:TI 468 3 849 2 (parallel [ > > > > (set

Re: Patch ping (was Re: [PATCH] Oprimize stack_protect_set_1_ followed by a move to the same register (PR target/92841))

2019-12-19 Thread Jakub Jelinek
On Thu, Dec 19, 2019 at 04:01:31PM +0100, Jan Hubicka wrote: > I now get build failure of Firefox with LTO due to: > > movabsq $.LC12, %rax > > which is output by: > > (insn:TI 468 3 849 2 (parallel [ > > (set (mem/v/f/c:DI (plus:DI

Re: Patch ping (was Re: [PATCH] Oprimize stack_protect_set_1_ followed by a move to the same register (PR target/92841))

2019-12-19 Thread Jan Hubicka
> Hi! > > I'd like to ping this patch (with the sizeof (c) -> sizeof (c) / sizeof (c[0]) > testsuite fix Andreas pointed out). > > Thanks! > > On Tue, Dec 10, 2019 at 10:57:35AM +0100, Jakub Jelinek wrote: > > 2019-12-10 Jakub Jelinek > > > > PR target/92841 > > *

Re: [PATCH] Oprimize stack_protect_set_1_ followed by a move to the same register (PR target/92841)

2019-12-17 Thread Uros Bizjak
On Tue, Dec 10, 2019 at 10:57 AM Jakub Jelinek wrote: > > Hi! > > The stack_protect_set_1_ pattern intentionally clears the register it > used as a temporary to read the canary from the register and push it back > on the stack for security reasons, to make sure the stack canary isn't > spilled

Patch ping (was Re: [PATCH] Oprimize stack_protect_set_1_ followed by a move to the same register (PR target/92841))

2019-12-17 Thread Jakub Jelinek
Hi! I'd like to ping this patch (with the sizeof (c) -> sizeof (c) / sizeof (c[0]) testsuite fix Andreas pointed out). Thanks! On Tue, Dec 10, 2019 at 10:57:35AM +0100, Jakub Jelinek wrote: > 2019-12-10 Jakub Jelinek > > PR target/92841 > * config/i386/i386.md

Re: [PATCH] Oprimize stack_protect_set_1_ followed by a move to the same register (PR target/92841)

2019-12-10 Thread Jakub Jelinek
On Tue, Dec 10, 2019 at 11:02:39AM +0100, Andreas Schwab wrote: > On Dez 10 2019, Jakub Jelinek wrote: > > > --- gcc/testsuite/gcc.target/i386/pr92841.c.jj 2019-12-09 > > 19:38:29.572759215 +0100 > > +++ gcc/testsuite/gcc.target/i386/pr92841.c 2019-12-09 19:40:59.642492417 > > +0100 > > @@

Re: [PATCH] Oprimize stack_protect_set_1_ followed by a move to the same register (PR target/92841)

2019-12-10 Thread Andreas Schwab
On Dez 10 2019, Jakub Jelinek wrote: > --- gcc/testsuite/gcc.target/i386/pr92841.c.jj2019-12-09 > 19:38:29.572759215 +0100 > +++ gcc/testsuite/gcc.target/i386/pr92841.c 2019-12-09 19:40:59.642492417 > +0100 > @@ -0,0 +1,17 @@ > +/* PR target/92841 */ > +/* { dg-do compile { target

[PATCH] Oprimize stack_protect_set_1_ followed by a move to the same register (PR target/92841)

2019-12-10 Thread Jakub Jelinek
Hi! The stack_protect_set_1_ pattern intentionally clears the register it used as a temporary to read the canary from the register and push it back on the stack for security reasons, to make sure the stack canary isn't spilled somewhere else etc. On the following testcase, we end up with a