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
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
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
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
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.
> >
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) ==
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) ==
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
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
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)
> > +
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
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
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,
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
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
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
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
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
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
>
> 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
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 | }
| ^
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
22 matches
Mail list logo