On Mon, Apr 28, 2025 at 2:38 PM Richard Sandiford
wrote:
>
> native_decode_rtx handles integer modes by building up a wide_int
> and then converting it to an rtx. This patch splits out the
> wide_int part, so that callers who don't want an rtx can avoid
> creating garbage rtl.
>
> Bootstrapped &
native_decode_rtx handles integer modes by building up a wide_int
and then converting it to an rtx. This patch splits out the
wide_int part, so that callers who don't want an rtx can avoid
creating garbage rtl.
Bootstrapped & regression-tested on aarch64-linux-gnu. OK to install?
Richard
gcc/
Thanks Richard for all review comments. I have addressed the comments and sent
a v2 patch in a new email thread.
--
Thanks,
Pengfei
On Fri, Apr 25, 2025 at 8:53 PM Jeff Law wrote:
>
>
>
> On 4/25/25 9:25 PM, Andrew Pinski wrote:
> > This adds the simplification of a ZERO_EXTEND of an AND. This optimization
> > was already handled in combine via combine_simplify_rtx and the handling
> > there of compound_operations (ZERO_EXTRAC
On 4/25/25 9:25 PM, Andrew Pinski wrote:
This adds the simplification of a ZERO_EXTEND of an AND. This optimization
was already handled in combine via combine_simplify_rtx and the handling
there of compound_operations (ZERO_EXTRACT).
Build and tested for aarch64-linux-gnu.
Bootstrapped and te
On 4/25/25 9:29 AM, Richard Sandiford wrote:
@@ -4274,6 +4286,18 @@ simplify_context::simplify_binary_operation_1 (rtx_code
code,
return simplify_gen_binary (LSHIFTRT, mode, XEXP (op0, 0), XEXP
(op0, 1));
}
+ /* Convert (and (subreg (not X) off) Y) into (and (not
This adds the simplification of a ZERO_EXTEND of an AND. This optimization
was already handled in combine via combine_simplify_rtx and the handling
there of compound_operations (ZERO_EXTRACT).
Build and tested for aarch64-linux-gnu.
Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
Pengfei Li writes:
> This patch transforms RTL expressions of the form (subreg (not X) off)
> into (not (subreg X off)) when the subreg is an operand of a bitwise AND
> or OR. This transformation can expose opportunities to combine a NOT
> operation with the bitwise AND/OR.
>
> For example, it imp
This patch transforms RTL expressions of the form (subreg (not X) off)
into (not (subreg X off)) when the subreg is an operand of a bitwise AND
or OR. This transformation can expose opportunities to combine a NOT
operation with the bitwise AND/OR.
For example, it improves the codegen of the follow
On Tue, Apr 1, 2025 at 8:17 PM Richard Sandiford
wrote:
>
> This patch forestalls a regression in gcc.dg/rtl/x86_64/vector_eq.c
> with the patch for PR116398. The test wants:
>
> (cinsn 3 (set (reg:V4SI <0>) (const_vector:V4SI [(const_int 0)
> (const_int 0) (const_int 0) (const_int 0)])))
Jakub Jelinek writes:
> Hi!
>
> The gcc.dg/vect/pr113281-1.c test and many others ICE on riscv since
> presumably the r15-9238 change which allowed more cases of vector modes
> in simplify_const_relational_operation.
> In the testcase it is EQ of
> (popcount:SI (unspec:RVVMF32BI [
> (a
Hi!
The gcc.dg/vect/pr113281-1.c test and many others ICE on riscv since
presumably the r15-9238 change which allowed more cases of vector modes
in simplify_const_relational_operation.
In the testcase it is EQ of
(popcount:SI (unspec:RVVMF32BI [
(and:RVVMF32BI (const_vector:RVVMF32BI r
On Tue, Apr 01, 2025 at 01:16:32PM +0100, Richard Sandiford wrote:
> gcc/
> * simplify-rtx.cc (simplify_const_relational_operation): Generalize
> the constant checks in the fold-via-minus path to match the
> INTEGRAL_MODE_P condition.
LGTM.
Jakub
This patch forestalls a regression in gcc.dg/rtl/x86_64/vector_eq.c
with the patch for PR116398. The test wants:
(cinsn 3 (set (reg:V4SI <0>) (const_vector:V4SI [(const_int 0) (const_int
0) (const_int 0) (const_int 0)])))
(cinsn 5 (set (reg:V4SI <2>)
(eq:V4SI (reg
On Tue, Mar 04, 2025 at 09:26:07AM +, Richard Sandiford wrote:
> gcc/
> PR rtl-optimization/119002
> * simplify-rtx.cc
> (simplify_context::simplify_logical_relational_operation): Handle
> comparisons between CC values. If there is no evidence that the
> CC values
Richard Sandiford writes:
> Jakub Jelinek writes:
>> On Mon, Mar 03, 2025 at 01:46:20PM +, Richard Sandiford wrote:
>>> Jakub Jelinek writes:
>>> > On Mon, Mar 03, 2025 at 01:02:07PM +, Richard Sandiford wrote:
>>> >> ...how about something like this? Completely untested, and I haven't
Jakub Jelinek writes:
> On Mon, Mar 03, 2025 at 01:46:20PM +, Richard Sandiford wrote:
>> Jakub Jelinek writes:
>> > On Mon, Mar 03, 2025 at 01:02:07PM +, Richard Sandiford wrote:
>> >> ...how about something like this? Completely untested, and I haven't
>> >> thought about it much. Jus
On Mon, Mar 03, 2025 at 01:46:20PM +, Richard Sandiford wrote:
> Jakub Jelinek writes:
> > On Mon, Mar 03, 2025 at 01:02:07PM +, Richard Sandiford wrote:
> >> ...how about something like this? Completely untested, and I haven't
> >> thought about it much. Just didn't want to hold up the
Jakub Jelinek writes:
> On Mon, Mar 03, 2025 at 01:02:07PM +, Richard Sandiford wrote:
>> ...how about something like this? Completely untested, and I haven't
>> thought about it much. Just didn't want to hold up the discussion.
>
> Works for me.
>
> Just wonder if there is anything that wil
On Mon, Mar 03, 2025 at 01:02:07PM +, Richard Sandiford wrote:
> ...how about something like this? Completely untested, and I haven't
> thought about it much. Just didn't want to hold up the discussion.
Works for me.
Just wonder if there is anything that will actually verify that XEXP (op0,
Jakub Jelinek writes:
> On Mon, Mar 03, 2025 at 12:20:00PM +, Richard Sandiford wrote:
>> I think we should instead go back to punting on comparisons whose inputs
>> are CC modes, as we did (indirectly, via comparison_code_valid_for_mode)
>> before r15-6777. Sorry, I'd forgotten/hadn't though
On Mon, Mar 03, 2025 at 12:20:00PM +, Richard Sandiford wrote:
> I think we should instead go back to punting on comparisons whose inputs
> are CC modes, as we did (indirectly, via comparison_code_valid_for_mode)
> before r15-6777. Sorry, I'd forgotten/hadn't thought to exclude CC modes
> expl
Jakub Jelinek writes:
> Hi!
>
> The following testcase is miscompiled on powerpc64le-linux starting with
> r15-6777.
> That change has the if (HONOR_NANS (GET_MODE (XEXP (op0, 0 all = 15;
> lines which work fine if the comparisons use MODE_FLOAT or MODE_INT operands
> (or say MODE_VECTOR* etc.
For the record, this small change have been committed as part of another
larger one:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=bcc8dea6a45b46febfa76df6f5e3e5b13f3b4a58
On 19/02/2025 13:49, Jonathan Wakely wrote:
On Mon, 17 Feb 2025 at 11:59, François Dumont wrote:
On 16/02/2025 23:14,
Hi!
The following testcase is miscompiled on powerpc64le-linux starting with
r15-6777.
That change has the if (HONOR_NANS (GET_MODE (XEXP (op0, 0 all = 15;
lines which work fine if the comparisons use MODE_FLOAT or MODE_INT operands
(or say MODE_VECTOR* etc.). But on this testcase on ppc64le
On Mon, 17 Feb 2025 at 11:59, François Dumont wrote:
>
>
> On 16/02/2025 23:14, Jonathan Wakely wrote:
> > On Sun, 16 Feb 2025 at 21:15, François Dumont wrote:
> >> Hi
> >>
> >> A minor simplification.
> >>
> >> libstdc++: Simplify _Hashtable::_M_merge_multi
> >>
> >> When merging two hashtable i
On 16/02/2025 23:14, Jonathan Wakely wrote:
On Sun, 16 Feb 2025 at 21:15, François Dumont wrote:
Hi
A minor simplification.
libstdc++: Simplify _Hashtable::_M_merge_multi
When merging two hashtable instances of the same type we do not need
to go through _M_src_hash_code that also check for
On Sun, 16 Feb 2025 at 21:15, François Dumont wrote:
>
> Hi
>
> A minor simplification.
>
> libstdc++: Simplify _Hashtable::_M_merge_multi
>
> When merging two hashtable instances of the same type we do not need
> to go through _M_src_hash_code that also check for identical Hash functor
> type.
B
Hi
A minor simplification.
libstdc++: Simplify _Hashtable::_M_merge_multi
When merging two hashtable instances of the same type we do not need
to go through _M_src_hash_code that also check for identical Hash functor
type.
libstdc++-v3/ChangeLog:
* include/bits/hashtable.h
(_Hashtabl
On 12/30/24 8:16 AM, Richard Sandiford wrote:
Andrew Pinski writes:
On Fri, Dec 27, 2024 at 3:19 AM Robin Dapp wrote:
Thanks for the helpful suggestion. The attached v2 patch tries to implement
it.
It was bootstrapped and regtested on x86, aarch64 and Power 10.
Also regtested on rv64gcv_
Jeff Law writes:
> On 12/30/24 8:16 AM, Richard Sandiford wrote:
>
>>
>> The divisor is by definition 1. I think dropping it would make the
>> loop more obviously correct, since the same assumption is implicit in
>> the loop body.
> I'll likely pick this up as Robin is on PTO for the next ~10 da
On 12/30/24 8:16 AM, Richard Sandiford wrote:
The divisor is by definition 1. I think dropping it would make the
loop more obviously correct, since the same assumption is implicit in
the loop body.
I'll likely pick this up as Robin is on PTO for the next ~10 days. So
just to be 100% clear
Andrew Pinski writes:
> On Fri, Dec 27, 2024 at 3:19 AM Robin Dapp wrote:
>>
>> Thanks for the helpful suggestion. The attached v2 patch tries to implement
>> it.
>>
>> It was bootstrapped and regtested on x86, aarch64 and Power 10.
>> Also regtested on rv64gcv_zvl512b.
>>
>> Those are all littl
On Fri, Dec 27, 2024 at 3:19 AM Robin Dapp wrote:
>
> Thanks for the helpful suggestion. The attached v2 patch tries to implement
> it.
>
> It was bootstrapped and regtested on x86, aarch64 and Power 10.
> Also regtested on rv64gcv_zvl512b.
>
> Those are all little-endian (sub)targets, though, so
Thanks for the helpful suggestion. The attached v2 patch tries to implement
it.
It was bootstrapped and regtested on x86, aarch64 and Power 10.
Also regtested on rv64gcv_zvl512b.
Those are all little-endian (sub)targets, though, so it would certainly be
helpful if you could run additional aarch6
"Robin Dapp" writes:
> [PATCH] varasm: Use native_encode_rtx for constant vectors.
>
> optimize_constant_pool hashes vector masks by native_encode_rtx and
> merges identically hashed values in the constant pool. Afterwards the
> optimized values are written in output_constant_pool_2.
>
> However,
> from output_constant_pool_2 and make it defer to native_encode_rtx
> instead. That seems like the most direct way of avoiding mishaps.
>
> E.g. another way in which different routines could make different choices
> is in whether, for SVE's VNx8BI (say), they fill the upper bit of each
> 2-bit el
"Robin Dapp" writes:
>> "Robin Dapp" writes:
>>> But here I intended to just change the encoded value in memory and to
>>> prevent it from aliasing with other encoded values.
>>> In an actual instruction the values we "padded" (or that are beyond the
>>> vector length) are ignored. For the purpo
> "Robin Dapp" writes:
>> But here I intended to just change the encoded value in memory and to
>> prevent it from aliasing with other encoded values.
>> In an actual instruction the values we "padded" (or that are beyond the
>> vector length) are ignored. For the purpose of hashing a mask of
>>
"Robin Dapp" writes:
> But here I intended to just change the encoded value in memory and to
> prevent it from aliasing with other encoded values.
> In an actual instruction the values we "padded" (or that are beyond the
> vector length) are ignored. For the purpose of hashing a mask of
> "1010"
>> How does encoding work for SVE's small mask modes? I suppose
>>
>> unsigned int elt_bits = vector_element_size (GET_MODE_PRECISION (mode),
>> GET_MODE_NUNITS (mode));
>>
>> is != 1 but rather adjusted so a byte is filled?
>
> It's 1 for VNx1
"Robin Dapp" writes:
>> ...it's not clear to me that we should define the upper bits of the
>> byte to be zero. What would rely on that? Is it something that we'd
>> require for all loads and stores of such modes?
>
> Yes, I meant fewer than BITS_PER_UNIT bits in total. As opposed to SVE's
> "b
Gentle ping. Any guidance on how to continue here?
--
Regards
Robin
> Am 25.11.2024 um 15:36 schrieb Robin Dapp :
>
>
>>
>> ...it's not clear to me that we should define the upper bits of the
>> byte to be zero. What would rely on that? Is it something that we'd
>> require for all loads and stores of such modes?
Btw, we’ve been there on the tree level wit
> ...it's not clear to me that we should define the upper bits of the
> byte to be zero. What would rely on that? Is it something that we'd
> require for all loads and stores of such modes?
Yes, I meant fewer than BITS_PER_UNIT bits in total. As opposed to SVE's
"balanced" mask representation i
"Robin Dapp" writes:
> Hi,
>
> this came up when testing even/odd permutes on riscv
> (https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669181.html).
> I didn't yet continue with the patch but it's clear it
> exposes an issue with encoding vector masks.
>
> When we encode a vector mask with
Hi,
this came up when testing even/odd permutes on riscv
(https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669181.html).
I didn't yet continue with the patch but it's clear it
exposes an issue with encoding vector masks.
When we encode a vector mask with a constant number of elements
and f
On Wed, Oct 23, 2024 at 8:38 PM Jeff Law wrote:
>
>
>
> On 10/20/24 3:18 PM, Andrew Pinski wrote:
> > The gimple (and generic) levels have this optmization since
> > r12-2041-g7d6979197274a662da7bdc5.
> > It seems like a good idea to add a similar one to rtl just in case it is
> > not caught at
On 10/20/24 3:18 PM, Andrew Pinski wrote:
The gimple (and generic) levels have this optmization since
r12-2041-g7d6979197274a662da7bdc5.
It seems like a good idea to add a similar one to rtl just in case it is not
caught at the
gimple level.
Note the loop case in csel-neg-1.c is not handled
The gimple (and generic) levels have this optmization since
r12-2041-g7d6979197274a662da7bdc5.
It seems like a good idea to add a similar one to rtl just in case it is not
caught at the
gimple level.
Note the loop case in csel-neg-1.c is not handled at the gimple level (even
with phiopt turned
Tamar Christina writes:
> Hi All,
>
> The optimization added in r15-1047-g7876cde25cbd2f is using the wrong
> operaiton to check for uniform constant vectors.
>
> The Author intended to check that all the lanes in the vector are the same and
> so used CONST_VECTOR_DUPLICATE_P. However this only c
Hi All,
The optimization added in r15-1047-g7876cde25cbd2f is using the wrong
operaiton to check for uniform constant vectors.
The Author intended to check that all the lanes in the vector are the same and
so used CONST_VECTOR_DUPLICATE_P. However this only checks that the vector
is created from
Richard Biener writes:
> The following reduces the number of wide_ints built which show up
> in the profile for PR114855 as the largest remaining bit at -O1.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
Thanks.
The following reduces the number of wide_ints built which show up
in the profile for PR114855 as the largest remaining bit at -O1.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* range-op.cc (operator_rshift::op1_range): Use wi::mask instead
of shift and not.
---
g
On Wed, Jun 5, 2024 at 10:44 PM Jeff Law wrote:
>
>
>
> On 6/4/24 10:22 PM, liuhongt wrote:
> >> Can you add a testcase for this? I don't mind if it's x86 specific and
> >> does a bit of asm scanning.
> >>
> >> Also note that the context for this patch has changed, so it won't
> >> automatically
On 6/4/24 10:22 PM, liuhongt wrote:
Can you add a testcase for this? I don't mind if it's x86 specific and
does a bit of asm scanning.
Also note that the context for this patch has changed, so it won't
automatically apply. So be extra careful when updating so that it goes
into the right pla
> Can you add a testcase for this? I don't mind if it's x86 specific and
> does a bit of asm scanning.
>
> Also note that the context for this patch has changed, so it won't
> automatically apply. So be extra careful when updating so that it goes
> into the right place (all the more reason to hav
tion-0.C | 8
4 files changed, 16 insertions(+), 16 deletions(-)
Attached patch Okay?From b64524632e236b2476d5eced8315c2ba8bece315 Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Sun, 11 Feb 2024 09:26:20 +0000
Subject: [PATCH] Simplify \r handling
Simplify
On Wed, 31 Jan 2024, Jakub Jelinek wrote:
> Hi!
>
> When simplifying e.g. (float_truncate:SF (float_truncate:DF (reg:XF))
> or (float_truncate:SF (float_extend:XF (reg:DF)) etc. into
> (float_truncate:SF (reg:XF)) or (float_truncate:SF (reg:DF)) we call
> simplify_gen_unary with incorrect op_mode
Hi!
When simplifying e.g. (float_truncate:SF (float_truncate:DF (reg:XF))
or (float_truncate:SF (float_extend:XF (reg:DF)) etc. into
(float_truncate:SF (reg:XF)) or (float_truncate:SF (reg:DF)) we call
simplify_gen_unary with incorrect op_mode argument, it should be
the argument's mode, but we cal
On Mon, Dec 11, 2023 at 4:14 PM Richard Biener
wrote:
>
> On Mon, Dec 11, 2023 at 7:51 AM liuhongt wrote:
> >
> > > since you are looking at TYPE_PRECISION below you want
> > > VECTOR_INTIEGER_TYPE_P here as well? The alternative
> > > would be to compare TYPE_SIZE.
> > >
> > > Some of the check
On Mon, Dec 11, 2023 at 7:51 AM liuhongt wrote:
>
> > since you are looking at TYPE_PRECISION below you want
> > VECTOR_INTIEGER_TYPE_P here as well? The alternative
> > would be to compare TYPE_SIZE.
> >
> > Some of the checks feel redundant but are probably good for
> > documentation purposes.
> since you are looking at TYPE_PRECISION below you want
> VECTOR_INTIEGER_TYPE_P here as well? The alternative
> would be to compare TYPE_SIZE.
>
> Some of the checks feel redundant but are probably good for
> documentation purposes.
>
> OK with using VECTOR_INTIEGER_TYPE_P
Actually, the data typ
On Thu, Nov 16, 2023 at 11:49 AM liuhongt wrote:
>
> Update in V2:
> 1) Add some comments before the pattern.
> 2) Remove ? from view_convert.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> Ok for trunk?
>
> When I'm working on PR112443, I notice there's some misoptimizations:
> a
ping.
On Thu, Nov 16, 2023 at 6:49 PM liuhongt wrote:
>
> Update in V2:
> 1) Add some comments before the pattern.
> 2) Remove ? from view_convert.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> Ok for trunk?
>
> When I'm working on PR112443, I notice there's some misoptimization
Update in V2:
1) Add some comments before the pattern.
2) Remove ? from view_convert.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk?
When I'm working on PR112443, I notice there's some misoptimizations:
after we fold _mm{,256}_blendv_epi8/pd/ps into gimple, the backend
fa
On Fri, Nov 10, 2023 at 2:14 PM liuhongt wrote:
>
> When I'm working on PR112443, I notice there's some misoptimizations:
> after we fold _mm{,256}_blendv_epi8/pd/ps into gimple, the backend
> fails to combine it back to v{,p}blendv{v,ps,pd} since the pattern is
> too complicated, so I think maybe
On Fri, Nov 10, 2023 at 2:52 AM liuhongt wrote:
>
> When I'm working on PR112443, I notice there's some misoptimizations: after we
> fold _mm{,256}_blendv_epi8/pd/ps into gimple, the backend fails to combine it
> back to v{,p}blendv{v,ps,pd} since the pattern is too complicated, so I think
> maybe
When I'm working on PR112443, I notice there's some misoptimizations:
after we fold _mm{,256}_blendv_epi8/pd/ps into gimple, the backend
fails to combine it back to v{,p}blendv{v,ps,pd} since the pattern is
too complicated, so I think maybe we should hanlde it in the gimple
level.
The dump is like
On Fri, Nov 10, 2023 at 10:11 AM Andrew Pinski wrote:
>
> On Thu, Nov 9, 2023 at 5:52 PM liuhongt wrote:
> >
> > When I'm working on PR112443, I notice there's some misoptimizations: after
> > we
> > fold _mm{,256}_blendv_epi8/pd/ps into gimple, the backend fails to combine
> > it
> > back to v
On Thu, Nov 9, 2023 at 5:52 PM liuhongt wrote:
>
> When I'm working on PR112443, I notice there's some misoptimizations: after we
> fold _mm{,256}_blendv_epi8/pd/ps into gimple, the backend fails to combine it
> back to v{,p}blendv{v,ps,pd} since the pattern is too complicated, so I think
> maybe
When I'm working on PR112443, I notice there's some misoptimizations: after we
fold _mm{,256}_blendv_epi8/pd/ps into gimple, the backend fails to combine it
back to v{,p}blendv{v,ps,pd} since the pattern is too complicated, so I think
maybe we should hanlde it in the gimple level.
The dump is like
The current implementation returns
(_M_y & (__is_multiple_of_100 ? 15 : 3)) == 0;
where __is_multiple_of_100 is calculated using an obfuscated algorithm which
saves one ror instruction when compared to _M_y % 100 == 0 [1].
In leap years calculation, it's mathematically correct to replace the
d
On Thu, Sep 28, 2023 at 3:37 PM Richard Sandiford
wrote:
>
> c_readstr only operated on integer modes. It worked by reading
> the source string into an array of HOST_WIDE_INTs, converting
> that array into a wide_int, and from there to an rtx.
>
> It's simpler to do this by building a target memo
c_readstr only operated on integer modes. It worked by reading
the source string into an array of HOST_WIDE_INTs, converting
that array into a wide_int, and from there to an rtx.
It's simpler to do this by building a target memory image and
using native_decode_rtx to convert that memory image int
The following adds simplification of abs (copysign (x, y)) to abs (x).
Bootstrap & regtest in progress on x86_64-unknown-linux-gnu.
Richard.
* match.pd (abs (copysign (x, y)) -> abs (x)): New pattern.
* gcc.dg/fold-abs-6.c: New testcase.
---
gcc/match.pd |
When doing interleaving we perform code generation when visiting the
last store of a chain. We keep track of this via DR_GROUP_STORE_COUNT,
the following localizes this to the caller of vectorizable_store,
also avoing redundant non-processing of the other stores.
Bootstrapped and tested on x86_64
Richard Biener writes:
> On Wed, Jul 12, 2023 at 1:05 PM Uros Bizjak wrote:
>>
>> On Wed, Jul 12, 2023 at 12:58 PM Uros Bizjak wrote:
>> >
>> > On Wed, Jul 12, 2023 at 12:23 PM Richard Sandiford
>> > wrote:
>> > >
>> > > Richard Biener via Gcc-patches writes:
>> > > > On Mon, Jul 10, 2023 at 1
On Wed, Jul 12, 2023 at 1:05 PM Uros Bizjak wrote:
>
> On Wed, Jul 12, 2023 at 12:58 PM Uros Bizjak wrote:
> >
> > On Wed, Jul 12, 2023 at 12:23 PM Richard Sandiford
> > wrote:
> > >
> > > Richard Biener via Gcc-patches writes:
> > > > On Mon, Jul 10, 2023 at 1:01 PM Uros Bizjak wrote:
> > > >
On Wed, Jul 12, 2023 at 12:58 PM Uros Bizjak wrote:
>
> On Wed, Jul 12, 2023 at 12:23 PM Richard Sandiford
> wrote:
> >
> > Richard Biener via Gcc-patches writes:
> > > On Mon, Jul 10, 2023 at 1:01 PM Uros Bizjak wrote:
> > >>
> > >> On Mon, Jul 10, 2023 at 11:47 AM Richard Biener
> > >> wrote
On Wed, Jul 12, 2023 at 12:23 PM Richard Sandiford
wrote:
>
> Richard Biener via Gcc-patches writes:
> > On Mon, Jul 10, 2023 at 1:01 PM Uros Bizjak wrote:
> >>
> >> On Mon, Jul 10, 2023 at 11:47 AM Richard Biener
> >> wrote:
> >> >
> >> > On Mon, Jul 10, 2023 at 11:26 AM Uros Bizjak wrote:
>
Richard Biener via Gcc-patches writes:
> On Mon, Jul 10, 2023 at 1:01 PM Uros Bizjak wrote:
>>
>> On Mon, Jul 10, 2023 at 11:47 AM Richard Biener
>> wrote:
>> >
>> > On Mon, Jul 10, 2023 at 11:26 AM Uros Bizjak wrote:
>> > >
>> > > On Mon, Jul 10, 2023 at 11:17 AM Richard Biener
>> > > wrote:
On Mon, Jul 10, 2023 at 1:01 PM Uros Bizjak wrote:
>
> On Mon, Jul 10, 2023 at 11:47 AM Richard Biener
> wrote:
> >
> > On Mon, Jul 10, 2023 at 11:26 AM Uros Bizjak wrote:
> > >
> > > On Mon, Jul 10, 2023 at 11:17 AM Richard Biener
> > > wrote:
> > > >
> > > > On Sun, Jul 9, 2023 at 10:53 AM Ur
On Mon, Jul 10, 2023 at 11:47 AM Richard Biener
wrote:
>
> On Mon, Jul 10, 2023 at 11:26 AM Uros Bizjak wrote:
> >
> > On Mon, Jul 10, 2023 at 11:17 AM Richard Biener
> > wrote:
> > >
> > > On Sun, Jul 9, 2023 at 10:53 AM Uros Bizjak via Gcc-patches
> > > wrote:
> > > >
> > > > As shown in the
On Mon, Jul 10, 2023 at 11:26 AM Uros Bizjak wrote:
>
> On Mon, Jul 10, 2023 at 11:17 AM Richard Biener
> wrote:
> >
> > On Sun, Jul 9, 2023 at 10:53 AM Uros Bizjak via Gcc-patches
> > wrote:
> > >
> > > As shown in the PR, simplify_gen_subreg call in simplify_replace_fn_rtx:
> > >
> > > (gdb) l
On Mon, Jul 10, 2023 at 11:17 AM Richard Biener
wrote:
>
> On Sun, Jul 9, 2023 at 10:53 AM Uros Bizjak via Gcc-patches
> wrote:
> >
> > As shown in the PR, simplify_gen_subreg call in simplify_replace_fn_rtx:
> >
> > (gdb) list
> > 469 if (code == SUBREG)
> > 470 {
> > 471
On Sun, Jul 9, 2023 at 10:53 AM Uros Bizjak via Gcc-patches
wrote:
>
> As shown in the PR, simplify_gen_subreg call in simplify_replace_fn_rtx:
>
> (gdb) list
> 469 if (code == SUBREG)
> 470 {
> 471 op0 = simplify_replace_fn_rtx (SUBREG_REG (x),
> old_rtx, fn, d
As shown in the PR, simplify_gen_subreg call in simplify_replace_fn_rtx:
(gdb) list
469 if (code == SUBREG)
470 {
471 op0 = simplify_replace_fn_rtx (SUBREG_REG (x),
old_rtx, fn, data);
472 if (op0 == SUBREG_REG (x))
473 return x;
47
On 6/16/23 03:06, Kyrylo Tkachov via Gcc-patches wrote:
Hi all,
In the testcase for this patch we try to vec_concat the lowpart and highpart of
a vector, but the lowpart is expressed as a subreg.
simplify-rtx.cc does not recognise this and combine ends up trying to match:
Trying 7 -> 8:
Hi all,
In the testcase for this patch we try to vec_concat the lowpart and highpart of
a vector, but the lowpart is expressed as a subreg.
simplify-rtx.cc does not recognise this and combine ends up trying to match:
Trying 7 -> 8:
7: r93:V2SI=vec_select(r95:V4SI,parallel)
8: r97:V4SI=vec
Hi Richard,
> -Original Message-
> From: Richard Sandiford
> Sent: Friday, June 9, 2023 7:08 PM
> To: Kyrylo Tkachov via Gcc-patches
> Cc: Kyrylo Tkachov
> Subject: Re: [PATCH] simplify-rtx: Implement constant folding of
> SS_TRUNCATE, US_TRUNCATE
>
> Kyr
Kyrylo Tkachov via Gcc-patches writes:
> Hi all,
>
> This patch implements RTL constant-folding for the SS_TRUNCATE and
> US_TRUNCATE codes.
> The semantics are a clamping operation on the argument with the min and max
> of the narrow mode,
> followed by a truncation. The signedness of the clamp
On 6/8/23 08:56, Kyrylo Tkachov via Gcc-patches wrote:
Hi all,
This patch implements RTL constant-folding for the SS_TRUNCATE and US_TRUNCATE
codes.
The semantics are a clamping operation on the argument with the min and max of
the narrow mode,
followed by a truncation. The signedness of th
Hi all,
This patch implements RTL constant-folding for the SS_TRUNCATE and US_TRUNCATE
codes.
The semantics are a clamping operation on the argument with the min and max of
the narrow mode,
followed by a truncation. The signedness of the clamp and the min/max extrema
is derived from
the signedn
The following simplifies and outlines gimple_assign_load. In
particular it is not necessary to get at the base of the possibly
loaded expression but just handle the case of a single handled
component wrapping a non-memory operand.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
Committed attached patch.
On 02/03/2023 10:13, Richard Sandiford wrote:
"Andre Vieira (lists)" writes:
Hey both,
Sorry about that, don't know how I missed those. Just running a test on
that now and will commit when it's done. I assume the comment and 0 ->
byte change can be seen as obvious, e
"Andre Vieira (lists)" writes:
> Hey both,
>
> Sorry about that, don't know how I missed those. Just running a test on
> that now and will commit when it's done. I assume the comment and 0 ->
> byte change can be seen as obvious, especially since it was supposed to
> be in my original patch...
Hey both,
Sorry about that, don't know how I missed those. Just running a test on
that now and will commit when it's done. I assume the comment and 0 ->
byte change can be seen as obvious, especially since it was supposed to
be in my original patch...
On 27/02/2023 15:46, Richard Sandiford w
Uros Bizjak writes:
> On Fri, Feb 17, 2023 at 8:38 AM Richard Biener wrote:
>>
>> On Thu, 16 Feb 2023, Uros Bizjak wrote:
>>
>> > simplify_subreg can return VOIDmode const_int operand and will
>> > cause ICE in simplify_gen_subreg when this operand is passed to it.
>> >
>> > The patch prevents VO
On Fri, Feb 17, 2023 at 12:31 PM Richard Biener wrote:
>
> On Fri, 17 Feb 2023, Uros Bizjak wrote:
>
> > On Fri, Feb 17, 2023 at 8:38 AM Richard Biener wrote:
> > >
> > > On Thu, 16 Feb 2023, Uros Bizjak wrote:
> > >
> > > > simplify_subreg can return VOIDmode const_int operand and will
> > > > c
1 - 100 of 496 matches
Mail list logo
