Re: [RFC] postreload cse'ing vector constants

2022-11-20 Thread Jeff Law via Gcc-patches
On 11/3/22 06:38, Robin Dapp wrote: Should we go ahead with this, i.e. push the change and wait for fallout? I guess we're still early enough in the cycle for that. There are no regressions anymore on s390, Power9, x86 and aarch64 (at least on the farm machines I checked). That would be

Re: [RFC] postreload cse'ing vector constants

2022-11-03 Thread Robin Dapp via Gcc-patches
Should we go ahead with this, i.e. push the change and wait for fallout? I guess we're still early enough in the cycle for that. There are no regressions anymore on s390, Power9, x86 and aarch64 (at least on the farm machines I checked). Regards Robin

Re: [RFC] postreload cse'ing vector constants

2022-09-28 Thread Robin Dapp via Gcc-patches
> I opened: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107061 The online docs for encodekey256 also say XMM4 through XMM6 are reserved for future usages and software should not rely upon them being zeroed. I believe we also zero there. > This sounds like an issue. So with your patch

Re: [RFC] postreload cse'ing vector constants

2022-09-27 Thread H.J. Lu via Gcc-patches
On Tue, Sep 27, 2022 at 10:46 AM Robin Dapp via Gcc-patches wrote: > > > I did bootstrapping and ran the testsuite on x86(-64), aarch64, Power9 > > and s390. Everything looks good except two additional fails on x86 > > where code actually looks worse. > > > >

Re: [RFC] postreload cse'ing vector constants

2022-09-27 Thread Robin Dapp via Gcc-patches
> I did bootstrapping and ran the testsuite on x86(-64), aarch64, Power9 > and s390. Everything looks good except two additional fails on x86 > where code actually looks worse. > > gcc.target/i386/keylocker-encodekey128.c > > 17c17,18 > < movaps %xmm4, k2(%rip) > --- >> pxor

Re: [RFC] postreload cse'ing vector constants

2022-09-08 Thread Robin Dapp via Gcc-patches
> Which is this from the mail archives: > > https://gcc.gnu.org/pipermail/gcc-patches/1998-June/000308.html > > I would tend to agree that for equal cost that the constant would be > preferred since that should be better from a scheduling/dependency > standpoint.   So it seems to me we can

Re: [RFC] postreload cse'ing vector constants

2022-09-07 Thread Jeff Law via Gcc-patches
On 9/7/2022 9:33 AM, Robin Dapp wrote: Did you did any archeology into this code to see if there was any history that might shed light on why it doesn't just using the costing models? This one was buried under some dust :) commit 0254c56158b0533600ba9036258c11d377d46adf Author: John Carr

Re: [RFC] postreload cse'ing vector constants

2022-09-07 Thread Robin Dapp via Gcc-patches
> Did you did any archeology into this code to see if there was any > history that might shed light on why it doesn't just using the costing > models? This one was buried under some dust :) commit 0254c56158b0533600ba9036258c11d377d46adf Author: John Carr Date: Wed Jun 10 06:00:50 1998 +

Re: [RFC] postreload cse'ing vector constants

2022-09-07 Thread Jeff Law via Gcc-patches
On 9/7/2022 8:40 AM, Robin Dapp via Gcc-patches wrote: Hi, I recently looked into a sequence like vzero %v0 vlr %v2, %v0 vlr %v3, %v0. Ideally we would like to use vzero for all of these sets in order to not create dependencies. For some instances of this problem I found the

[RFC] postreload cse'ing vector constants

2022-09-07 Thread Robin Dapp via Gcc-patches
Hi, I recently looked into a sequence like vzero %v0 vlr %v2, %v0 vlr %v3, %v0. Ideally we would like to use vzero for all of these sets in order to not create dependencies. For some instances of this problem I found the offending snippet to be the postreload cse pass. If there is a non