https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101908
cuilili changed:
What|Removed |Added
CC||lili.cui at intel dot com
--- Comment #23 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101908
--- Comment #24 from cuilili ---
(In reply to cuilili from comment #23)
> (In reply to Richard Biener from comment #17)
> > I do wonder though how CLX is fine with such access pattern ;) (did you
> > test
> > with just -O2?)
>
Sorry, correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101908
--- Comment #28 from cuilili ---
(In reply to H.J. Lu from comment #25)
> Can this be mitigated by removing redundant load and store?
Yes, inlining say_sphere can remove redundant loads and stores, O3 does
inlining, but O2 is more sensitive to c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104723
--- Comment #3 from cuilili ---
(In reply to Hongtao.liu from comment #1)
> STF issue here?
Yes, Since "YMMWORD PTR [rsp-72]" across the cache line, it has STLF issue
here.
vmovdqu64 YMMWORD PTR [rsp-72], ymm31 --> store 32 bytes from [rsp-7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104723
--- Comment #9 from cuilili ---
(In reply to cuilili from comment #3)
> (In reply to Hongtao.liu from comment #1)
> > STF issue here?
>
correct comment #3
I used perf to collect the "ld_blocks.store_forward" event for those two test
cases, stl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104271
--- Comment #6 from cuilili ---
I created a patch to fix this regression. The patch is under performance
testing. Will sent it out later.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104271
--- Comment #7 from cuilili ---
Created attachment 52706
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52706&action=edit
Add a heuristic for eliminate redundant load and store in inline pass.
Hi Richard,
Could you help take a look? This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104271
--- Comment #9 from cuilili ---
Really appreciate for your reply, I debugged SRA pass with the small testcase
and found that SRA dose not handle this situation.
SRA cannot split callee's first parameter for "Do not decompose non-BLKmode
paramet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104723
--- Comment #11 from cuilili ---
(In reply to Jakub Jelinek from comment #10)
> And for the backend, the question is how big the penalty for the overlapping
> store is compared to doing multiple non-overlapping stores. Say for those
> 49 bytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105493
cuilili changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 105493, which changed state.
Bug 105493 Summary: [12/13 Regression] x86_64 538.imagick_r 6% regressions and
2% 525.x264_r regressions on Alder Lake after r12-7319-g90d693bdc9d718
https://gcc.gnu.org/bugzilla/show_bug.cgi?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104271
--- Comment #12 from cuilili ---
This regression caused by the store forwarding issue, we eliminate the
redundant two pairs of loads and stores which have store forwarding issue by
inlining.
This regression has been fixed by
https://gcc.gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105493
Bug ID: 105493
Summary: [12/13 Regression] x86_64 538.imagick_r 6% regressions
and 2% 525.x264_r regressions on Alder Lake after
r12-7319-g90d693bdc9d718
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105493
--- Comment #2 from cuilili ---
(In reply to Richard Biener from comment #1)
> Martin is currently re-benchmarking GCC 12 on AMD, so let's see if there's
> anything left on those.
AMD may not have this issue, Richard fixed AMD regression with t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110148
--- Comment #7 from cuilili ---
(In reply to Martin Jambor from comment #6)
> I believe this has been fixed?
Yes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110038
--- Comment #2 from cuilili ---
(In reply to Richard Biener from comment #1)
> Probably best to limit the values to reassoc-width by adding the
> appropriate IntegerRange attribute in params.opt
>
> IntegerRange(0, 256)
>
> maybe?
"rewrite_ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110038
--- Comment #5 from cuilili ---
(In reply to Martin Jambor from comment #4)
> So is this now fixed?
Yes, the attachment case has been fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104271
--- Comment #14 from cuilili ---
This regression has been fixed with the commit below and we can close this
ticket.
https://gcc.gnu.org/g:1b9a5cc9ec08e9f239dd2096edcc447b7a72f64a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110148
cuilili changed:
What|Removed |Added
CC||lili.cui at intel dot com
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110148
--- Comment #3 from cuilili ---
I reproduced S1244 regression on znver3.
Src code:
for (int i = 0; i < LEN_1D-1; i++)
{
a[i] = b[i] + c[i] * c[i] + b[i] * b[i] + c[i];
d[i] = a[i] + a[i+1];
}
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117192
--- Comment #14 from cuilili ---
(In reply to Uroš Bizjak from comment #12)
> Created attachment 59373 [details]
> Proposed patch
>
> Patch in testing.
Sorry, I made a mistake here, thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117838
Bug ID: 117838
Summary: IRA issues: The higher cost variable a is spilled for
the lower cost variable conflict_a in
improve_allocatuion()
Product: gcc
Version: 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120697
--- Comment #14 from cuilili ---
Created attachment 61659
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61659&action=edit
Update estcase for the patch.
Thanks for the reminder.
Added #c7 as a new testcase for the patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120697
--- Comment #10 from cuilili ---
Thanks Sam and Sergei,
I created a patch to remove this assertion. However, validating this patch
requires running many tests, and if all goes well, it will take 1-2 days to fix
this issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120697
--- Comment #15 from cuilili ---
(In reply to Sam James from comment #11)
> Thanks Lili. I am happy to test a patch (I am not sure if just that assert
> should go, or if it is that same assert in various places), or to just
> workaround it local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120697
--- Comment #12 from cuilili ---
Created attachment 61658
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61658&action=edit
0001-x86-Handle-fstack-clash-protection-for-shrink-wrap-s.patch
I have reproduced and solved this problem locally.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120741
--- Comment #5 from cuilili ---
(In reply to H.J. Lu from comment #3)
> (In reply to cuilili from comment #1)
> > Created attachment 61678 [details]
> > Fix-shrink-wrap-separate-ICE-for-mingw
> >
> > Hi Sergei,
> >
> > Thanks for reporting thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120741
--- Comment #1 from cuilili ---
Created attachment 61678
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61678&action=edit
Fix-shrink-wrap-separate-ICE-for-mingw
Hi Sergei,
Thanks for reporting this issue and providing a small testcase. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120818
--- Comment #1 from cuilili ---
Created attachment 61730
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61730&action=edit
fix patch
Hi Rainer,
Thank you for reporting this issue and giving the actual output. I have relaxed
the testcase c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120881
--- Comment #10 from cuilili ---
(In reply to Sam James from comment #9)
> Thanks both.
>
> H.J.'s is slightly less pessimising because it'll only affect functions
> where we actually emit a call, but I don't think it really matters here, and
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120881
--- Comment #2 from cuilili ---
I think it is an old bug, since shrink wrap, NOTE_INSN_PROLOGUE_END does not
represent the entry bb.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120881
--- Comment #6 from cuilili ---
Created attachment 61781
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61781&action=edit
Disable separate shrink wrapping for profile
How about changing it like this, like shrink wrap.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120818
--- Comment #4 from cuilili ---
Thank you all！
33 matches
Mail list logo
