Re: [V2] New pass for sign/zero extension elimination -- not ready for "final" review

2023-12-12 Thread Jeff Law
On 11/29/23 21:10, Joern Rennecke wrote: I originally computed mmask in carry_backpropagate from XEXP (x, 0), but abandoned that when I realized we also get called for RTX_OBJ things. I forgot to adjust the SIGN_EXTEND code, though. Fixed in the attached revised patch. Also made sure to

Re: [V2] New pass for sign/zero extension elimination -- not ready for "final" review

2023-11-30 Thread Xi Ruoyao
On Thu, 2023-11-30 at 08:44 -0700, Jeff Law wrote: > > > On 11/29/23 02:33, Xi Ruoyao wrote: > > On Mon, 2023-11-27 at 23:06 -0700, Jeff Law wrote: > > > This has (of course) been tested on rv64.  It's also been bootstrapped > > > and regression tested on x86.  Bootstrap and regression tested (C

Re: [V2] New pass for sign/zero extension elimination -- not ready for "final" review

2023-11-30 Thread Jeff Law
On 11/30/23 14:22, Jeff Law wrote: So if you're going to add opcodes in here, don't they also need to be in safe_for_propagation_p as well?  Otherwise they won't get used, right? I'm thinking about the HIGHPART cases for example.  As well as the saturating shifts which we indicated we were

Re: [V2] New pass for sign/zero extension elimination -- not ready for "final" review

2023-11-30 Thread Jeff Law
On 11/30/23 11:31, Joern Rennecke wrote: Pretending the vector modes don't happen is not making the code safe. We have to handle them somehow, so we might as well do that in a way that is consistent and gives more potential for optimization. We're not pretending they don't happen. Quite

Re: [V2] New pass for sign/zero extension elimination -- not ready for "final" review

2023-11-30 Thread Joern Rennecke
On Thu, 30 Nov 2023 at 17:53, Jeff Law wrote: > > * ext-dce.c: Fixes for carry handling. > > > > * ext-dce.c (safe_for_live_propagation): Handle MINUS. > >(ext_dce_process_uses): Break out carry handling into .. > >(carry_backpropagate): This new function. > >

Re: [V2] New pass for sign/zero extension elimination -- not ready for "final" review

2023-11-30 Thread Jeff Law
On 11/29/23 19:39, Joern Rennecke wrote: On Wed, 29 Nov 2023 at 20:05, Joern Rennecke wrote: I suspect it'd be more useful to add handling of LSHIFTRT and ASHIFTRT . Some ports do a lot of static shifting. +case SS_ASHIFT: +case US_ASHIFT: + if (!mask || XEXP (x, 1) ==

Re: [V2] New pass for sign/zero extension elimination -- not ready for "final" review

2023-11-30 Thread Jeff Law
On 11/29/23 19:39, Joern Rennecke wrote: On Wed, 29 Nov 2023 at 20:05, Joern Rennecke wrote: I suspect it'd be more useful to add handling of LSHIFTRT and ASHIFTRT . Some ports do a lot of static shifting. +case SS_ASHIFT: +case US_ASHIFT: + if (!mask || XEXP (x, 1) ==

Re: [V2] New pass for sign/zero extension elimination -- not ready for "final" review

2023-11-30 Thread Jeff Law
On 11/29/23 02:33, Xi Ruoyao wrote: On Mon, 2023-11-27 at 23:06 -0700, Jeff Law wrote: This has (of course) been tested on rv64.  It's also been bootstrapped and regression tested on x86.  Bootstrap and regression tested (C only) for m68k, sh4, sh4eb, alpha.  Earlier versions were also

Re: [V2] New pass for sign/zero extension elimination -- not ready for "final" review

2023-11-29 Thread Joern Rennecke
I originally computed mmask in carry_backpropagate from XEXP (x, 0), but abandoned that when I realized we also get called for RTX_OBJ things. I forgot to adjust the SIGN_EXTEND code, though. Fixed in the attached revised patch. Also made sure to not make inputs of LSHIFTRT / ASHIFTRT live if

Re: [V2] New pass for sign/zero extension elimination -- not ready for "final" review

2023-11-29 Thread Joern Rennecke
On Wed, 29 Nov 2023 at 20:05, Joern Rennecke wrote: > > I suspect it'd be more useful to add handling of LSHIFTRT and ASHIFTRT > > . Some ports do > > a lot of static shifting. > > > +case SS_ASHIFT: > > +case US_ASHIFT: > > + if (!mask || XEXP (x, 1) == const0_rtx) > > +

Re: [V2] New pass for sign/zero extension elimination -- not ready for "final" review

2023-11-29 Thread Joern Rennecke
On Wed, 29 Nov 2023 at 19:57, Joern Rennecke wrote: > > Attached is what I have for carry_backpropagate . > > The utility of special handling for SS_ASHIFT / US_ASHIFT seems > somewhat marginal. > > I suspect it'd be more useful to add handling of LSHIFTRT and ASHIFTRT > . Some ports do > a lot

