https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117297
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=117248
--- Comment #2 from Richard Sandiford ---
Also, could you check whether g:9bd19ff515c95af71b29bc6e232785532afa6823 makes
a difference?
: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*-*-*
int f1(int x) { return x < 0 || x & 3; }
on aarch64 produces:
f1:
tbn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116550
--- Comment #12 from Richard Sandiford ---
(In reply to denisc from comment #4)
> Explanation.
> […]
Thanks for the great explanation! Based on that, the patch LGTM FWIW, although
Vlad should have the final say.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #389 from Richard Sandiford ---
(In reply to Oleg Endo from comment #304)
> (define_insn "block_lump_real"
> [(set (mem:BLK (match_operand:SI 2 "sfunc_arg0_reg" "=r,r"))
> (mem:BLK (match_operand:SI 3 "sfunc_arg1_reg" "=r,r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116629
Richard Sandiford changed:
What|Removed |Added
Known to work||15.0
Summary|[14/15 Regr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117045
--- Comment #3 from Richard Sandiford ---
Ah, yeah, the patch fixes that too. The easiest fix seemed to be to handle the
degenerate cases up-front rather than as part of constant folding.
I deliberately left off folding svwhilelt(INT_MAX, x) t
|1
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
Last reconfirmed||2024-10-09
--- Comment #1 from Richard Sandiford ---
I'll send a patch soon.
y: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*-*-*
#include
#include
svbool_t f() { return svwhilele_b8_s32(INT_MAX, INT_MAX); }
is folded to:
ptrue p0.b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109498
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116578
Bug 116578 depends on bug 116583, which changed state.
Bug 116583 Summary: vectorizable_slp_permutation cannot handle even/odd extract
from VLA vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116583
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116583
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116583
--- Comment #10 from Richard Sandiford ---
I have a proof-of-concept hack (far from submission quality). But it looks
like some cases will also require us to extend aarch64_evpc_reencode to handle
SVE modes, which is also worthwhile for its own
|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #9 from Richard Sandiford ---
Mine. Lets see if I can remember how this “vectoriser” thing works…
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116629
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=116583
--- Comment #7 from Richard Sandiford ---
...actually, they probably don't need to bijective. I suppose
[0, 0] for two-lane SLP is handled too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116583
--- Comment #6 from Richard Sandiford ---
Sorry for the slow response (here and in general). Been having to
spend my time on other things recently :(
I agree that this case is regular enough to handle for VLA, but it
seems to me like a separat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116326
--- Comment #8 from Richard Sandiford ---
(In reply to Georg-Johann Lay from comment #7)
> What about the following line in reload1.h:
>
> // Used during roload -> LRA transition because ELIMINABLE_REGS may depend
> // on command line options.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116326
--- Comment #6 from Richard Sandiford ---
(In reply to Georg-Johann Lay from comment #5)
> > But either way, I think we should start with the assumption that the entry
> > should be removed and make everything else work to that. Unfortunately t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116326
--- Comment #4 from Richard Sandiford ---
(In reply to Georg-Johann Lay from comment #3)
> It was due to problems with multi-reg frame-pointer. (AFAIR, using a
> hard-frame-poiner besides frame-poiner didn't resolve the issues.)
>
> My problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116326
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116516
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116481
--- Comment #10 from Richard Sandiford ---
(In reply to Richard Sandiford from comment #9)
> If the tag bit is dropped by going
> out of bounds, that's a feature, not a bug, and would happen equally for
> void*/char* arithmetic as for (u)intptr_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116481
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #3 from Richard Sandiford ---
Gah, mine then.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116254
Richard Sandiford changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116254
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116238
Richard Sandiford changed:
What|Removed |Added
Known to fail|15.0|14.2.1
Summary|[12/13/14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116413
--- Comment #17 from Richard Sandiford ---
Hmm, but if the ICE is coming from vregs then it doesn't sound like it's
related to LRA. vregs is the first RTL pass to run.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116413
--- Comment #14 from Richard Sandiford ---
Created attachment 58967
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58967&action=edit
Patch for the decompse_mem_address ICE
Thanks. Can you try the attached patch?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116413
--- Comment #11 from Richard Sandiford ---
I can't reproduce this with m68k-elf. Do you have any local changes beyond
making TARGET_LRA_P return true?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116321
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #5 from Richard Sandiford ---
Yeah, seems to be a latent bug in aarch64_hard_regno_caller_save_mode. A
brute-force reproducer is:
void foo();
typedef unsigned char v2qi __attribute__((vector_size(2)));
void f(v2qi *ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116413
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115683
--- Comment #8 from Richard Sandiford ---
(In reply to Uroš Bizjak from comment #7)
> Richi, maybe tree optimizers can perform their optimizations with
> vec_cmp{,u} and vcond_mask, and at the end provide the true coditional
> vector move (that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114603
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114607
Richard Sandiford changed:
What|Removed |Added
Known to work||12.4.1, 13.3.1, 14.1.0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115464
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113939
Bug 113939 depends on bug 116236, which changed state.
Bug 116236 Summary: [LRA] [M68K] ICE insn does not satisfy its constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116236
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116236
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116343
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116236
--- Comment #22 from Richard Sandiford ---
(In reply to Michael Matz from comment #21)
> (In reply to Richard Sandiford from comment #17)
> > > But if LRA needs to be extended for correctness, then, ... meh.
> > But this is how it's always worke
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116371
--- Comment #2 from Richard Sandiford ---
Fixed on trunk. I'll wait a bit before backporting.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116371
Richard Sandiford changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*-*-*
The intrinsics for PEXT are supposed to be called svpext_lane_cN and
svpext_lane_cN_x2, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116236
--- Comment #19 from Richard Sandiford ---
Of course, immediately after posting I realise it should be address_mode
instead of pointer_mode, but that shouldn't affect m68k.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116236
--- Comment #18 from Richard Sandiford ---
Created attachment 58927
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58927&action=edit
Candidate patch
Could you try the attached patch? It seems to fix the reduced testcase for me.
|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #17 from Richard Sandiford ---
(In reply to Michael Matz from comment #16)
> (In reply to Richard Sandiford from comment #15)
> > > Yes, I considered adding this handling of (zero_extend Rx) to LRA. I'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116236
--- Comment #15 from Richard Sandiford ---
(In reply to Michael Matz from comment #14)
> (In reply to Richard Sandiford from comment #13)
> > (In reply to Michael Matz from comment #12)
> > > That's why I struggle a bit, I lack the bigger pictur
|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #5 from Richard Sandiford ---
Argh, substituting into the REG_EQUAL note is causing INSN_CODE to be reset.
Testing a patch…
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116343
--- Comment #4 from Richard Sandiford ---
(In reply to Andrew Pinski from comment #3)
> Note I think late_combine 1 depends on DCE later on to delete the
> noop_move_p instructions but since -fno-dce was passed on the command line,
> it is not d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116312
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116236
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30920
--- Comment #8 from Richard Sandiford ---
The patch in comment 7 is just one step.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116145
Richard Sandiford changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116200
Richard Sandiford changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30920
Richard Sandiford changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116145
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116145
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=116145
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115881
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116109
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116136
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116100
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116044
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116058
Richard Sandiford changed:
What|Removed |Added
CC|richard.sandiford at arm dot com |rsandifo at gcc dot
gnu.org
|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
--- Comment #2 from Richard Sandiford ---
Gah, this part of the code is causing more than it's fair share of trouble…
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116009
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115969
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #6 from Richard Sandiford ---
Testing a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115406
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115991
--- Comment #9 from Richard Sandiford ---
(In reply to Andrew Pinski from comment #7)
> (In reply to Sam James from comment #6)
> > The ICE bisects to r15-1945-g9d20529d94b232. The ivopts issue needs to be
> > done still.
>
> Note this is basic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115969
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=115950
--- Comment #5 from Richard Sandiford ---
Alternatively, I suppose we could say that svcntp_bN(svptrue_bN(), pg) etc.
should be folded to svcntp_bN(pg, pg) in gimple/expand, and then make the
INCP/DECP wrappers only match the equal-predicate ver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115950
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115929
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115928
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115929
--- Comment #3 from Richard Sandiford ---
As it turned out, the two tests exposed different bugs. I've submitted a patch
for the other one and will close once that's resolved.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115901
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115891
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115901
Richard Sandiford changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
||2024-07-12
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
Status|UNCONFIRMED |ASSIGNED
--- Comment #3 from Richard Sandiford ---
Comes from:
trying to combine definition of r5 in:
1058: di:SI=ax:SI
into:
299
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115785
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115881
Richard Sandiford changed:
What|Removed |Added
Assignee|rsandifo at gcc dot gnu.org|unassigned at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115881
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=115782
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115785
--- Comment #2 from Richard Sandiford ---
The patch in #c1 is just part 1. Part 2 will fix the bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114531
--- Comment #20 from Richard Sandiford ---
(In reply to Jan Hubicka from comment #18)
> I am trying to understand how useful this is. I am basically worried
> about two things
> 1) we have other optimization passes that behave differently at -
|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
Ever confirmed|0 |1
Last reconfirmed||2024-07-05
|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #1 from Richard Sandiford ---
I'll take a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115629
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115677
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115677
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=115634
--- Comment #3 from Richard Sandiford ---
Yeah, I agree that sounds like the right fix. Specifically, I assume
s390_decompose_addrstyle_without_index, when doing:
if (op && GET_CODE (op) != REG)
return false;
should check whether the re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114531
--- Comment #17 from Richard Sandiford ---
I can see that it's useful to ask whether the current -O2 & -O3 inlining
heuristics are making the right trade-off. But I think that's really a
different issue from the one that is raised in the PR. (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115631
--- Comment #4 from Richard Sandiford ---
Created attachment 58513
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58513&action=edit
A patch for a bug seen on arm*-*-*
Also, could you check whether the attached patch makes any difference?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115631
--- Comment #3 from Richard Sandiford ---
I've now pushed a debug counter for late_combine. Sorry to ask, but could you
bisect on N in -fdbg-cnt=late_combine:N to see which transformation is causing
the problem?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115633
--- Comment #2 from Richard Sandiford ---
-flate-combine-instructions is supposed to be disabled by default for all
powerpc targets. Could you look at why that isn't the case for you?
1 - 100 of 1207 matches
Mail list logo
