https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110812
--- Comment #14 from Robin Dapp ---
I managed to have a look now but the whole builtin and LTO machinery is kind of
new to me.
As Andreas mentioned already the issue is that we do not register vector
builtins when the current target is !TARGET_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120459
Robin Dapp changed:
What|Removed |Added
CC||rdapp at gcc dot gnu.org
--- Comment #2 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120436
Robin Dapp changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110812
--- Comment #11 from Robin Dapp ---
Tried building highway to reproduce and hit another error in fre...
Do we have a minimal example for this issue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120378
--- Comment #3 from Robin Dapp ---
vnclipu is basically a scaling (narrowing), rounding shift with subsequent
"clip" i.e. saturation. Its input and output is unsigned, though, so for the
function above we first need to "clip" the negative value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120378
--- Comment #4 from Robin Dapp ---
Does it make sense to have the vmax/vmin/truncate pattern as a fallback for
other targets? On riscv it would save one predicated instruction.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120297
--- Comment #4 from Robin Dapp ---
I can reproduce this, but only with a qemu VLEN=128, VLEN >= 256 result in the
correct value of 234635118.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120378
Bug ID: 120378
Summary: Support narrowing clip idiom
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362
--- Comment #11 from Robin Dapp ---
> Yes. I am sure. And SPIKE and QEMU have no problem.
So vlre/vsre should execute despite a VILL in VTYPE? At first sight I don't
find any specifics in the vector spec.
qemu is not very pedantic in that res
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362
--- Comment #9 from Robin Dapp ---
> No. vlre should not depend on vtype. It should be hardware bug.
Are you sure about that? vmv1r also doesn't depend on a specific vtype, each
one is OK, but the vtype must at least be valid. So we get a SIG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362
--- Comment #6 from Robin Dapp ---
(In reply to Kito Cheng from comment #5)
> Oh, vsetvli/vill issue should only appeared for whole reg move not whole reg
> load store
On the Banana Pi I get a SIGILL for
int
main() {
asm volatile ("lui a5, 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362
--- Comment #4 from Robin Dapp ---
> I see, but when I changed to
>
> addia5,a5,912
>
> aka load from 0xdd390, the board still has the illegal insn. 0xdd390 is
> aligned for -O2 -march=rv64gcv -mrvv-vector-bits=zvl build, right?
Hmm, righ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362
--- Comment #1 from Robin Dapp ---
That's a misaligned vector load I suppose?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118950
Robin Dapp changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118950
--- Comment #13 from Robin Dapp ---
Going to push this to the 14 branch later today if the x86 testsuite shows no
regressions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120067
Robin Dapp changed:
What|Removed |Added
CC||rdapp at gcc dot gnu.org
--- Comment #4 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119577
--- Comment #3 from Robin Dapp ---
I manage to have a quick look at the code now. It looks like we force live
every induction and build slp instances for the IV increments.
I don't think adjusting the actual IV creation in vectorizable_inducti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119832
Robin Dapp changed:
What|Removed |Added
CC||rdapp at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119547
Robin Dapp changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116595
Robin Dapp changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119547
--- Comment #16 from Robin Dapp ---
> Yes, it is precisely the issue I have encountered in cvtScale8s64f (actually
> in cvt_64f). After the commit 34ae3a99, the default value of
> LOGICAL_OP_NON_SHORT_CIRCUIT has changed from 0 into 1, it will c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119672
--- Comment #8 from Robin Dapp ---
(In reply to Jakub Jelinek from comment #7)
> Thanks, I've posted it to gcc-patches in case some CI picks it up too:
> https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680408.html
Testing looked good on rv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119672
Robin Dapp changed:
What|Removed |Added
CC||rdapp at gcc dot gnu.org
--- Comment #6 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119547
--- Comment #15 from Robin Dapp ---
> Yes, it is precisely the issue I have encountered in cvtScale8s64f (actually
> in cvt_64f). After the commit 34ae3a99, the default value of
> LOGICAL_OP_NON_SHORT_CIRCUIT has changed from 0 into 1, it will c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119547
--- Comment #13 from Robin Dapp ---
Hmm, now I compiled with -O3 on top of --param logical-op-non-short-circuit=0
(which shouldn't actually be necessary or change anything as it's the default)
but there is a segmentation fault in
_ZN2cv12cpu_b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119547
--- Comment #12 from Robin Dapp ---
> I recompile the opencv application with current gcc(commit b6aafe9a5b), and
> it still reproduce this bug. Do you have apply the patch of step 3 which
> enable vector implement of cvt_64f function?
Yes, I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119547
--- Comment #10 from Robin Dapp ---
> 4. run
> ```
> export LD_LIBRARY_PATH=//lib
> ./opencv_test_core --gtest_filter="Core_ConvertScale/ElemWiseTest.accuracy/0"
> ```
[==] Running 1 test from 1 test case.
[--] Global test e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116595
--- Comment #7 from Robin Dapp ---
Ah, not a regression but just a checking assert, sorry.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116595
Robin Dapp changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119547
--- Comment #9 from Robin Dapp ---
> cmake --build cross-build/$BUILD_DIR-gcc --target opencv_test_core -j10
> ```
> 4. run
> ```
> export LD_LIBRARY_PATH=//lib
> ./opencv_test_core --gtest_filter="Core_ConvertScale/ElemWiseTest.accuracy/0"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119373
--- Comment #5 from Robin Dapp ---
> The analysis of SPEC2017's 510.parest_r shows that the topmost basic block
> is a tight loop (see attached reducer). Once vectorised, by unrolling and
> mutualising 4 instructions, AArch64 achieves a 22% redu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119572
Robin Dapp changed:
What|Removed |Added
Priority|P1 |P3
--- Comment #3 from Robin Dapp ---
(In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119577
Bug ID: 119577
Summary: RISC-V: Redundant vector IV roundtrip.
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119547
--- Comment #5 from Robin Dapp ---
Do you happen to have an excution test ready so I can have a look?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119361
--- Comment #4 from Robin Dapp ---
(In reply to Edwin Lu from comment #3)
> I'm not familiar enough with how the two modes interact with each other but
> I guess my question is, why do we have so many conversions between the two
> modes? What's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119361
--- Comment #2 from Robin Dapp ---
I looked into this some more and it points to a general deficiency in how we
handle the split between VLA and VLS modes.
With ...bits=zvl the RVVM1SI etc modes. become VLS modes. In turn, this means
that whene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119361
--- Comment #1 from Robin Dapp ---
The issue is due to:
_279 = BIT_FIELD_REF <_480, 64, 0>;
_330 = BIT_FIELD_REF <_480, 64, 64>;
_340 = BIT_FIELD_REF <_481, 64, 0>;
_350 = BIT_FIELD_REF <_481, 64, 64>;
Ideally they expand to simple sl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119114
Robin Dapp changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116398
Robin Dapp changed:
What|Removed |Added
CC||rdapp at gcc dot gnu.org
--- Comment #17 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117955
Robin Dapp changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119115
Robin Dapp changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119224
--- Comment #7 from Robin Dapp ---
> So this why you weren't seeing it but I'm confused about the rationale...
> I unpack above to following statements
>
> 1. -mno-vector-strict-align allows us to unroll - seems ok.
> 2. Otherwise (-mvector-str
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119224
--- Comment #4 from Robin Dapp ---
Ah, sorry, I always specify -mno-vector-strict-align by default. It's always
that option that allows us to unroll, otherwise unrolling will lead to
misaligned accesses. And -mtune=generic-ooo defaults to
-mno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119224
--- Comment #2 from Robin Dapp ---
I'm afraid that's due to scheduling (and not RA spilling). Of course there
shouldn't be any vector stores in this loop and with -fno-schedule-insns there
aren't any.
It's much worse for zvl128b even. While t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119114
--- Comment #22 from Robin Dapp ---
> Is that not happening? What value does _164 actually end up being?
>
> In other words, if the XOR is happening in GPRs, it doesn't matter whether
> the register holds 1 or -1 (or 3) for a true boolean. Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119114
--- Comment #20 from Robin Dapp ---
Hmm, so right now we return "1" or "0" when extracting from a mask, not "-1" or
"0" and that's what aarch64/SVE does as well. We cannot start returning a
sign-extended -1 all of a sudden.
There is an inconsi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119114
--- Comment #17 from Robin Dapp ---
> No you got it wrong.
> _121 will either be -1 or 0. _11 should be -1 or 0 too.
> So the question is what was the VEC_EXTRACT doing the right thing? Is it
> 0/-1 or 0/1?
I literally mentioned VEC_EXTRACT in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119114
--- Comment #11 from Robin Dapp ---
/* In GIMPLE, getting rid of 2 conversions for one new results
in smaller IL. */
(simplify
(convert (bitop:cs@2 (nop_convert:s @0) @1))
(if (GIMPLE
&& TREE_CODE (@1) != INTEGER_CST
&&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119114
--- Comment #10 from Robin Dapp ---
The test passes with -fno-vrp, so maybe the optimized tree isn't correct after
all?
Folding statement: _157 = _26 ? -1 : 0;
Matching expression match.pd:161, gimple-match-10.cc:33
Matching expression match.pd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119114
--- Comment #9 from Robin Dapp ---
I suspect the problem lies somewhere here:
_11 = .VEC_EXTRACT (mask__83.22_110, 0);
_23 = MEM[(short int *)&t + 20B];
_24 = _23 & _132;
_25 = _24 != 0;
_121 = () _25;
_157 = _11 ^ _121;
For
_121
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119114
--- Comment #6 from Robin Dapp ---
As convoluted (and redundant) as it looks but the optimized tree looks at least
correct to me. Maybe a backend issue?
But I don't see costing for what we emit in the vectorizer and I didn't yet
find where we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119114
--- Comment #4 from Robin Dapp ---
Very weird indeed. It looks like we're not even vectorizing? I mean, sure, we
use vector instructions but they are all broadcast from scalars?
(VMAT_INVARIANT) And in the end we extract the first element wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119115
--- Comment #5 from Robin Dapp ---
The problematic vsetvl is
vsetvli zero,a3,e16,m1,ta,ma
which was a
vsetvli a4,a3,e8,mf2,ta,ma
vsetvli t1,a3,e8,mf2,ta,ma
with the simple strategy.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119115
Robin Dapp changed:
What|Removed |Added
Last reconfirmed||2025-3-4
--- Comment #3 from Robin Dapp -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119115
--- Comment #2 from Robin Dapp ---
(In reply to Andrew Pinski from comment #1)
> Could this be another one of the vsetivli failures?
100% as I get "0" with --param=vsetvl-strategy=simple. But at first sight
unrelated to the previous ones. Wil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117955
Robin Dapp changed:
What|Removed |Added
CC||rdapp at gcc dot gnu.org
--- Comment #7 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118950
--- Comment #11 from Robin Dapp ---
I figured this particular problem on RISC-V won't be fixed on GCC 14 because we
don't have the zeroing of masked elements there. But you're referring to
backporting just this patch, right?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118595
--- Comment #2 from Robin Dapp ---
Hmm I'm not seeing those locally with -march=rv64gcv_zvl256b at least. Which
exact options were used to run the test suite? Or have those fails disappeared
in the meanwhile?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118950
Robin Dapp changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116773
Bug 116773 depends on bug 114516, which changed state.
Bug 114516 Summary: RISC-V: TSVC2 s315 has spill with dynamic lmul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114516
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114516
Robin Dapp changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114516
--- Comment #1 from Robin Dapp ---
The issue is that we're not considering pattern statements for costing. It's
rather straightforward to include those as well which would fix this PR.
I'm going to test a patch locally.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116686
Robin Dapp changed:
What|Removed |Added
CC||rdapp at gcc dot gnu.org
--- Comment #7 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118950
Robin Dapp changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118950
--- Comment #5 from Robin Dapp ---
Yeah, the original statement is recognized as a mask conversion pattern:
pr118950.c:9:21: note: vect_recog_mask_conversion_pattern: detected: _152 =
.MASK_LOAD (_230, 8B, _229, 0);
pr118950.c:9:21: note: m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118950
--- Comment #4 from Robin Dapp ---
It indeed appears is if we need zeroing of the loaded gather values but
bool type_mode_padding_p
= TYPE_PRECISION (scalar_type) < GET_MODE_PRECISION (GET_MODE_INNER
(mode));
is false.
The last of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116242
Bug 116242 depends on bug 115703, which changed state.
Bug 115703 Summary: [15 Regression] rv64gcv_zvl256b miscompile since
r15-1579-g792f97b44ff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115703
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115703
Robin Dapp changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116351
--- Comment #3 from Robin Dapp ---
I started with a fix here:
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671939.html
but, due to other priorities, dropped the ball :/ Feel free to pick up from
there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118832
--- Comment #8 from Robin Dapp ---
I think for vec_duplicate the idea is the same as for all the other splits -
keep it in simple shape so we can combine/fwprop etc. It also helps converting
e.g.
vmv.v.x v3,a3 vadd.vv v1, v2, v3
into
vad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118832
--- Comment #6 from Robin Dapp ---
Thanks for laying it out so clearly. Helps to put things into perspective.
I believe all our insn_and_split patterns already have can_create_pseudo_p in
their condition so shouldn't match after reload. Warra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118832
--- Comment #4 from Robin Dapp ---
>From a cursory look the following shifts might also be vulnerable:
(riscv-v.cc:1528)
else
{
/* { 1, 3, 2, 6, ... }. */
rtx tmp2 = gen_reg_rtx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118832
--- Comment #3 from Robin Dapp ---
The mechanism that introduces those unsplit instructions always seems to be via
reload. At some point we see a REG_EQUAL note with a const_vector. As we,
generally, can rematerialize constants we try to do th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115340
--- Comment #8 from Robin Dapp ---
I went with your approach and performed some local testing.
What I did is add another "unrolling type" in cunrolli, UL_FOR_GAPS, and split
it off as a third cunrolli invocation.
Right now it analyses the loop f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116242
Bug 116242 depends on bug 112853, which changed state.
Bug 112853 Summary: RISC-V: RVV: SPEC2017 525.x264 regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112853
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112853
Robin Dapp changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115703
--- Comment #4 from Robin Dapp ---
The problem appears to be
Fuse curr info since prev info compatible with it:
prev_info: VALID (insn 438, bb 2)
Demand fields: demand_ge_sew demand_non_zero_avl
SEW=32, VLMUL=m1, RATIO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115703
--- Comment #3 from Robin Dapp ---
For me this doesn't occur on the trunk anymore and I bisected the working
change to:
r15-3459-gcbea72b265e4c9
Author: Raphael Moreira Zinsly
Date: Wed Sep 4 17:21:24 2024 -0600
[PATCH 1/3] RISC-V: Impr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115703
--- Comment #2 from Robin Dapp ---
> I don't see anything wrong with this move on RTL. Maybe there is something
> wrong going on the pass which is emitting the vsetivli instructions.
Yes, indeed. With --param=vsetvl-strategy=simple the output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115458
--- Comment #12 from Robin Dapp ---
Some "findings" below but I don't have the feeling I'm much closer to anything
actionable.
At some point we're trying to split a live range of an RVVM8QI register (v16,
hard regno = 112) for the reload insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118734
Bug ID: 118734
Summary: RISC-V: Vector broadcast via strided load.
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: targe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115458
--- Comment #10 from Robin Dapp ---
It's also odd to see single-register spills for an LMUL8 register group, that
doesn't seem right.
(insn 174 169 180 2 (set (reg:RVVM1SF 247)
(reg:RVVM1SF 112 v16)) "pr115458.c":48:33 2749 {*movrvvm1sf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115458
--- Comment #9 from Robin Dapp ---
Bisecting further only leads to the commit that introduced the vector ABI.
Comparing the dumps with and without vector ABI is very tedious because a lot
of things differ.
It looks like we cannot create a relo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118019
--- Comment #15 from Robin Dapp ---
I think it's r15-2820-gab18785840d7b8.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118140
Robin Dapp changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118154
Robin Dapp changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118140
--- Comment #18 from Robin Dapp ---
Fixed on trunk. Guess we still need a backport.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118154
Robin Dapp changed:
What|Removed |Added
Component|tree-optimization |target
--- Comment #6 from Robin Dapp ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118154
--- Comment #5 from Robin Dapp ---
Confirmed, funnily only happens with a QEMU VLEN=128 and not with VLEN >= 256.
-fwrapv and -fno-strict-aliasing are not necessary for me.
Another "funny" thing:
vect__5.15_44 = .COND_LEN_MAX ({ -1, ... },
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115340
--- Comment #2 from Robin Dapp ---
> The stores are not considered "grouped" because they have gaps.
> To do better we'd have to improve the store dataref analysis to see
> that a vectorization factor of four would "close" the gaps, or more
> g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118154
--- Comment #3 from Robin Dapp ---
Uh, what a nice small test case ;) I'll have a look when I'm back mid next
week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118140
--- Comment #15 from Robin Dapp ---
(In reply to Andrew Pinski from comment #14)
> (In reply to Robin Dapp from comment #13)
> > The #if 0 shouldn't be necessary, right?
>
> Correct, it is the same testcase as comment #7 except the plain char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118140
--- Comment #13 from Robin Dapp ---
(In reply to Andrew Pinski from comment #11)
> I see sometimes we check the return value of maybe_resimplify_conditional_op
> and sometimes does not.
>
> E.g. in try_conditional_simplification we don't check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118140
--- Comment #9 from Robin Dapp ---
Already during ifcvt we do
Setting value number of _46 to 1 (changed)
Replaced _44 <= 1 with 1 in all uses of _46 = _44 <= 1;
Value numbering stmt = _41 = _3;
Setting value number of _41 to _3 (changed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118182
--- Comment #1 from Robin Dapp ---
We should probably always populate the initial value as the VL=0 only refers
(should refer) to the actual reduction?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118140
--- Comment #8 from Robin Dapp ---
The optimized tree looks good apart from 'd' and the return value :)
[local count: 76665171]:
e_lsm.8_12 = e;
_55 = .MASK_LEN_LOAD (&MEM <_Bool[17]> [(void *)&f + 4B], 8B, { -1, ... },
_54(D), 13, 0);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032
--- Comment #15 from Robin Dapp ---
> Based on earlier builds this file will take 2.5 to 3 hours to build (while
> all other cores are idle).
insn-attrtab.c doesn't consist of many functions so a split won't help. Given
that we have a number o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116242
Bug 116242 depends on bug 115995, which changed state.
Bug 115995 Summary: RISC-V: Can't generate portable RVV code for rv64gcv_zvl512b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115995
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115995
Robin Dapp changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032
--- Comment #12 from Robin Dapp ---
It looks like the insn-recog split didn't help here but maybe of of the
mentioned commits slowed down the compilation of insn-attrtab.c?
Has anybody made progress with narrowing down the problem?
1 - 100 of 412 matches
Mail list logo
