On Tue, 27 May 2025, Thomas Schwinge wrote:
> Hi!
>
> On 2025-05-23T17:01:31+0200, Richard Biener wrote:
> > Am 23.05.2025 um 16:49 schrieb Thomas Schwinge :
> >> This fell out of me looking into PR119835. This doesn't resolve the
> >> underlying
> >> issue, but instead of failing GIMPLE sema
Hi!
On 2025-05-23T17:01:31+0200, Richard Biener wrote:
> Am 23.05.2025 um 16:49 schrieb Thomas Schwinge :
>> This fell out of me looking into PR119835. This doesn't resolve the
>> underlying
>> issue, but instead of failing GIMPLE semantics verification just by chance in
>> the 'GIMPLE pass: n
appens downstream when we violate this (an assert does not
qualify). ESP. When at the same time we allow the actual thing returned to be
a register (aka SSA name)
Richard
>PR middle-end/119835
>gcc/
>* tree-cfg.cc (verify_gimple_return): Verify 'GIMPLE_RETURN' vs.
bootstrap
and 'make check' (without offloading configured).
PR middle-end/119835
gcc/
* tree-cfg.cc (verify_gimple_return): Verify 'GIMPLE_RETURN' vs.
'RESULT_DECL' if 'aggregate_value_p'.
* gimplify.cc (gimplify_
Since genoutput has no information about hard register names we cannot
statically verify those names in constraints of the machine description.
Therefore, we have to do it at runtime. Although verification shouldn't
be too expensive, restrict it to checking builds. This should be
suffi
On Tue, Mar 11, 2025 at 04:56:32PM +0100, Jakub Jelinek wrote:
> On Fri, Feb 28, 2025 at 10:06:49AM +0100, Richard Biener wrote:
> > > I've done 3 x86_64-linux and i686-linux bootstraps/regtests, each time
> > > with the 3rd patch to gather statistics on number of successful ICF
> > > function
> >
REF. But yes, a FUNCTION_DECL or also a
LABEL_DECL directly appearing as part of a value should be invalid. Note
that even f.a should be invalid and detected. verify_types_in_gimple_reference
is the vehicle that's designed to verify what's a valid reference (those might
appear
st not catching this?
Because verify_gimple_assign_single does not check is_gimple_val. So
maybe this should moved into verify_gimple_assign_single instead of
where I placed it.
Thanks,
Andrew
>
> >
> > gcc/ChangeLog:
> >
> >PR middle-end/118796
> >* tree-
t; didn't translate the function name into the result decl in some cases.
>
> Bootstrapped and tested on x86_64_linux-gnu with no regressions.
Why is the is_gimple_val test not catching this?
>
> gcc/ChangeLog:
>
>PR middle-end/118796
>* tree-cfg.cc (verify_gimp
otstrapped and tested on x86_64_linux-gnu with no regressions.
gcc/ChangeLog:
PR middle-end/118796
* tree-cfg.cc (verify_gimple_assign): Verify the lhs is not
a function decl.
Signed-off-by: Andrew Pinski
---
gcc/tree-cfg.cc | 9 +
1 file changed, 9 insertions(+)
On Fri, Feb 28, 2025 at 10:06:49AM +0100, Richard Biener wrote:
> > I've done 3 x86_64-linux and i686-linux bootstraps/regtests, each time
> > with the 3rd patch to gather statistics on number of successful ICF function
> > merges, and once with no further patches, once with the first patch and
> >
SI, RDX and RCX registers are
> used to pass arguments in 64-bit mode. EAX, EDX and ECX registers are
> used to pass arguments in 32-bit mode. But there is no coverage in the
> GCC testsuite. Add tests to verify that argument registers are spilled
> properly.
>
> PR ta
pass arguments in 32-bit mode. But there is no coverage in the
GCC testsuite. Add tests to verify that argument registers are spilled
properly.
PR target/119171
* gcc.target/i386/pr119171-1.c: New test.
* gcc.target/i386/pr119171-2.c: Likewise.
Signed-off-by: H.J. Lu
o pass arguments in 32-bit
> >> mode. Add tests to verify that argument registers are spilled properly.
> >>
> >> PR target/119171
> >> * gcc.target/i386/pr119171-1.c: New test.
> >> * gcc.target/i386/pr119171-2.c: Likewise.
>
Uros Bizjak writes:
> On Sun, Mar 9, 2025 at 3:05 PM H.J. Lu wrote:
>>
>> RDI, RSI, RDX and RCX registers are used to pass arguments in 64-bit
>> mode. EAX, EDX and ECX registers are used to pass arguments in 32-bit
>> mode. Add tests to verify that argument reg
On Sun, Mar 9, 2025 at 3:05 PM H.J. Lu wrote:
>
> RDI, RSI, RDX and RCX registers are used to pass arguments in 64-bit
> mode. EAX, EDX and ECX registers are used to pass arguments in 32-bit
> mode. Add tests to verify that argument registers are spilled properly.
>
>
RDI, RSI, RDX and RCX registers are used to pass arguments in 64-bit
mode. EAX, EDX and ECX registers are used to pass arguments in 32-bit
mode. Add tests to verify that argument registers are spilled properly.
PR target/119171
* gcc.target/i386/pr119171-1.c: New test
On Fri, 28 Feb 2025, Jakub Jelinek wrote:
> Hi!
>
> The testcase in the following patches is miscompiled, because
> ICF only uses operand_equal_p to compare operands and when that
> sees an ADDR_EXPR, it turns on OEP_ADDRESS_OF mode which only cares
> about the exact value instead of checking the
Hi!
The testcase in the following patches is miscompiled, because
ICF only uses operand_equal_p to compare operands and when that
sees an ADDR_EXPR, it turns on OEP_ADDRESS_OF mode which only cares
about the exact value instead of checking the types etc.
Unfortunately, get_range_strlen/get_range_
The compiler emits code with init_priority(99) for -fvtable-verify=std
and that creates a section conflict with the uses of init_priority(99)
that I recently added to src/c++20/tzdb.cc.
Change tzdb.cc to use a different priority to avoid the conflict.
libstdc++-v3/ChangeLog:
PR c
p+12], edi
> callf(int)
> imuleax, DWORD PTR [rsp+12]
> add rsp, 24
> ret
>
> There's no call in if branch, it's not optimal to push rbx at the entry
> of the function, it can be sinked to else branch. When "jle .L2&quo
.L2" is not
taken, it can save one push instruction. Update pr111673.c to verify
that this optimization isn't turned off.
PR rtl-optimization/111673
* gcc.target/i386/pr111673.c: Verify that PUSH/POP can be
skipped.
--
H.J.
From 6606ec5573e724295bdceb572ddc2813f021709f Mon Sep 17
On 2025-01-09 12:56, Richard Earnshaw (lists) wrote:
On 27/12/2024 17:01, Torbjörn SVENSSON wrote:
Ok for trunk?
--
This change will enforce that the expected instructions are generated
per function rather than allowing some other function to use the
expected instructions.
gcc/testsuite/Ch
On 27/12/2024 17:01, Torbjörn SVENSSON wrote:
> Ok for trunk?
>
> --
>
> This change will enforce that the expected instructions are generated
> per function rather than allowing some other function to use the
> expected instructions.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/arm/armv
Ok for trunk?
--
This change will enforce that the expected instructions are generated
per function rather than allowing some other function to use the
expected instructions.
gcc/testsuite/ChangeLog:
* gcc.target/arm/armv8_2-fp16-conv-1.c: Convert
scan-assembler-times to check-f
Hi,
On Thu, Nov 07 2024, Aldy Hernandez wrote:
> Aldy Hernandez writes:
>
>> Martin Jambor writes:
>>
>>> Hi,
>>>
>>> Because the simplified way of extracting value ranges from functions
>>> does not look at scalar constants (as one of the versions had been
>>> doing before) but instead rely on
Symbolically execute potential CRC loops and check whether the loop
actually calculates CRC (uses LFSR matching).
Calculated CRC and created LFSR are compared on each iteration of the
potential CRC loop.
gcc/
* Makefile.in (OBJS): Add crc-verification.o.
* crc-verification.cc: New file.
Symbolically execute potential CRC loops and check whether the loop
actually calculates CRC (uses LFSR matching).
Calculated CRC and created LFSR are compared on each iteration of the
potential CRC loop.
gcc/
* Makefile.in (OBJS): Add crc-verification.o.
* crc-verification.cc: New file.
Aldy Hernandez writes:
> Martin Jambor writes:
>
>> Hi,
>>
>> Because the simplified way of extracting value ranges from functions
>> does not look at scalar constants (as one of the versions had been
>> doing before) but instead rely on the value range within the jump
>> function already captur
Martin Jambor writes:
> Hi,
>
> Because the simplified way of extracting value ranges from functions
> does not look at scalar constants (as one of the versions had been
> doing before) but instead rely on the value range within the jump
> function already capturing the constant, I have added a v
>
>
> On Tue, Nov 05 2024, Jan Hubicka wrote:
> >> 2024-11-04 Martin Jambor
> >>
> >>* ipa-cp.cc (ipa_check_const_jf_vr): New function.
> >>(ipa_value_range_from_jfunc): Call it when checking and when
> >>dealing with a constant jump function.
> >>(propagate_vr_across_jump_fun
> 2024-11-04 Martin Jambor
>
> * ipa-cp.cc (ipa_check_const_jf_vr): New function.
> (ipa_value_range_from_jfunc): Call it when checking and when
> dealing with a constant jump function.
> (propagate_vr_across_jump_function): Likewise.
OK
> + /* TODO: Non-nullness is
On Tue, Nov 05 2024, Jan Hubicka wrote:
>> 2024-11-04 Martin Jambor
>>
>> * ipa-cp.cc (ipa_check_const_jf_vr): New function.
>> (ipa_value_range_from_jfunc): Call it when checking and when
>> dealing with a constant jump function.
>> (propagate_vr_across_jump_function): L
Hi,
Because the simplified way of extracting value ranges from functions
does not look at scalar constants (as one of the versions had been
doing before) but instead rely on the value range within the jump
function already capturing the constant, I have added a verifier that
it is indeed so. Afte
Since genoutput has no information about hard register names we cannot
statically verify those names in constraints of the machine description.
Therefore, we have to do it at runtime. Although verification shouldn't
be too expensive, restrict it to checking builds. This should be
suffi
Symbolically execute potential CRC loops and check whether the loop
actually calculates CRC (uses LFSR matching).
Calculated CRC and created LFSR are compared on each iteration of the
potential CRC loop.
gcc/
* Makefile.in (OBJS): Add crc-verification.o.
* crc-verification.cc: New file.
On Sun, Sep 29, 2024 at 8:01 PM Jeff Law wrote:
>
>
>
> On 9/13/24 5:06 AM, Mariam Arutunian wrote:
> > Symbolically execute potential CRC loops and check whether the loop
> > actually calculates CRC (uses LFSR matching).
> > Calculated CRC and created LFSR are compared on each iteration of the
>
On 9/13/24 5:06 AM, Mariam Arutunian wrote:
Symbolically execute potential CRC loops and check whether the loop
actually calculates CRC (uses LFSR matching).
Calculated CRC and created LFSR are compared on each iteration of the
potential CRC loop.
gcc/
* Makefile.in (OBJS): Add crc
Since genoutput has no information about hard register names we cannot
statically verify those names in constraints of the machine description.
Therefore, we have to do it at runtime. Although verification shouldn't
be too expensive, restrict it to checking builds. This should be
suffi
Symbolically execute potential CRC loops and check whether the loop
actually calculates CRC (uses LFSR matching).
Calculated CRC and created LFSR are compared on each iteration of the
potential CRC loop.
gcc/
* Makefile.in (OBJS): Add crc-verification.o.
* crc-verification.cc: New file.
Since genoutput has no information about hard register names we cannot
statically verify those names in constraints of the machine description.
Therefore, we have to do it at runtime. Although verification shouldn't
be too expensive, restrict it to checking builds. This should be
suffi
On 2024-08-16 16:45, Jakub Jelinek wrote:
On Fri, Aug 16, 2024 at 03:51:01PM +0200, Torbjörn SVENSSON wrote:
gcc/testsuite/ChangeLog:
* g++.dg/warn/pr33738.C: Added -fno-short-enums.
* g++.dg/warn/pr33738-2.C: Duplicate g++.dg/warn/pr33738.C with
-fshort-enums and rem
On Fri, Aug 16, 2024 at 03:51:01PM +0200, Torbjörn SVENSSON wrote:
> gcc/testsuite/ChangeLog:
>
> * g++.dg/warn/pr33738.C: Added -fno-short-enums.
> * g++.dg/warn/pr33738-2.C: Duplicate g++.dg/warn/pr33738.C with
> -fshort-enums and removed xfail.
>
> Signed-off-by: Torbjörn SVE
me targets, like Cortex-M on arm-none-eabi, the -fshort-enums is
enabled by default. For these targets, the test case fails as
sizeof(Alpha) < sizeof(int).
To make the test case behave identical for targets that does enable
-fshort-enums and those that does not, add -fno-short-enums in the test
ca
ks in flight.
Jeff
commit fd536b8412d4dae42aa04739c06f99a915be6261
Author: Jeff Law
Date: Sun Jun 23 08:26:25 2024 -0600
[committed][RISC-V][PR target/114139] Verify we have a CONST_INT before
extracting INTVAL
Run-of-the-mill checking issue. We had something like (plus (reg) (reg))
Symbolically execute potential CRC loops and check whether the loop
actually calculates CRC (uses LFSR matching).
Calculated CRC and created LFSR are compared on each iteration of the
potential CRC loop.
gcc/
* Makefile.in (OBJS): Add crc-verification.o.
* crc-verification.cc: New file.
trunk.
R.
Kind regards,
Torbjörn
On 2024-05-02 12:50, Torbjörn SVENSSON wrote:
Add regression test to the existing zero/sign extend tests for CMSE to
verify that r0, r1, r2 and r3 are properly extended, not just r0.
boolCharShortEnumSecureFunc test is done using -O0 to ensure the
instructions a
would regress on a
>> release branch without having first regressed on trunk.
>>
>> R.
>>
>>> Kind regards,
>>> Torbjörn
>>>
>>> On 2024-05-02 12:50, Torbjörn SVENSSON wrote:
>>>> Add regression test to the existing zer
regression test to the existing zero/sign extend tests for CMSE to
verify that r0, r1, r2 and r3 are properly extended, not just r0.
boolCharShortEnumSecureFunc test is done using -O0 to ensure the
instructions are in a predictable order.
gcc/testsuite/ChangeLog:
* gcc.target/arm/cmse/exte
>> Add regression test to the existing zero/sign extend tests for CMSE to
>> verify that r0, r1, r2 and r3 are properly extended, not just r0.
>>
>> boolCharShortEnumSecureFunc test is done using -O0 to ensure the
>> instructions are in a predictable order.
>>
>
024-05-02 12:50, Torbjörn SVENSSON wrote:
Add regression test to the existing zero/sign extend tests for CMSE to
verify that r0, r1, r2 and r3 are properly extended, not just r0.
boolCharShortEnumSecureFunc test is done using -O0 to ensure the
instructions are in a predictable order.
gcc/test
xtend tests for CMSE to
verify that r0, r1, r2 and r3 are properly extended, not just r0.
boolCharShortEnumSecureFunc test is done using -O0 to ensure the
instructions are in a predictable order.
gcc/testsuite/ChangeLog:
* gcc.target/arm/cmse/extend-param.c: Add regression test. Add
zero/sign extend tests for CMSE to
verify that r0, r1, r2 and r3 are properly extended, not just r0.
boolCharShortEnumSecureFunc test is done using -O0 to ensure the
instructions are in a predictable order.
gcc/testsuite/ChangeLog:
* gcc.target/arm/cmse/extend-param.c: Add regression test
Add regression test to the existing zero/sign extend tests for CMSE to
verify that r0, r1, r2 and r3 are properly extended, not just r0.
boolCharShortEnumSecureFunc test is done using -O0 to ensure the
instructions are in a predictable order.
gcc/testsuite/ChangeLog:
* gcc.target/arm
On 30/04/2024 16:37, Torbjorn SVENSSON wrote:
>
>
> On 2024-04-30 17:11, Richard Earnshaw (lists) wrote:
>> On 27/04/2024 15:13, Torbjörn SVENSSON wrote:
>>> Add regression test to the existing zero/sign extend tests for CMSE to
>>> verify that r0, r1, r2 and r
On 2024-04-30 17:11, Richard Earnshaw (lists) wrote:
On 27/04/2024 15:13, Torbjörn SVENSSON wrote:
Add regression test to the existing zero/sign extend tests for CMSE to
verify that r0, r1, r2 and r3 are properly extended, not just r0.
Test is done using -O0 to ensure the instructions are
On 27/04/2024 15:13, Torbjörn SVENSSON wrote:
> Add regression test to the existing zero/sign extend tests for CMSE to
> verify that r0, r1, r2 and r3 are properly extended, not just r0.
>
> Test is done using -O0 to ensure the instructions are in a predictable
> order.
>
@@ -165,6 +165,19 @@ vrange_storage::set_vrange (const vrange &r)
}
else
gcc_unreachable ();
+
+ // Verify that reading back from the cache didn't drop bits.
+ if (flag_checking
+ // FIXME: Avoid checking frange, as it currently pessimizes some ranges:
+ //
+ // gfor
Add regression test to the existing zero/sign extend tests for CMSE to
verify that r0, r1, r2 and r3 are properly extended, not just r0.
Test is done using -O0 to ensure the instructions are in a predictable
order.
gcc/testsuite/ChangeLog:
* gcc.target/arm/cmse/extend-param.c: Add
The following adds missing verification of vector type compatibility
to recurrence vectorization.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/114464
* tree-vect-loop.cc (vectorizable_recurr): Verify the latch
vector type is compatible
On Wed, 24 Jan 2024, Jeff Law wrote:
> > Do we have consensus now to move forward with this change as posted? I'd
> > like to get these patches ticked off ASAP.
> I think it should move forward. I think having the RTL tests deals with
> Andrew's concern and the testcase adjustment has value as
On 1/24/24 04:26, Maciej W. Rozycki wrote:
On Tue, 16 Jan 2024, Maciej W. Rozycki wrote:
I don't have a strong opinion on this. I certainly see Andrew's point, but
it's also the case that if some work earlier in the RTL or gimple pipeline
comes along and compromises the test, then we'd see
On Tue, 16 Jan 2024, Maciej W. Rozycki wrote:
> > I don't have a strong opinion on this. I certainly see Andrew's point, but
> > it's also the case that if some work earlier in the RTL or gimple pipeline
> > comes along and compromises the test, then we'd see the failure and deal
> > with
> > it
On Tue, 16 Jan 2024, Jeff Law wrote:
> > It's not clear to me what you mean by an "RTL testcase", i.e. how you'd
> > see the testcase changed (or an additional one produced instead) and why,
> > please elaborate. Right now we verify that branches are ab
On 1/12/24 06:59, Maciej W. Rozycki wrote:
On Fri, 12 Jan 2024, Andrew Pinski wrote:
Verify that if-conversion succeeded through noce_try_store_flag_mask, as
per PR rtl-optimization/105314, tightening the test case and making it
explicit.
gcc/testsuite/
* gcc.target/riscv
On Fri, 12 Jan 2024, Andrew Pinski wrote:
> > Verify that if-conversion succeeded through noce_try_store_flag_mask, as
> > per PR rtl-optimization/105314, tightening the test case and making it
> > explicit.
> >
> > gcc/testsuite/
> > * gcc.t
On Thu, Jan 11, 2024 at 3:37 PM Maciej W. Rozycki wrote:
>
> Verify that if-conversion succeeded through noce_try_store_flag_mask, as
> per PR rtl-optimization/105314, tightening the test case and making it
> explicit.
>
> gcc/testsuite/
> * gcc.target/riscv
LGTM
On Fri, Jan 12, 2024 at 7:37 AM Maciej W. Rozycki wrote:
>
> Verify that if-conversion succeeded through noce_try_store_flag_mask, as
> per PR rtl-optimization/105314, tightening the test case and making it
> explicit.
>
> gcc/testsuite/
> * gcc.target/r
Verify that if-conversion succeeded through noce_try_store_flag_mask, as
per PR rtl-optimization/105314, tightening the test case and making it
explicit.
gcc/testsuite/
* gcc.target/riscv/pr105314.c: Scan the RTL "ce1" pass too.
---
gcc/testsuite/gcc.target/riscv/
Hi Jeff,
on 2023/12/21 04:30, Jeff Law wrote:
>
>
> On 12/15/23 01:52, Kewen.Lin wrote:
>> Hi,
>>
>> PR112995 exposed one issue in current try_replace_dest_reg
>> that the result rtx insn after replace_dest_with_reg_in_expr
>> is probably unable to match any constraints. Although there
>> are s
On 12/15/23 01:52, Kewen.Lin wrote:
Hi,
PR112995 exposed one issue in current try_replace_dest_reg
that the result rtx insn after replace_dest_with_reg_in_expr
is probably unable to match any constraints. Although there
are some checks on the changes onto dest or src of orig_insn,
none is pe
heduling2" } */
+
+/* Verify there is no ICE. */
+
+int a[10];
+int b(_Float128 e) {
+ int c;
+ _Float128 d;
+ c = e;
+ d = c;
+ d = a[c] + d;
+ return d;
+}
--
2.39.3
verify
Pushed to trunk as r14-1420-ge4c8f7024f02d8.
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/malloc-sarif-1.c: Add missing verify-sarif-file
directive.
* gcc.dg/analyzer/sarif-pr107366.c: Likewise.
---
gcc/testsuite/gcc.dg/analyzer/malloc-sarif-1.c | 2 ++
gcc/testsuite/gcc.dg
On 5/5/23 09:46, Michael Collison wrote:
While working on autovectorizing for the RISCV port I encountered an issue
where can_duplicate_and_interleave_p assumes that GET_MODE_NUNITS is a
evenly divisible by two. The RISC-V target has vector modes (e.g. VNx1DImode),
where GET_MODE_NUNITS is equ
While working on autovectorizing for the RISCV port I encountered an issue
where can_duplicate_and_interleave_p assumes that GET_MODE_NUNITS is a
evenly divisible by two. The RISC-V target has vector modes (e.g. VNx1DImode),
where GET_MODE_NUNITS is equal to one.
Tested on RISCV and x86_64-linux-g
Michael Collison writes:
> While working on autovectorizing for the RISCV port I encountered an issue
> where can_duplicate_and_interleave_p assumes that GET_MODE_NUNITS is a
> evenly divisible by two. The RISC-V target has vector modes (e.g. VNx1DImode),
> where GET_MODE_NUNITS is equal to one.
>
While working on autovectorizing for the RISCV port I encountered an issue
where can_duplicate_and_interleave_p assumes that GET_MODE_NUNITS is a
evenly divisible by two. The RISC-V target has vector modes (e.g. VNx1DImode),
where GET_MODE_NUNITS is equal to one.
Tested on RISCV and x86_64-linux-g
On 3/14/23 15:52, Michael Collison wrote:
While working on autovectorizing for the RISCV port I encountered an issue
where can_duplicate_and_interleave_p assumes that GET_MODE_NUNITS is a
evenly divisible by two. The RISC-V target has vector modes (e.g. VNx1DImode),
where GET_MODE_NUNITS is eq
writes:
> Yes, like kito said.
> We won't enable VNx1DImode in auto-vectorization so it's meaningless to fix
> it here.
> We dynamic adjust the minimum vector-length for different '-march' according
> to RVV ISA specification.
> So we strongly suggest that we should drop this fix.
I think the p
ener <mailto:richard.guent...@gmail.com>; Jeff Law
<mailto:jeffreya...@gmail.com>; Palmer Dabbelt
<mailto:pal...@dabbelt.com>
*CC:* Michael Collison <mailto:colli...@rivosinc.com>; gcc-patches
<mailto:gcc-patches@gcc.gnu.org>; 钟居哲 <mailto:juzhe.zh...
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-04-19 02:21
To: Richard Biener; Jeff Law; Palmer Dabbelt
CC: Michael Collison; gcc-patches; 钟居哲
Subject: Re: [PATCH v4 07/10] vect: Verify that GET_MODE_NUNITS is a multiple
of 2.
Few more background about RVV:
RISC-V has provide different V
On 4/17/23 10:38, Kevin Lee wrote:
This patch properly guards gcc_assert (multiple_p (m_full_nelts,
m_npatterns)) in vec_perm_indices indices (sel, 2, nelt) for VNx1 vectors.
Based on the feedback from Richard Biener and Richard Sandiford,
multiple_p has been used instead of maybe_lt to compa
Few more background about RVV:
RISC-V has provide different VLEN configuration by different ISA
extension like `zve32x`, `zve64x` and `v`
zve32x just guarantee the minimal VLEN is 32 bits,
zve64x guarantee the minimal VLEN is 64 bits,
and v guarantee the minimal VLEN is 128 bits,
Current status (
Wait, VNx1DImode can be really evaluate to just one element if
-march=rv64g_zve64x,
I thinks this should be just fixed on backend by this patch:
https://patchwork.ozlabs.org/project/gcc/patch/20230414014518.15458-1-juzhe.zh...@rivai.ai/
On Tue, Apr 18, 2023 at 2:12 PM Richard Biener via Gcc-patc
On Mon, Apr 17, 2023 at 8:42 PM Michael Collison wrote:
>
> While working on autovectorizing for the RISCV port I encountered an issue
> where can_duplicate_and_interleave_p assumes that GET_MODE_NUNITS is a
> evenly divisible by two. The RISC-V target has vector modes (e.g. VNx1DImode),
> where G
On Mon, Apr 17, 2023 at 6:40 PM Kevin Lee wrote:
>
> This patch properly guards gcc_assert (multiple_p (m_full_nelts,
> m_npatterns)) in vec_perm_indices indices (sel, 2, nelt) for VNx1 vectors.
>
> Based on the feedback from Richard Biener and Richard Sandiford,
> multiple_p has been used instead
While working on autovectorizing for the RISCV port I encountered an issue
where can_duplicate_and_interleave_p assumes that GET_MODE_NUNITS is a
evenly divisible by two. The RISC-V target has vector modes (e.g. VNx1DImode),
where GET_MODE_NUNITS is equal to one.
Tested on RISCV and x86_64-linux-g
This patch properly guards gcc_assert (multiple_p (m_full_nelts,
m_npatterns)) in vec_perm_indices indices (sel, 2, nelt) for VNx1 vectors.
Based on the feedback from Richard Biener and Richard Sandiford,
multiple_p has been used instead of maybe_lt to compare nelt with the
minimum size 2.
Boots
Thank you for the feedback Richard and Richard.
> Note the calls are guarded with
>
> && ! known_eq (TYPE_VECTOR_SUBPARTS (vectype), 1U)
Yes, I believe nelt.is_constant() wouldn't be necessary. I didn't realize
the call was guarded by this condition.
> But I think the better check for loca
Richard Biener via Gcc-patches writes:
> On Mon, Mar 27, 2023 at 6:02 PM Kevin Lee wrote:
>>
>> This patch is a proper fix to the previous patch
>> https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614463.html
>> vect_grouped_store_supported checks if the count is a power of 2, but
>> doesn't
On Mon, Mar 27, 2023 at 6:02 PM Kevin Lee wrote:
>
> This patch is a proper fix to the previous patch
> https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614463.html
> vect_grouped_store_supported checks if the count is a power of 2, but
> doesn't check the size of the GET_MODE_NUNITS.
> This s
May I ping this patch?
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614700.html
Any suggestions and comments would be appreciated. Thank you!
Sincerely,
Kevin Lee
Michael Collison writes:
> While working on autovectorizing for the RISCV port I encountered an issue
> where can_duplicate_and_interleave_p assumes that GET_MODE_NUNITS is a
> evenly divisible by two. The RISC-V target has vector modes (e.g. VNx1DImode),
> where GET_MODE_NUNITS is equal to one.
>
This patch is a proper fix to the previous patch
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614463.html
vect_grouped_store_supported checks if the count is a power of 2, but
doesn't check the size of the GET_MODE_NUNITS.
This should handle the riscv case where the mode is VNx1DI since t
This is a patch related to
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613977.html,
aiming for gcc14. Since the RISC-V target has vector modes (e.g. VNx1DImode)
with nelt smaller than 2, npat has to match with the nelt to create proper
vec_perm_indices.
I tested on x86_64-linux-gnu an
On 3/14/23 15:52, Michael Collison wrote:
While working on autovectorizing for the RISCV port I encountered an issue
where can_duplicate_and_interleave_p assumes that GET_MODE_NUNITS is a
evenly divisible by two. The RISC-V target has vector modes (e.g. VNx1DImode),
where GET_MODE_NUNITS is eq
While working on autovectorizing for the RISCV port I encountered an issue
where can_duplicate_and_interleave_p assumes that GET_MODE_NUNITS is a
evenly divisible by two. The RISC-V target has vector modes (e.g. VNx1DImode),
where GET_MODE_NUNITS is equal to one.
Tested on RISCV and x86_64-linux-g
ested on RISCV and x86_64-linux-gnu. Okay?
>
> 2023-03-09 Michael Collison
>
> * poly-int.h (exact_div_p): New function to
> verify that argument is a power of 2 poly_int.
> * tree-vect-slp.cc (can_duplicate_and_interleave_p):
> Check that GET_MO
Michael Collison
* poly-int.h (exact_div_p): New function to
verify that argument is a power of 2 poly_int.
* tree-vect-slp.cc (can_duplicate_and_interleave_p):
Check that GET_MODE_NUNITS is a power of 2.
---
gcc/poly-int.h | 17 +
gcc/tree
1 - 100 of 324 matches
Mail list logo
