https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105219
--- Comment #5 from Tamar Christina ---
OK, I think this is an alignment issue.
When using the thunderx cost model it needs to peel the loop for alignment in
order to vectorize and it looks the error is there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105219
--- Comment #4 from Tamar Christina ---
(In reply to Alex Coplan from comment #3)
> (In reply to Tamar Christina from comment #1)
> > Smaller reproducer getting rid of the loop nest and simplify the inner
> > condition.
>
> Hmm, I can't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105219
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105197
Tamar Christina changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105197
Tamar Christina changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105197
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104039
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105196
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104409
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104409
Tamar Christina changed:
What|Removed |Added
Summary|-march=armv8.6-a+ls64 |[12 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104049
Tamar Christina changed:
What|Removed |Added
Target Milestone|12.0|13.0
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105095
Tamar Christina changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105157
--- Comment #7 from Tamar Christina ---
(In reply to Richard Biener from comment #6)
> More to the point the cited rev. doesn't look like it should change anything
> for -mtune=generic. Maybe the "generic" config is always the last one on
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104049
--- Comment #15 from Tamar Christina ---
(In reply to rsand...@gcc.gnu.org from comment #14)
>
> So IMO we should fix RTL representation problem that Andrew pointed
> out in comment 7 as the P1 fix, then accept the other cases as a P2
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105095
Tamar Christina changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104049
--- Comment #13 from Tamar Christina ---
That said, I'll wait for Richard S to respond, but I don't think this is a P1
any longer, we know why it can't be done during reload and neither sequences
are really significantly better/worse.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104049
--- Comment #12 from Tamar Christina ---
(In reply to Jakub Jelinek from comment #10)
> Could we fix this up in postreload or later?
> (insn 35 18 21 2 (set (reg:SI 0 x0 [125])
> (reg:SI 32 v0 [117])) "pr104049.c":16:33 52
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104049
--- Comment #11 from Tamar Christina ---
(In reply to Jakub Jelinek from comment #9)
> Perhaps the r12-2288-g8695bf78dad1a42636 change wasn't a good idea?
I think it's still a good idea as it fixes a bigger problem (unneeded SIMD
partial
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105012
Bug ID: 105012
Summary: [12 Regression] wrf from SPECCPU2017 ICEs during LTO
linking
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104755
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104529
--- Comment #7 from Tamar Christina ---
(In reply to Jakub Jelinek from comment #6)
> I don't see the code mentioned in #c0 on x86_64, I see also loads and stores
> like on aarch64.
Yes, that was my mistake, I was accidentally comparing GCC 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104755
--- Comment #4 from Tamar Christina ---
Hmmm looks like it doesn't support vector comparisons
missed: not vectorized: relevant stmt not supported: _6 = _5 <= 255;
I'll probably just have to skip them on sparc*-* then.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104730
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104755
--- Comment #2 from Tamar Christina ---
Hmmm the tests are gated by vect_int which sparc declares to support but the
code didn't vectorize, so probably an unsupported operation somewhere..
Could you attach the output of -fdump-tree-vect-all?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104730
Tamar Christina changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102819
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104529
Tamar Christina changed:
What|Removed |Added
Summary|[missed optimization] |[12 Regression] inefficient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104529
--- Comment #2 from Tamar Christina ---
I don't quite see how this is a CSE problem,
There's only one of each constant and none of them are needed before the call.
unlike in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86892
You don't need
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104529
Bug ID: 104529
Summary: [missed optimization] inefficient codegen around
new/delete
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94294
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103641
--- Comment #34 from Tamar Christina ---
(In reply to Andrew Pinski from comment #33)
> (In reply to Tamar Christina from comment #32)
> > I'm not sure... I can't seem to get the same granularity level that Andrew
> > got... How did you get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103641
--- Comment #32 from Tamar Christina ---
>
> I suppose the slowness is still entirely within synth_mult?
I'm not sure... I can't seem to get the same granularity level that Andrew
got... How did you get that report Andrew?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103641
--- Comment #30 from Tamar Christina ---
No problem during nightlies. No real changes in other workloads in compile time
nor runtime.
can confirm no perf change for xxhash and compile time decreased from 8 to 1
sec.
tree vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104408
--- Comment #4 from Tamar Christina ---
(In reply to Richard Biener from comment #3)
> match.pd just does canonicalization here. SLP discovery could handle this
> in the existing swap operands or reassoc support but I guess the desire here
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104408
Tamar Christina changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104408
--- Comment #1 from Tamar Christina ---
In particular, the rewrite should probably be gated on the expression being
single use.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104405
--- Comment #4 from Tamar Christina ---
(In reply to Andrew Pinski from comment #2)
> The big question becomes now is really an issue in real world code or just a
> toy benchmark which is testing argument/return passing optimizations?
Can't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104406
--- Comment #2 from Tamar Christina ---
Yeah it looks like there's an overlap with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485 indeed, but that ticket
seems to be trying to address multiple things at once including an x86 costing
issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104408
Bug ID: 104408
Summary: SLP discovery fails due to -Ofast rewriting
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104406
Bug ID: 104406
Summary: SLP discovery doesn't use TWO_OPERAND nodes as seeds
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104405
Bug ID: 104405
Summary: Inefficient register allocation on complex arithmetic
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103641
--- Comment #29 from Tamar Christina ---
(In reply to Richard Biener from comment #28)
> I'm not removing the regression marker yet - can ARM folks please update the
> trunk numbers with a fully built compiler (w/o checking)?
Sure, I'll come
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102819
Tamar Christina changed:
What|Removed |Added
Summary|[11/12 Regression] |[11 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103169
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104049
--- Comment #8 from Tamar Christina ---
(In reply to Andrew Pinski from comment #7)
> Hmm,
> ;; _43 = .REDUC_PLUS (vect__7.11_47);
>
> (insn 23 22 24 (set (reg:V4SI 112)
> (unspec:V4SI [
> (reg:V4SI 103 [ vect__7.11 ])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104049
--- Comment #4 from Tamar Christina ---
(In reply to Vladimir Makarov from comment #3)
> (In reply to Richard Biener from comment #2)
> > We need to understand the issue at least.
>
> I think that it is not an RA problem.
>
> IRA assigns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104049
Bug ID: 104049
Summary: [12 Regression] vec_select to subreg lowering causes
superfluous moves
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103771
--- Comment #1 from Tamar Christina ---
Looks like the change causes the simpler conditional to be detected by the
vectorizer as a masked operation, which in principle makes sense:
note: vect_recog_mask_conversion_pattern: detected:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103741
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103741
--- Comment #4 from Tamar Christina ---
Patch missing a check on vec_mode, testing a fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103741
--- Comment #2 from Tamar Christina ---
AH!
unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set 1 canonical-type
0x7fdf17594738 precision:64 min max
pointer_to_this >
VNx2DI
size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103741
Tamar Christina changed:
What|Removed |Added
Last reconfirmed||2021-12-16
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78136
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
--- Comment #30 from Tamar Christina ---
(In reply to Martin Jambor from comment #29)
> (In reply to Tamar Christina from comment #23)
> > I wonder if we can get rid of the final magic parameter too, we run with
> > --param ipa-cp-unit-growth=80
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103734
Bug ID: 103734
Summary: IPA-CP opportunity for imagick in SPECCPU 2017
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103350
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
--- Comment #28 from Tamar Christina ---
(In reply to pthaugen from comment #19)
> I tried -fno-inline-functions-called-once and the patches on a Power9
> system. Following are the run times and spill counts (grep -c Spilling
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
--- Comment #27 from Tamar Christina ---
(In reply to hubicka from comment #26)
> > It's with LTO, I'll see if non-LTO has the same benefit. In terms of
> > code-size
> > it looks like it accounts for a 20% increase for binary size, but the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
--- Comment #25 from Tamar Christina ---
(In reply to hubicka from comment #24)
> > Awesome! thanks!
> >
> > I wonder if we can get rid of the final magic parameter too, we run with
> > --param ipa-cp-unit-growth=80 too which seems to have no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
--- Comment #23 from Tamar Christina ---
(In reply to Jan Hubicka from comment #20)
> With g:r12-5872-gf157c5362b4844f7676cae2aba81a4cf75bd68d5 we should no
> longer need -fno-inline-functions-called-once
Awesome! thanks!
I wonder if we can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103094
Tamar Christina changed:
What|Removed |Added
CC||jonathan.wright at arm dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103350
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103350
--- Comment #5 from Tamar Christina ---
*** Bug 103632 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103632
Tamar Christina changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103253
Tamar Christina changed:
What|Removed |Added
Priority|P1 |P3
Summary|[12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103523
Tamar Christina changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
--- Comment #17 from Tamar Christina ---
> On “CALL_FREQ grows much quicker than BB_FREQ”: for r104, the
> ALLOCNO_FREQ ought in principle to be fixed for a given loop iteration
> count. It shouldn't grow or shrink based on the value of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
--- Comment #15 from Tamar Christina ---
> That is, we're trading two memory accesses in the call branch
> (if we allocate R) against one memory access in both branches
> (if we spill R). As the call branch gets more likely,
> the cost of doing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
--- Comment #13 from Tamar Christina ---
Created attachment 51943
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51943=edit
0002-PATCH-2-2-GCC-reload-Don-t-move-if-the-next-BB-has-m.patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
--- Comment #12 from Tamar Christina ---
Created attachment 51942
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51942=edit
0001-PATCH-1-2-GCC-reload-Weigh-available-callee-saves-ba.patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
--- Comment #11 from Tamar Christina ---
(In reply to Jan Hubicka from comment #10)
> Thanks for looking into this. I was planning to try to contact Vladimir
> about the IRA behaviour here, but there was always something else to work
> with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103305
Tamar Christina changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103523
--- Comment #6 from Tamar Christina ---
Looks like the ICE is cause by a bug in `vectorizable_induction` not checking
for MULT_EXPR and PLUS_EXPR for the given type before it tries to emit them.
This then leads to veclower trying to lower the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103404
Tamar Christina changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103305
--- Comment #22 from Tamar Christina ---
Ok, great, Jonathan what do you want to do, do we need to revert the commit or
just close this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103547
Tamar Christina changed:
What|Removed |Added
CC|tamar.christina at arm dot com |
--- Comment #2 from Tamar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103547
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103479
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103523
--- Comment #1 from Tamar Christina ---
An additional ICE seen on a month old tree is
during GIMPLE pass: veclower2
zbuf.i: In function 'd':
zbuf.i:3:1: internal compiler error: in to_constant, at poly-int.h:504
0xbc9494 poly_int_pod<2u,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103523
Bug ID: 103523
Summary: [12 Regression] SVE float auto-vect float format
expand failure
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103479
--- Comment #3 from Tamar Christina ---
(In reply to seurer from comment #2)
> Created attachment 51907 [details]
> dec7 dump file
>
> Dump file attached
Got it, thanks, I'll fix it today, the regexp is too liberal in this case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103305
--- Comment #20 from Tamar Christina ---
Newlib ML thread https://sourceware.org/pipermail/newlib/2021/018706.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103479
--- Comment #1 from Tamar Christina ---
Could you post the dce7 dump file if you have it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
--- Comment #8 from Tamar Christina ---
>
> I wonder how the situation looks on AArch64?
The situation didn't improve, up until the end of stage-1 we were seeing a 6%
perf uplift from somewhere which seems to have gone away now (in a commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103404
--- Comment #5 from Tamar Christina ---
This is a somewhat latent bug in CSE where merge_equiv_classes assumes that all
entries into the equivalence table are unique but CSE makes no attempt to
enforce this constraint.
So inserting the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103417
--- Comment #5 from Tamar Christina ---
(In reply to Jakub Jelinek from comment #4)
> Created attachment 51870 [details]
> gcc12-pr103417.patch
>
> Untested fix. Handling GE in that simplification is clearly bogus, we
> should just fold it to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103404
Tamar Christina changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
--- Comment #23 from Tamar Christina ---
Thanks Aldy!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103311
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103330
Tamar Christina changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103330
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
--- Comment #18 from Tamar Christina ---
(In reply to Martin Liška from comment #17)
> > I don't mind closing this as invalid, however this isn't a known limitation,
> > it's a new limitation.
>
> Yes, it may be a new limitation or we may be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
--- Comment #16 from Tamar Christina ---
(In reply to Martin Liška from comment #14)
> > > Richi the configury bits you shared once upon a time had
> > > -fno-unsafe-math-optimizations for 500.perlbench. Are there known issues
> > > with
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103305
--- Comment #12 from Tamar Christina ---
Fixed on master, is this something we'd want to backport to active branches?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
--- Comment #11 from Tamar Christina ---
> > Richi the configury bits you shared once upon a time had
> > -fno-unsafe-math-optimizations for 500.perlbench. Are there known issues
> > with
> > this test for -ffast-math that we had
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103311
Tamar Christina changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103311
Tamar Christina changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
--- Comment #8 from Tamar Christina ---
(In reply to Aldy Hernandez from comment #7)
> Could someone post the relevant configury bits used for the ppc64le case.
>
> I used:
>
> runcpu --config=myconfig -a validate --iterations=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103305
--- Comment #10 from Tamar Christina ---
Oh yes, sorry, I kept saying the wrong name :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103305
--- Comment #8 from Tamar Christina ---
This seems to work, would you like me to submit the patch or will you do it
Jakup?
501 - 600 of 753 matches
Mail list logo
