> Date: Fri, 1 Dec 2023 08:09:08 -0700
> From: Jeff Law
> On 11/30/23 18:08, Hans-Peter Nilsson wrote:
> >> Date: Sun, 19 Nov 2023 17:47:56 -0700
> >> From: Jeff Law
> >
> >> Locally we have had this enabled at -O1 and above to encourage testing,
> >> but I'm thinking that for the trunk
On 11/30/23 18:08, Hans-Peter Nilsson wrote:
Date: Sun, 19 Nov 2023 17:47:56 -0700
From: Jeff Law
Locally we have had this enabled at -O1 and above to encourage testing,
but I'm thinking that for the trunk enabling at -O2 and above is the
right thing to do.
Yes.
Thoughts, comments,
> Date: Sun, 19 Nov 2023 17:47:56 -0700
> From: Jeff Law
> Locally we have had this enabled at -O1 and above to encourage testing,
> but I'm thinking that for the trunk enabling at -O2 and above is the
> right thing to do.
Yes.
> Thoughts, comments, recommendations?
Sounds great!
It'd be
On 11/28/23 06:36, Joern Rennecke wrote:
On Mon, 27 Nov 2023 at 20:18, Jeff Law wrote:
On 11/27/23 13:03, Richard Sandiford wrote:
Joern Rennecke writes:
On 11/20/23 11:26, Richard Sandiford wrote:
+ /* ?!? What is the point of this adjustment to DST_MASK? */
+ if (code
On 11/29/23 10:37, Joern Rennecke wrote:
Why did you leave out MINUS from safe_for_live_propagation ?
As Jivan noted, mistake on my part.
jeff
We already noticed it and will roll back in V3
With the best regards
Jivan Hakobyan
> On 29 Nov 2023, at 21:37, Joern Rennecke wrote:
>
> Why did you leave out MINUS from safe_for_live_propagation ?
Why did you leave out MINUS from safe_for_live_propagation ?
On Tue, 28 Nov 2023 at 13:36, Joern Rennecke
wrote:
> For the saturating truncation operations, we have the high-to-low
propagation,
> but no low-to-high propagation, so that would be something separate to model.
P.S.:
For unsigned saturating truncation, the propagation from higher to
lower
On Mon, 27 Nov 2023 at 20:18, Jeff Law wrote:
>
>
>
> On 11/27/23 13:03, Richard Sandiford wrote:
> > Joern Rennecke writes:
> >> On 11/20/23 11:26, Richard Sandiford wrote:
> + /* ?!? What is the point of this adjustment to DST_MASK? */
> + if (code == PLUS || code ==
On Mon, 27 Nov 2023 at 20:03, Richard Sandiford
wrote:
>
> Joern Rennecke writes:
> > On 11/20/23 11:26, Richard Sandiford wrote:
> >>> + /* ?!? What is the point of this adjustment to DST_MASK? */
> >>> + if (code == PLUS || code == MINUS
> >>> + || code == MULT || code == ASHIFT)
On 11/27/23 11:19, Joern Rennecke wrote:
You are applying PATTERN to an INSN_LIST.
I know :-) That was the late change to clean up some of the horrific
control flow in the code.
jeff
On 11/27/23 10:36, Joern Rennecke wrote:
On 11/20/23 11:26, Richard Sandiford wrote:
+
+ mask = GET_MODE_MASK (GET_MODE (SUBREG_REG (x))) << bit;
+ if (!mask)
+ mask = -0x1ULL;
Not sure I follow this. What does the -0x1ULL constant indicate?
Also, isn't it the
On 11/27/23 13:03, Richard Sandiford wrote:
Joern Rennecke writes:
On 11/20/23 11:26, Richard Sandiford wrote:
+ /* ?!? What is the point of this adjustment to DST_MASK? */
+ if (code == PLUS || code == MINUS
+ || code == MULT || code == ASHIFT)
+ dst_mask
+ = dst_mask ?
[Sorry for the slow response]
Jeff Law writes:
> On 11/20/23 11:26, Richard Sandiford wrote:
>>
>>scalar_int_mode outer_mode;
>>if (!is_a (GET_MODE (x), _mode)
>>|| GET_MODE_BITSIZE (outer_mode) > 64)
>> continue;
> Wouldn't we also want to verify that the
Joern Rennecke writes:
> On 11/20/23 11:26, Richard Sandiford wrote:
>>> + /* ?!? What is the point of this adjustment to DST_MASK? */
>>> + if (code == PLUS || code == MINUS
>>> + || code == MULT || code == ASHIFT)
>>> + dst_mask
>>> + = dst_mask ? ((2ULL << floor_log2 (dst_mask))
You are applying PATTERN to an INSN_LIST.
diff --git a/gcc/ext-dce.cc b/gcc/ext-dce.cc
index 52032b50951..4523654538c 100644
--- a/gcc/ext-dce.cc
+++ b/gcc/ext-dce.cc
@@ -122,10 +122,9 @@ safe_for_live_propagation (rtx_code code)
optimziation phase during use handling will be. */
static
On 11/20/23 11:26, Richard Sandiford wrote:
>> + /* ?!? What is the point of this adjustment to DST_MASK? */
>> + if (code == PLUS || code == MINUS
>> + || code == MULT || code == ASHIFT)
>> + dst_mask
>> + = dst_mask ? ((2ULL << floor_log2 (dst_mask)) - 1) : 0;
>
> Yeah, sympathise
On 11/20/23 11:26, Richard Sandiford wrote:
>> +
>> + mask = GET_MODE_MASK (GET_MODE (SUBREG_REG (x))) << bit;
>> + if (!mask)
>> + mask = -0x1ULL;
>
> Not sure I follow this. What does the -0x1ULL constant indicate?
> Also, isn't it the mask of the outer register that
On 11/27/23 04:30, Andrew Stubbs wrote:
I tried this patch for AMD GCN. We have a similar problem with excess
extends, but also for vector modes. Each lane has a minimum 32 bits and
GCC's normal assumption is that vector registers have precisely the
number of bits they need, so the amdgcn
On 11/26/23 09:42, rep.dot@gmail.com wrote:
On 22 November 2023 23:23:41 CET, Jeff Law wrote:
On 11/20/23 11:56, Dimitar Dimitrov wrote:
On Sun, Nov 19, 2023 at 05:47:56PM -0700, Jeff Law wrote:
...
+ enum rtx_code xcode = GET_CODE (x);
+ if (xcode == SET)
+ {
+
I tried this patch for AMD GCN. We have a similar problem with excess
extends, but also for vector modes. Each lane has a minimum 32 bits and
GCC's normal assumption is that vector registers have precisely the
number of bits they need, so the amdgcn backend patterns have explicit
sign/zero
On 22 November 2023 23:23:41 CET, Jeff Law wrote:
>
>
>On 11/20/23 11:56, Dimitar Dimitrov wrote:
>> On Sun, Nov 19, 2023 at 05:47:56PM -0700, Jeff Law wrote:
>> ...
>>> + enum rtx_code xcode = GET_CODE (x);
>>> + if (xcode == SET)
>>> + {
>>> + const_rtx dst = SET_DEST (x);
>>>
On 11/20/23 11:56, Dimitar Dimitrov wrote:
On Sun, Nov 19, 2023 at 05:47:56PM -0700, Jeff Law wrote:
...
+/* Process uses in INSN. Set appropriate bits in LIVENOW for any chunks of
+ pseudos that become live, potentially filtering using bits from LIVE_TMP.
+
+ If MODIFIED is true, then
On 11/20/23 11:26, Richard Sandiford wrote:
+
+/* If we know the destination of CODE only uses some low bits
+ (say just the QI bits of an SI operation), then return true
+ if we can propagate the need for just the subset of bits
+ from the destination to the sources. */
+
+static
On Sun, Nov 19, 2023 at 05:47:56PM -0700, Jeff Law wrote:
...
> +/* Process uses in INSN. Set appropriate bits in LIVENOW for any chunks of
> + pseudos that become live, potentially filtering using bits from LIVE_TMP.
> +
> + If MODIFIED is true, then optimize sign/zero extensions to SUBREGs
Jeff Law writes:
> This is work originally started by Joern @ Embecosm.
>
> There's been a long standing sense that we're generating too many
> sign/zero extensions on the RISC-V port. REE is useful, but it's really
> focused on a relatively narrow part of the extension problem.
>
> What
On 11/19/23 20:32, Xi Ruoyao wrote:
On Sun, 2023-11-19 at 19:52 -0700, Jeff Law wrote:
/* snip */
Unfortunately, I get some ICE building stage 1 libgcc with this patch on
loongarch64-linux-gnu:
during RTL pass: ext_dce
../../../gcc/libgcc/libgcc2.c: In function ‘__absvdi2’:
On Sun, 2023-11-19 at 19:52 -0700, Jeff Law wrote:
/* snip */
>
> > Unfortunately, I get some ICE building stage 1 libgcc with this patch on
> > loongarch64-linux-gnu:
> >
> > during RTL pass: ext_dce
> > ../../../gcc/libgcc/libgcc2.c: In function ‘__absvdi2’:
> >
On Sun, 2023-11-19 at 19:51 -0700, Jeff Law wrote:
>
> On 11/19/23 18:22, Oleg Endo wrote:
> >
> > On Sun, 2023-11-19 at 17:47 -0700, Jeff Law wrote:
> > > This is work originally started by Joern @ Embecosm.
> > >
> > > There's been a long standing sense that we're generating too many
> > >
On 11/19/23 19:23, Xi Ruoyao wrote:
On Sun, 2023-11-19 at 17:47 -0700, Jeff Law wrote:
This is work originally started by Joern @ Embecosm.
There's been a long standing sense that we're generating too many
sign/zero extensions on the RISC-V port. REE is useful, but it's really
focused on a
On 11/19/23 18:22, Oleg Endo wrote:
On Sun, 2023-11-19 at 17:47 -0700, Jeff Law wrote:
This is work originally started by Joern @ Embecosm.
There's been a long standing sense that we're generating too many
sign/zero extensions on the RISC-V port. REE is useful, but it's really
focused on
On Sun, 2023-11-19 at 17:47 -0700, Jeff Law wrote:
> This is work originally started by Joern @ Embecosm.
>
> There's been a long standing sense that we're generating too many
> sign/zero extensions on the RISC-V port. REE is useful, but it's really
> focused on a relatively narrow part of the
On Sun, 2023-11-19 at 17:47 -0700, Jeff Law wrote:
> This is work originally started by Joern @ Embecosm.
>
> There's been a long standing sense that we're generating too many
> sign/zero extensions on the RISC-V port. REE is useful, but it's really
> focused on a relatively narrow part of
This is work originally started by Joern @ Embecosm.
There's been a long standing sense that we're generating too many
sign/zero extensions on the RISC-V port. REE is useful, but it's really
focused on a relatively narrow part of the extension problem.
What Joern's patch does is introduce a
34 matches
Mail list logo
