https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120447
--- Comment #9 from Richard Sandiford ---
I think the ICE is caused by a bad interaction between the AArch64 optimisation
and r16-718, which added more checks for paradoxical subregs. The testcase
works if r16-718 is reverted.
I think the shou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120447
--- Comment #8 from Richard Sandiford ---
I think we've already got the right condition for partial modes:
/* If the predicate in operands[2] is a patterned SVE PTRUE predicate
with patterns VL1, VL2, VL4, VL8, or VL16 and at most the bo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120447
--- Comment #6 from Richard Sandiford ---
I think a paradoxical VNx4QI subreg of QI is logically ok, but I'd need to
think a bit more about what the exact conditions should be. I don't think we
should rush into an aarch64 workaround.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119610
Richard Sandiford changed:
What|Removed |Added
Known to work||12.4.1
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111901
--- Comment #14 from Richard Sandiford ---
ISTM that the problem is that cselib doesn't consider:
(clobber (mem:BLK (scratch)))
to be a read from memory (unlike note_uses, which gets this right). cselib
instead assumes that the SET_SRC of t
|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
CC||rsandifo at gcc dot gnu.org
--- Comment #3 from Richard Sandiford ---
Mine then.
: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
Target: amdgcn*-*-*
The following pattern is infinitely recursive. It looks like it should be
calling "vec_cmp..." r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117978
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120050
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119966
--- Comment #6 from Richard Sandiford ---
(In reply to Andrew Pinski from comment #4)
> validate_subreg allows the paradoxical subreg even in the case of hard
> register:
> ```
> /* Paradoxical subregs must have offset zero. */
> if (maybe_
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*-*-*
AAPCS64 defined __fp16 and __bf16 to map to the same fundamental data type: a
half-precision floating-point
||rsandifo at gcc dot gnu.org
Status|UNCONFIRMED |WAITING
Ever confirmed|0 |1
--- Comment #1 from Richard Sandiford ---
Removing the PTEST wouldn't be correct in isolation, since RDFFRS+B.LAST would
test the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96191
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113416
Bug 113416 depends on bug 101018, which changed state.
Bug 101018 Summary: ICE when enabling OpenMP on a simple loop with SVE
intrinsics (aarch64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101018
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101018
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119399
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118443
Bug 118443 depends on bug 119399, which changed state.
Bug 119399 Summary: [12 Backport] Overlap check in vectorized code may invoke UB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119399
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 116125, which changed state.
Bug 116125 Summary: [12 Regression] Does not fully checking for overlapping
memory regions with the vectorizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116125
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116125
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118501
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119133
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115258
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119399
Richard Sandiford changed:
What|Removed |Added
Summary|Overlap check in vectorized |[12/13/14 Backport] Overlap
|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #5 from Richard Sandiford ---
Mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119399
--- Comment #5 from Richard Sandiford ---
(In reply to rguent...@suse.de from comment #4)
> >, so for a 4-element
> > vector, the only problem cases are p==q+4, p==q+8 and p==q+12. That's
> > equivalent to testing whether the unsigned value p-(
|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #3 from Richard Sandiford ---
Taking for the pointer difference.
(In reply to Richard Biener from comment #2)
> Still the actual alias check looks prone to overflow issues since we do
> not distinguish before/after pla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119689
--- Comment #14 from Richard Sandiford ---
(In reply to Richard Biener from comment #13)
> diff --git a/gcc/lra-remat.cc b/gcc/lra-remat.cc
> index 2f3afffcf5b..5f823193aa7 100644
> --- a/gcc/lra-remat.cc
> +++ b/gcc/lra-remat.cc
> @@ -460,7 +46
|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #10 from Richard Sandiford ---
Mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104200
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116398
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116595
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97286
--- Comment #9 from Richard Sandiford ---
(In reply to ktkachov from comment #8)
> Richard, do you think this is something early-ra in aarch64 is well-placed
> to address? Or is there perhaps a realistic IRA solution?
I don't think the RAs can ha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97286
--- Comment #10 from Richard Sandiford ---
(In reply to Richard Sandiford from comment #9)
> … Or perhaps we
> could do the optimisation in gimple, so that there is only one loop-carried
> dependency coming into expand.
That is, replace:
[loc
|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #28 from Richard Sandiford ---
I'm back from holiday, so taking.
(In reply to Segher Boessenkool from comment #26)
> So, the one thing I really worry about a bit: will everything still work if
> we can lose some l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119495
--- Comment #2 from Richard Sandiford ---
(In reply to Filip Kastl from comment #0)
> So my understanding is that this slowdown isn't really that important.
> However, it seemed reasonable to at least notify Richard Sandiford about
> this in ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116398
--- Comment #23 from Richard Sandiford ---
(In reply to Segher Boessenkool from comment #22)
> (In reply to Richard Sandiford from comment #18)
> > but: the problem in PR101523 was that, after each
> > successful 2->2 attempt, distribute_links w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116398
--- Comment #20 from Richard Sandiford ---
(In reply to Richard Sandiford from comment #18)
> Still more than 0% of course, but nevertheless much less than before.
than before the fix for PR101523 went in, I mean.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116398
--- Comment #18 from Richard Sandiford ---
Created attachment 60754
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60754&action=edit
Proof of concept patch with hard-coded limit
I'd been reluctant to get involved in this for fear of creat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119287
--- Comment #4 from Richard Sandiford ---
(In reply to Jakub Jelinek from comment #3)
> tree_nop_conversion_p certainly doesn't imply the two types are compatible
> types.
> So, I think we should go with
> --- gcc/match.pd.jj 2025-03-13 14:05:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113965
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
CC||rsandifo at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed||2025-03-13
--- Comment #4 from Richard Sandiford ---
Mine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115248
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115248
Richard Sandiford changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116901
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118956
--- Comment #4 from Richard Sandiford ---
XFAILed for GCC 15, keeping open for the actual fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118976
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 116238, which changed state.
Bug 116238 Summary: [12 Regression] ICE building 526.blender_r on aarch64 SVE
after r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116238
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116238
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117045
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117045
--- Comment #8 from Richard Sandiford ---
Fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116564
--- Comment #7 from Richard Sandiford ---
(In reply to Alex Coplan from comment #6)
> So I'm testing the following to do this (which so far survives bootstrap on
> aarch64):
>
> diff --git a/gcc/df-problems.cc b/gcc/df-problems.cc
> index f3218
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119114
--- Comment #21 from Richard Sandiford ---
Perhaps I'm missing the point, but I don't think we should look at 1 vs -1 for
. has only a single bit. That bit is
interpreted as a sign bit for extension purposes, but that only matters when an
ext
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116901
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119174
--- Comment #13 from Richard Sandiford ---
(In reply to Jeffrey A. Law from comment #11)
> Andrew. You're missing the point. This scenario isn't the kind of thing
> that reload and LRA are supposed to fix. They fix constraint problems. ie,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119133
Richard Sandiford changed:
What|Removed |Added
Summary|[14/15 Regression] ICE: |[14 Regression] ICE:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116125
Richard Sandiford changed:
What|Removed |Added
Summary|[12/13/14/15 Regression]|[12/13/14 Regression] Does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119156
Richard Sandiford changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
-optimization
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
CC: tnfchris at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*-*-*
Tamar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116125
--- Comment #5 from Richard Sandiford ---
(In reply to Richard Biener from comment #3)
> We document
>
> class dr_with_seg_len
> {
> ...
> /* The minimum common alignment of DR's start address, SEG_LEN and
> ACCESS_SIZE. */
> unsign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119142
--- Comment #1 from Richard Sandiford ---
Sorry, I thought Honza had regression-tested it on x86, but I realise now that
I didn't confirm whether he had. I reverted the patch in
r15-7862-g2c6ab4c443ae3278.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118957
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118959
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117477
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #2 from Richard Sandiford ---
Mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118531
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118976
Richard Sandiford changed:
What|Removed |Added
Summary|[12/13/14/15 regression]|[12/13/14 regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119002
Richard Sandiford changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116125
Richard Sandiford changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118976
Richard Sandiford changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116604
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
Status: UNCONFIRMED
Keywords: missed-optimization, testsuite-fail
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118956
--- Comment #1 from Richard Sandiford ---
Created attachment 60541
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60541&action=edit
candidate patch
This patch changes the patterns so that they don't require a scratch register
post-reload.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118952
--- Comment #3 from Richard Sandiford ---
(In reply to ktkachov from comment #2)
> Thanks, yeah I don't see PR34678 getting generally resolved any time soon.
> Is there something we could do with these particular builtins to make them a
> strong
||a/show_bug.cgi?id=34678
CC||rsandifo at gcc dot gnu.org
--- Comment #1 from Richard Sandiford ---
I think this is essentially the same problem as PR34678.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116604
Richard Sandiford changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117978
--- Comment #5 from Richard Sandiford ---
(In reply to ktkachov from comment #4)
> Do we also need to guard this under TARGET_NON_STREAMING?
Hopefully it should work for all cases. LDR Q and STR Q are still available in
streaming mode.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118892
--- Comment #10 from Richard Sandiford ---
(In reply to Tamar Christina from comment #9)
> I swear that was something that was fixed. But in any case, the simplest
> fix is to force it into a reg again indeed.
>
> I'm slightly worried that thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118611
--- Comment #9 from Richard Sandiford ---
(In reply to Vladimir Makarov from comment #7)
> Unfortunately, although the patch solves the problem but it adds 2 x86-64
> failures of tests expecting smaller number of moves. It also adds 2
> failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108608
--- Comment #12 from Richard Sandiford ---
(In reply to fengfei.xi from comment #11)
> could you please explain under what specific circumstances this change might
> lead to slower performance?
> Also, is there a more complete fix or any plans f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118755
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118328
--- Comment #14 from Richard Sandiford ---
(In reply to Sam James from comment #13)
> The request here notwithstanding, bug report(s) with testcases for missed
> opportunities in ipa-ra would be welcome too.
Agreed, if we find any. But just in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117477
Richard Sandiford changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115673
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118429
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
||rsandifo at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #13 from Richard Sandiford ---
Mine
|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #12 from Richard Sandiford ---
Mine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117922
--- Comment #23 from Richard Sandiford ---
FWIW, running locally on x86 with fold_mem_offsets disabled (admittedly with
rtl checking), I see:
combiner : 0.91 ( 0%)21M ( 0%)
late combiner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117922
--- Comment #21 from Richard Sandiford ---
I should have said, but: another reason for suggesting rtl-ssa is that it is
usually self-updating. My long-term hope is that we'll be able to maintain it
between passes, when we have consecutive passe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117922
--- Comment #19 from Richard Sandiford ---
Mind if I take this and try converting it to rtl-ssa? I think that would be
more forward-looking, rather than adding more custom (dominator walk) code to
the pass itself. Also, the switch to rtl-ssa d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117202
Richard Sandiford changed:
What|Removed |Added
CC||juzhe.zhong at rivai dot ai,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117202
--- Comment #5 from Richard Sandiford ---
FWIW, gcc.target/riscv/rvv/autovec/struct/mask_struct_store_run-3.c seems to
produce similar VEC_PERM_EXPRs for SVE, but it works there.
The idea is that we're unpacking one vector of [16,16] chars into
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 117270, which changed state.
Bug 117270 Summary: [15 Regression] 9% exec time slowdown of 538.imagick_r on
aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117270
What|Removed |Adde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117270
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118638
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
|UNCONFIRMED
Assignee|rsandifo at gcc dot gnu.org|unassigned at gcc dot
gnu.org
--- Comment #9 from Richard Sandiford ---
Probably best if I unassign myself then, because I don't really see where the
wrong code is.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118650
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #7 from Richard Sandiford ---
diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index c0550acf6b2..06cd6e42355 100644
--- a/gcc/tree-vect-stmts.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118669
--- Comment #6 from Richard Sandiford ---
(In reply to rguent...@suse.de from comment #5)
> On Mon, 27 Jan 2025, rsandifo at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118669
> >
> > ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118669
--- Comment #4 from Richard Sandiford ---
Just to be sure I understand: is the PR simply about making the RTL
representation of the memory more correct? Or is it about generating different
code?
gcc dot gnu.org|unassigned at gcc dot
gnu.org
--- Comment #7 from Richard Sandiford ---
The problem seems to be in the modelling of the FRM register.
CALL_USED_REGISTERS says that the register is call-clobbered/caller-save, which
means:
(a) it is not treated as live on entry to the
1 - 100 of 1363 matches
Mail list logo