[V2] New pass for sign/zero extension elimination -- not ready for "final" review

2023-11-29 Thread Joern Rennecke
Attached is what I have for carry_backpropagate . The utility of special handling for SS_ASHIFT / US_ASHIFT seems somewhat marginal. I suspect it'd be more useful to add handling of LSHIFTRT and ASHIFTRT . Some ports do a lot of static shifting. commit ed47c3d0d38f85c9b4e22bdbd079e0665465ef9c

Re: [V2] New pass for sign/zero extension elimination -- not ready for "final" review

2023-11-29 Thread Jivan Hakobyan
The reason is removing MINUS from safe_for_live_propagation. We did not do it on purpose, will roll back on V3. > On 29 Nov 2023, at 19:46, Xi Ruoyao wrote: > > On Wed, 2023-11-29 at 20:37 +0800, Xi Ruoyao wrote: >>> On Wed, 2023-11-29 at 17:33 +0800, Xi Ruoyao wrote: >>> On Mon,

Re: [V2] New pass for sign/zero extension elimination -- not ready for "final" review

2023-11-29 Thread Xi Ruoyao
On Wed, 2023-11-29 at 20:37 +0800, Xi Ruoyao wrote: > On Wed, 2023-11-29 at 17:33 +0800, Xi Ruoyao wrote: > > On Mon, 2023-11-27 at 23:06 -0700, Jeff Law wrote: > > > This has (of course) been tested on rv64.  It's also been bootstrapped > > > and regression tested on x86.  Bootstrap and

Re: [V2] New pass for sign/zero extension elimination -- not ready for "final" review

2023-11-29 Thread Xi Ruoyao
On Wed, 2023-11-29 at 17:33 +0800, Xi Ruoyao wrote: > On Mon, 2023-11-27 at 23:06 -0700, Jeff Law wrote: > > This has (of course) been tested on rv64.  It's also been bootstrapped > > and regression tested on x86.  Bootstrap and regression tested (C only) > > for m68k, sh4, sh4eb, alpha.  Earlier

Re: [V2] New pass for sign/zero extension elimination -- not ready for "final" review

2023-11-29 Thread Richard Sandiford
Jivan Hakobyan writes: >> >> The amdgcn ICE I reported still exists: > > > Can you send a build command to reproduce ICE. > I built on x86-64, RV32/64, and did not get any faults. The ICE that Andrew reported relies on configuring with: --enable-checking=yes,extra,rtl since rtl checking

Re: [V2] New pass for sign/zero extension elimination -- not ready for "final" review

2023-11-29 Thread Xi Ruoyao
On Mon, 2023-11-27 at 23:06 -0700, Jeff Law wrote: > This has (of course) been tested on rv64.  It's also been bootstrapped > and regression tested on x86.  Bootstrap and regression tested (C only) > for m68k, sh4, sh4eb, alpha.  Earlier versions were also bootstrapped > and regression tested on

Re: [V2] New pass for sign/zero extension elimination -- not ready for "final" review

2023-11-29 Thread Andrew Stubbs
On 28/11/2023 23:26, Jeff Law wrote: On 11/28/23 15:18, Jivan Hakobyan wrote:     The amdgcn ICE I reported still exists: Can you send a build command to reproduce ICE. I built on x86-64, RV32/64, and did not get any faults. THe code is clearly wrong though.  We need to test that we have a

Re: [V2] New pass for sign/zero extension elimination -- not ready for "final" review

2023-11-28 Thread Jeff Law
On 11/28/23 15:18, Jivan Hakobyan wrote: The amdgcn ICE I reported still exists: Can you send a build command to reproduce ICE. I built on x86-64, RV32/64, and did not get any faults. THe code is clearly wrong though. We need to test that we have a subreg before we look at the

Re: [V2] New pass for sign/zero extension elimination -- not ready for "final" review

2023-11-28 Thread Jivan Hakobyan
> > The amdgcn ICE I reported still exists: Can you send a build command to reproduce ICE. I built on x86-64, RV32/64, and did not get any faults. On Tue, Nov 28, 2023 at 7:08 PM Andrew Stubbs wrote: > On 28/11/2023 06:06, Jeff Law wrote: > > - Verify we have a SUBREG before looking at

Re: [V2] New pass for sign/zero extension elimination -- not ready for "final" review

2023-11-28 Thread Andrew Stubbs
On 28/11/2023 06:06, Jeff Law wrote: - Verify we have a SUBREG before looking at SUBREG_BYTE. The amdgcn ICE I reported still exists: conftest.c:16:1: internal compiler error: RTL check: expected code 'subreg', have 'reg' in ext_dce_process_uses, at ext-dce.cc:417 16 | } | ^

[V2] New pass for sign/zero extension elimination -- not ready for "final" review

2023-11-27 Thread Jeff Law
I've still got some comments from Richard S to work through, but some folks are trying to play with this and thus I want to get the fixes to date in their hands. Changes since V1: - Fix handling of CALL_INSN_FUNCTION_USAGE so we don't apply PATTERN to an EXPR_LIST. - Various comments and