https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
--- Comment #15 from rsandifo at gcc dot gnu.org
---
(In reply to Peter Bergner from comment #14)
> (In reply to Vladimir Makarov from comment #13)
> > Sorry, I have no good knowledge of decompose_address. The original author
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94072
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94201
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94072
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94254
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94254
--- Comment #4 from rsandifo at gcc dot gnu.org
---
The cycling comes from reloading:
(insn 7 6 8 2 (set (reg:SD 122 [ a32 ])
(mem/c:SD (reg/f:DI 120) [1 a32+0 S4 A32]))
"gcc/testsuite/gcc.target/powerpc/pr39902-2.c"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94254
--- Comment #5 from rsandifo at gcc dot gnu.org
---
(In reply to Zdenek Sojka from comment #1)
> I observe the same issue, and it breaks libgcc build for me:
What configure arguments do you use?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94254
--- Comment #7 from rsandifo at gcc dot gnu.org
---
Created attachment 48080
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48080&action=edit
Proof-of-concept hack to back up the point in comment 4
This hack shows what I mean in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94254
--- Comment #9 from rsandifo at gcc dot gnu.org
---
(In reply to Segher Boessenkool from comment #8)
> SFmode values are stored as DP IEEE float normally. There may be other
> cases as well, but this is the obvious one.
OK, thanks. Do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94261
--- Comment #5 from rsandifo at gcc dot gnu.org
---
(In reply to Richard Biener from comment #3)
> (In reply to Richard Biener from comment #2)
> > when placing gcc_unreachable () at the swapping place and most testcases
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94261
--- Comment #7 from rsandifo at gcc dot gnu.org
---
(In reply to Richard Biener from comment #6)
> (In reply to rsand...@gcc.gnu.org from comment #5)
> > (In reply to Richard Biener from comment #3)
> > > (In reply to R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94254
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Attachment #48080|0 |1
is obsolete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94254
--- Comment #13 from rsandifo at gcc dot gnu.org
---
(In reply to Segher Boessenkool from comment #12)
> That patch looks fine, thank you!
>
> Is there some way you can test if this works? Ideally in the testsuite
> of course, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94398
--- Comment #3 from rsandifo at gcc dot gnu.org
---
(In reply to Richard Biener from comment #2)
> But the ICE happens because the result from the function at transform time
> does not match that at analysis time.
>
> Richard?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94398
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92989
--- Comment #10 from rsandifo at gcc dot gnu.org
---
(In reply to Jakub Jelinek from comment #9)
> Richard, could you please have a look again?
OK, I'll try to get to this early next week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92989
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|REOPENED|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92989
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
URL||https://gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92989
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*-*-*
Compiling the following testcase with -O2 -march=armv8.2-a+sve:
typedef int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94605
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94606
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*-*-*
Compiling the following testcase with -O3 -march=armv8.2-a+sve
-msve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94606
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*-*-*
Compiling the following with -O -march=armv8.2-a+sve -msve-vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94668
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94668
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94668
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
Compiling this with -march=armv8.2-a+sve -msve-vector-bits=256 -O3:
#include
typedef float v8sf __attribute__((vector_size(32)));
svfloat32_t
f (svbool_t pg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94683
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94683
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
Compiling this with -march=armv8.2-a+sve -msve-vector-bits=256 -O3:
#include
typedef float v8sf __attribute__((vector_size(32)));
svfloat32_t
f (svbool_t pg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94700
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94700
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94678
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94712
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94727
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94727
--- Comment #5 from rsandifo at gcc dot gnu.org
---
Well, this is a bit of mess (surprise). We have a "<" comparison
between two booleans that are leaves of the SLP tree, so
vectorizable_comparison falls back on:
/* Invaria
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94727
--- Comment #7 from rsandifo at gcc dot gnu.org
---
(In reply to Richard Biener from comment #6)
> (In reply to rsand...@gcc.gnu.org from comment #5)
> >
> > However, we then defer to vect_get_slp_defs to get the actual op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94727
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94784
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94852
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|NEW
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94899
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Keywords||easyhack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94873
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94873
--- Comment #8 from rsandifo at gcc dot gnu.org
---
(In reply to Segher Boessenkool from comment #7)
> REG_EQ* is documented as only being allowed on insns that set only one
> register. If you want to change that, you'll have to
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
internal-fn.c:expand_mask_load_optab_fn uses expand_insn to emit the
load instruction, but doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94941
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2020-05-04
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94873
--- Comment #11 from rsandifo at gcc dot gnu.org
---
(In reply to Segher Boessenkool from comment #9)
> "clobber" is a red herring; it is impossible to make a REG_EQ* note for
> a clobber, a clobber does not set a new value (t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94941
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94873
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||ebotcazou at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92469
--- Comment #10 from rsandifo at gcc dot gnu.org
---
"jakub at gcc dot gnu.org" writes:
> --- Comment #9 from Jakub Jelinek ---
> Seems neither accessible_reg_set nor operand_reg_set can exclude frame,
> because
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94980
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94980
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*-*-*
Compiling this testcase with -march=armv8.2-a+sve
-msve-vector-bits=512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95105
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Target Milestone
-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95114
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92658
--- Comment #12 from rsandifo at gcc dot gnu.org
---
(In reply to rguent...@suse.de from comment #11)
> On Thu, 14 May 2020, ubizjak at gmail dot com wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92658
> >
> &
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94991
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95125
--- Comment #8 from rsandifo at gcc dot gnu.org
---
(In reply to Richard Biener from comment #7)
> (In reply to Uroš Bizjak from comment #6)
> > (In reply to Hongtao.liu from comment #5)
> > > (In reply to Uroš Bizj
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*-*-*
Compiling the following with -O2 -march=armv8-a:
typedef unsigned int uint_vec __attribute__((vector_size(32)));
uint_vec f1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95341
--- Comment #3 from rsandifo at gcc dot gnu.org
---
(In reply to ktkachov from comment #2)
> Interestingly, -msve-vector-bits gives good codegen for 128, 256, 512 but
> bad for 1024, 2048 and VLA code
That's because addition
: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*-*-*
Compiling the following with -O2 -march=armv8.2+sve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95361
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2020-05-27
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95459
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95459
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95523
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95523
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95528
--- Comment #6 from rsandifo at gcc dot gnu.org
---
(In reply to Jakub Jelinek from comment #4)
> I'd say the vectorizer/simplify_vector_constructor just shouldn't attempt to
> use these (e.g. vec_pack*, vec_unpack* optabs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95528
--- Comment #7 from rsandifo at gcc dot gnu.org
---
(In reply to rsand...@gcc.gnu.org from comment #6)
> In summary: from an AArch64 perspective, it's probably fine to
> check !VECTOR_MODE_P || VECTOR_BOOLEAN_TYPE_P. But given the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95254
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95528
--- Comment #9 from rsandifo at gcc dot gnu.org
---
(In reply to Jakub Jelinek from comment #8)
> Created attachment 48683 [details]
> gcc11-pr95528.patch
>
> Untested fix.
The VECTOR_TYPE_P condition should be redundant.
Look
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95523
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95570
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95694
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95199
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95726
--- Comment #2 from rsandifo at gcc dot gnu.org
---
(In reply to Jason Merrill from comment #1)
> Does the aarch64 port expect __Float32x4_t type to be considered equivalent
> to the GNU vector type or not? If so, w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95726
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95726
--- Comment #4 from rsandifo at gcc dot gnu.org
---
(In reply to Jakub Jelinek from comment #3)
> But if they mangle differently, then structural_comptypes shouldn't treat
> them as same types.
That certainly avoids the ICE, and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95726
--- Comment #8 from rsandifo at gcc dot gnu.org
---
Thanks for the pointers. Putting the mangled name in a target-specific
attribute (like we do for SVE) seems to fix it. It actually also keeps
the testcase in comment 4 “working”, which is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95805
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95674
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*-*-*
This meta-bug is to collect AArch64 performance improvements that
require or have a strong relationship
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95958
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95958
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Keywords||missed-optimization
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Blocks: 95958
Target Milestone: ---
Target: aarch64*-*-*
For:
#include
int32x4_t
foo (void)
{
int32_t array[] = { 0, 1
-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Blocks: 95958
Target Milestone: ---
Target: aarch64*-*-*
For
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95964
--- Comment #2 from rsandifo at gcc dot gnu.org
---
(In reply to Richard Biener from comment #1)
> You could use fnspec attributes to improve things but of course open-coding
> those as GIMPLE is preferable (last resort is to "fold
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Depends on: 95962
Blocks: 95958
Target Milestone: ---
Target: aarch64*-*-*
We generate poor code for the attached functions:
f1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95967
--- Comment #1 from rsandifo at gcc dot gnu.org
---
Created attachment 48802
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48802&action=edit
6 constructor functions
This time with attachment -- not sure what happened last time.
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Blocks: 95958
Target Milestone: ---
Target: aarch64
-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Blocks: 95958
Target Milestone: ---
Target: aarch64*-*-*
For
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92789
--- Comment #5 from rsandifo at gcc dot gnu.org
---
Keeping open since the problem also affects arm*-*-*. I don't
think we should change GCC 10 and earlier though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95726
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Target|aarch64-linux |aarch64*-*-* arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95961
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96075
--- Comment #4 from rsandifo at gcc dot gnu.org
---
(In reply to Richard Biener from comment #3)
> So we end up calling get_negative_load_store_type for this group which seems
> to only handle contiguous accesses but this one is single e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96091
--- Comment #3 from rsandifo at gcc dot gnu.org
---
(In reply to Richard Biener from comment #2)
> Why should we not have a VECTOR_CST of POLY_INT_CST elements? If
> POLY_INT_CST
> is not "constant" then it shouldn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95105
--- Comment #3 from rsandifo at gcc dot gnu.org
---
Fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95105
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
1 - 100 of 2099 matches
Mail list logo
