https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
Richard Biener changed:
What|Removed |Added
Target Milestone|14.0|14.2
--- Comment #34 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #33 from Jakub Jelinek ---
That is still a hack, but guess can be acceptable for 14.22 and short term
trunk if the ARM maintainers approve it.
But, for GCC 15+, I think if the behavior is that when the predicate
constant/register is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #32 from Christophe Lyon ---
Created attachment 58110
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58110=edit
patch v2
Here is another patch proposal along the lines of what you suggest in #c24
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #31 from Jakub Jelinek ---
Seems most of the V4BI/V8BImode predicates are in UNSPECs, I think long term
turning them into just using there V16BImode might help.
Keep using V4BI/V8BImode for cases where we know it is all 0 or all 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #30 from Christophe Lyon ---
> ./cc1 -quiet -isystem include/ -march=armv8.1-m.main+mve -mfloat-abi=hard
> pr114801.c -mthumb -O2 -da
Thanks, for some reason -O2 had disappeared from my flags, it does ICE with it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #29 from Jakub Jelinek ---
With
--- a/gcc/config/arm/arm-mve-builtins.cc
+++ b/gcc/config/arm/arm-mve-builtins.cc
@@ -2100,7 +2100,22 @@ function_expander::add_input_operand (insn_code icode,
rtx x)
mode = GET_MODE (x);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #28 from Jakub Jelinek ---
#include
uint32x4_t test_9() {
return vdupq_m_n_u32(vdupq_n_u32(0x), 0, 0x);
}
./cc1 -quiet -isystem include/ -march=armv8.1-m.main+mve -mfloat-abi=hard
pr114801.c -mthumb -O2 -da
during
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #27 from Christophe Lyon ---
(In reply to Jakub Jelinek from comment #25)
>
> Indeed, it ICEs e.g. during CSE.
> Though, that also means it is just about luck, if something isn't a
> CONST_INT at expansion time but simplified into
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #26 from Christophe Lyon ---
Thanks for testing, my build is still in progress.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #25 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #24)
> Another short term (14.1 only) possibility would be to force_reg a CONST_INT
> operand into a register if it didn't have all bits the same (and hope
> combine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #24 from Jakub Jelinek ---
Another short term (14.1 only) possibility would be to force_reg a CONST_INT
operand into a register if it didn't have all bits the same (and hope combine
or whatever else won't simplify it again), i.e.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #23 from Jakub Jelinek ---
(In reply to Christophe Lyon from comment #22)
> Sure, that's what I'm worried about.
>
> So we can:
> - leave this as-is for gcc-14 (known bug)
>
> - commit what we discussed in #c15 #c16, (with an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #22 from Christophe Lyon ---
Sure, that's what I'm worried about.
So we can:
- leave this as-is for gcc-14 (known bug)
- commit what we discussed in #c15 #c16, (with an improved testcase as you
mentioned on the list,) thus at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #21 from Jakub Jelinek ---
I mean if you represent it incorrectly, there are very high changes that
simplify-rtx.cc will screw this up, because it certainly doesn't understand
what a MODE_VECTOR_BOOL mode with elements other than
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #20 from Jakub Jelinek ---
Pretending a boolean mode has non-boolean value is invalid RTL (or GIMPLE).
So, the rtx-vector-builder.cc change looks wrong to me.
If you want to handle the predicate elements with element values other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #19 from Christophe Lyon ---
So basically values such as 0x are not UB and we want to accept them.
I tested:
diff --git a/gcc/rtx-vector-builder.cc b/gcc/rtx-vector-builder.cc
index 9509d9fc453..f89aa717903 100644
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #18 from avieira at gcc dot gnu.org ---
Sorry to be clear, the 'here' in the last sentence refers to supporting masks
as 0x to control the writing of the output register as the ISA allows,
rather than interpret 0x and 0x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #16 from Christophe Lyon ---
Thanks for the suggestion, this works.
I've posted the patch + testcase:
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650086.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #15 from Jakub Jelinek ---
https://developer.arm.com/documentation/101028/0012/14--M-profile-Vector-Extension--MVE--intrinsics
suggests that it is a UB if all the bits for a single element aren't the same
(i.e. false is all 0s, true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #14 from Christophe Lyon ---
Created attachment 58050
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58050=edit
patch proposal
Here is the patch I propose.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #13 from Jakub Jelinek ---
(In reply to Christophe Lyon from comment #12)
> (In reply to Jakub Jelinek from comment #11)
> > So, tried this under the debugger. All VALID_MVE_PRED_MODE modes have the
> > same size, 2 bytes, so I'd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #12 from Christophe Lyon ---
(In reply to Jakub Jelinek from comment #11)
> So, tried this under the debugger. All VALID_MVE_PRED_MODE modes have the
> same size, 2 bytes, so I'd go with
> else if (VALID_MVE_PRED_MODE (mode))
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #11 from Jakub Jelinek ---
So, tried this under the debugger. All VALID_MVE_PRED_MODE modes have the same
size, 2 bytes, so I'd go with
else if (VALID_MVE_PRED_MODE (mode))
{
/* unsigned short arguments to functions get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #10 from Jakub Jelinek ---
(mode == HImode || mode == V16BImode) could be GET_MODE_SIZE (mode) == 2 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #9 from Jakub Jelinek ---
(In reply to Christophe Lyon from comment #7)
> This fails because down the call chain from lowpart_subreg, we reach
> gcc_unreachable in rtx_vector_builder::find_cached_value because m_mode ==
> V4BImode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #8 from Christophe Lyon ---
(In reply to Jakub Jelinek from comment #5)
> Guess the primary question is why there is the gen_lowpart call at all.
> Is it that normally the mode of x is already right due to the prototypes of
> the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #7 from Christophe Lyon ---
(In reply to Jakub Jelinek from comment #4)
> (In reply to Christophe Lyon from comment #3)
> > lowpart_subreg does not work either.
> >
> > If we put the predicates in a variable in the testcase, then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #6 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #5)
> So (completely untested):
> --- gcc/config/arm/arm-mve-builtins.cc.jj 2024-03-19 09:51:05.203631194
> +0100
> +++ gcc/config/arm/arm-mve-builtins.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #5 from Jakub Jelinek ---
Guess the primary question is why there is the gen_lowpart call at all.
Is it that normally the mode of x is already right due to the prototypes of the
builtins, with the exception that gcc likes to promote
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #4 from Jakub Jelinek ---
(In reply to Christophe Lyon from comment #3)
> lowpart_subreg does not work either.
>
> If we put the predicates in a variable in the testcase, then in
> function_expander::add_input_operand() x is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #3 from Christophe Lyon ---
lowpart_subreg does not work either.
If we put the predicates in a variable in the testcase, then in
function_expander::add_input_operand() x is already a (subreg/s/v:HI (reg:SI
116 [ _3 ]) 0) so taking
32 matches
Mail list logo
