https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78664
--- Comment #2 from Vladimir Makarov ---
During register assignment subpass LRA processes hard regs from
ira_class_hard_regs. Under the same conditions (e.g. costs), LRA chooses regs
processed first.
ira_class_hard_regs contains regs according
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115013
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114415
--- Comment #11 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #10)
> Vlad, do you plan to backport this to 13.3? One of the 2 release blockers
> we have for that release.
Ok, I'll port it to releases/gcc-13 branch today.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114942
--- Comment #5 from Vladimir Makarov ---
I've started to work on this PR. I hope a patch will be ready on this or the
next week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114766
--- Comment #3 from Vladimir Makarov ---
(In reply to Tamar Christina from comment #2)
> (In reply to Vladimir Makarov from comment #1)
> > (In reply to Tamar Christina from comment #0)
> > > The documentation for ^ states:
> >
> > If it works
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114810
--- Comment #9 from Vladimir Makarov ---
(In reply to Uroš Bizjak from comment #7)
>
>
> Please note that the insn is defined as:
>
> (define_insn_and_split "*andn3_doubleword_bmi"
> [(set (match_operand: 0 "register_operand" "=,r,r")
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114810
--- Comment #6 from Vladimir Makarov ---
(In reply to Uroš Bizjak from comment #4)
> An interesting observation, when the insn is defined only with problematic
> alternative:
>
> (define_insn_and_split "*andn3_doubleword_bmi"
> [(set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114766
--- Comment #1 from Vladimir Makarov ---
(In reply to Tamar Christina from comment #0)
> The documentation for ^ states:
>
> "This constraint is analogous to ‘?’ but it disparages slightly the
> alternative only if the operand with the ‘^’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114415
--- Comment #5 from Vladimir Makarov ---
After some considerations, I've decided to fix it in the scheduler.
Such approach solves the problem for all targets and schedulers, still
permitting live range shrinkage (important for space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114415
--- Comment #4 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #3)
> BTW, with additional -mno-red-zone there is still movement of these insns,
>
The problem is even bigger. Live range splitting uses a standard insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114480
--- Comment #11 from Vladimir Makarov ---
My finding is that RA is not a problem for GCC speed with -O1 and up.
RA in -O0 does really consume a big portion of GCC compiler time. The
biggest part of RA in -O0 is actually spent in life
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99829
--- Comment #7 from Vladimir Makarov ---
(In reply to Maxim Kuvyrkov from comment #5)
>
> Where did you see the timeouts, btw?
Sorry, I glanced at c logs and interpreted it wrongly. Please, discard my
previous comment.
I should been more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99829
--- Comment #4 from Vladimir Makarov ---
(In reply to Maxim Kuvyrkov from comment #3)
> Hi Vladimir,
>
> Could you take a look at this, please?
I already got a message from automatic linaro tester yesterday about the new
test failures and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113790
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113510
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113048
--- Comment #7 from Vladimir Makarov ---
I believe this PR was recently fixed by
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=a729b6e002fe76208f33fdcdee49d6a310a1940e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113354
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112918
--- Comment #15 from Vladimir Makarov ---
The patch resulted in 2 new PRs about ICE when building glibc. So I reverted
the patch.
I'll continue work on this PR right after the winter holidays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113098
--- Comment #1 from Vladimir Makarov ---
The patch causing this was reverted.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113097
--- Comment #1 from Vladimir Makarov ---
Joseph, thank you for reporting this. I've just reverted the patch causing
this.
I'll use this report for work on another version of the patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112918
--- Comment #12 from Vladimir Makarov ---
I've been working on the PR this week. The problem for this case is in that
for subreg reload LRA can not narrow reg class more from ALL_REGS to
GENERAL_REGS and then to data regs or address regs.
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112875
--- Comment #3 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #2)
> Started with r14-53-g675b1a7f113adb1d737adaf78b4fd90be7a0ed1a
I reproduced it and hope to fix it today.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112445
--- Comment #7 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #5)
> Just changing
> --- i386.md.xx2023-11-22 09:47:22.746637132 +0100
> +++ i386.md 2023-11-22 20:38:07.216218697 +0100
> @@ -9984,7 +9984,7 @@
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111497
--- Comment #7 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #6)
> Is this backportable to release branches or too risky?
I don't think it is risky. LRA was designed to have unshared rtl. So copying
rtl in LRA is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112337
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109035
--- Comment #7 from Vladimir Makarov ---
For last 2 weeks I pushed several patches for better dealing with equivalences
in RA.
It seems the patches solves the current PR. I checked the test code generation
for loongarch and aarch64 and did
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112107
--- Comment #9 from Vladimir Makarov ---
(In reply to Sergei Trofimovich from comment #8)
> bootstrap with default options did not fail for me either. I had to use
> --enable-checking=release to trigger the failure. I wonder if it exposes the
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112107
--- Comment #7 from Vladimir Makarov ---
Sorry for inconvenience because of my patch.
I reproduced the bug with the reproducer using stage1 gcc although strangely
the standard bootstrap works ok for me on i686 debian.
I think I know the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111971
--- Comment #6 from Vladimir Makarov ---
(In reply to Andrew Pinski from comment #4)
> But r1 is the argument register.
It is even worse, r1 is a stack pointer. Still the compilation should not
finish by LRA failure.
I've just started to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111427
--- Comment #3 from Vladimir Makarov ---
Sorry for the inconvenience caused by the patch. I reverted this patch
yesterday.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111497
--- Comment #4 from Vladimir Makarov ---
I've reproduced the bug. The problem is in combination of splitting pseudo live
range and sharing rtl.
I hope to fix this on the next Monday or Tuesday.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111427
--- Comment #1 from Vladimir Makarov ---
Unfortunately, I did not manage to reproduce the bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111225
--- Comment #3 from Vladimir Makarov ---
I've reproduced the bug.
Just removing `else if (spilled_pseudo_p (op))` for CT_SPECIAL_MEMORY will
break a lot targets but this is right that this code is a reason for the bug.
I have ideas how to fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110093
--- Comment #5 from Vladimir Makarov ---
(In reply to Georg-Johann Lay from comment #4)
>
>
> So are you saying that the bug is actually in lower-subreg.cc ?
No. lower subreg is fine.
Sorry to be unclear. To generate a better code for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110093
--- Comment #3 from Vladimir Makarov ---
I worked on avr issues quite some time. And here is my findings.
Before IRA we have start of BB2:
;; lr in14 [r14] 15 [r15] 16 [r16] 17 [r17] 18 [r18] 19 [r19] 20 [r20]
21 [r21] 22 [r22] 23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110034
--- Comment #4 from Vladimir Makarov ---
Thank you for providing the test case.
To be honest I don't see why assigning to hr3 to r134 is better.
Currently we have the following assignments:
hr9->r134; hr3->r173; hr3->r124
and the related
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51041
--- Comment #4 from Vladimir Makarov ---
I believe it is the same problem as PR110215 which was solved recently by
checking whether pseudo values are used in the exception handler and the
handler does not return control flow back to the function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110215
--- Comment #4 from Vladimir Makarov ---
(In reply to Richard Biener from comment #3)
>
>
> We don't have any pass after reload that would perform loop invatiant motion,
> I'm not sure how this situation is handled in general in RA - is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109541
--- Comment #16 from Vladimir Makarov ---
Sam, thank you for your help. I've reproduced the problem on your machine.
The fix most probably will be ready this week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108703
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109541
--- Comment #9 from Vladimir Makarov ---
(In reply to Eric Botcazou from comment #7)
> The problem is that LRA assigns a floating-point register to the PIC
> pseudo-register (pic_offset_table_rtx) and the SPARC back-end is not
> prepared for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109541
--- Comment #8 from Vladimir Makarov ---
(In reply to Eric Botcazou from comment #7)
> The problem is that LRA assigns a floating-point register to the PIC
> pseudo-register (pic_offset_table_rtx) and the SPARC back-end is not
> prepared for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706
--- Comment #21 from Vladimir Makarov ---
(In reply to CVS Commits from comment #20)
> The releases/gcc-12 branch has been updated by Vladimir Makarov
> :
>
> https://gcc.gnu.org/g:88792f04e5c63025506244b9ac7186a3cc10c25a
>
>
The trunk with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137
--- Comment #20 from Vladimir Makarov ---
(In reply to CVS Commits from comment #19)
> The master branch has been updated by Jakub Jelinek :
>
> https://gcc.gnu.org/g:0d9e52675c009139a14182d92ddb446ba2feabce
>
> commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137
--- Comment #15 from Vladimir Makarov ---
I've reproduced hanging up but for the particular commit. I also reproduced
internal compiler error on the current master.
I'll try to fix the both problems on this week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179
--- Comment #21 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #20)
> That LGTM, but Vlad is the maintainer here...
It looks ok for me too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179
--- Comment #14 from Vladimir Makarov ---
(In reply to Peter Bergner from comment #13)
> (In reply to Peter Bergner from comment #12)
> > I'll try moving the test up earlier and testing with that.
>
> So this fixes the ICEs on the two test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179
--- Comment #9 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #7)
> So perhaps:
> --- gcc/lra-constraints.cc.jj 2023-03-17 16:09:09.162136438 +0100
> +++ gcc/lra-constraints.cc2023-03-17 21:37:04.799285670 +0100
> @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179
--- Comment #6 from Vladimir Makarov ---
Peter, thank you for reporting. I'll try to fix it today or revert it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109052
--- Comment #6 from Vladimir Makarov ---
(In reply to Uroš Bizjak from comment #5)
> (In reply to Vladimir Makarov from comment #4)
>
> > So I think the current patch is probably an adequate solution.
>
> Perhaps the compiler should also try
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109052
--- Comment #4 from Vladimir Makarov ---
The complete solution would be running combine pass also after LRA. I am not
sure how frequently the 2nd pass will improve the code. Also probably it might
create some troubles the fix of which will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108141
--- Comment #7 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #6)
> The change has been reverted, so this is no longer a regression.
Just for the info. The patch I reverted resulted in wrong calculation of
pressure classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108999
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108145
--- Comment #6 from Vladimir Makarov ---
FYI, I think my patch did not cause this problem.
I've just check fresh trunk (w/o my patch and the compilation still fails).
So the PR probably should be still open.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108774
--- Comment #1 from Vladimir Makarov ---
Thank you for reporting this. I'll try to fix it as soon as possible, today or
tomorrow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108754
--- Comment #9 from Vladimir Makarov ---
(In reply to Hans-Peter Nilsson from comment #8)
> My test-run with the suggested change on top of r13-5761-g10827a92f1a8c3
> came out clean (all regressions resolved, no new ones added) so I'll close
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108754
--- Comment #4 from Vladimir Makarov ---
(In reply to Hans-Peter Nilsson from comment #3)
> (In reply to Vladimir Makarov from comment #1)
> > I think the problem is that cris uses the old reload pass. Could you check
> > the following patch:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108754
--- Comment #1 from Vladimir Makarov ---
I think the problem is that cris uses the old reload pass. Could you check the
following patch:
diff --git a/gcc/ira.cc b/gcc/ira.cc
index d0b6ea062e8..9f9af808f63 100644
--- a/gcc/ira.cc
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108500
--- Comment #20 from Vladimir Makarov ---
(In reply to Richard Biener from comment #14)
> Thanks for the new testcase. With -O0 (and a --enable-checking=release
> built compiler) this builds in ~11 minutes (on a Ryzen 9 7900X) with
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103541
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #35 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #34)
> Seems right now DECL_NONALIASED is only used on these coverage vars and on
> Fortran caf tokens, so perhaps a quick workaround would be on the LRA side
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108388
--- Comment #1 from Vladimir Makarov ---
Thank you for reporting this. I've been working on this PR. I believe the PR
reveals the problem not only for PDP11. I guess the same can happen for some
other targets.
I hope the patch will be ready
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706
--- Comment #17 from Vladimir Makarov ---
I've reverted my patch as it resulted in two new PRs. I'll do more work on
this PR and I'll start this job in Jan.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106462
--- Comment #2 from Vladimir Makarov ---
I built mips64el-linux-gnuabi64 but using -mabi=64 -msingle-float for it gives
cc1: error: unsupported combination: -mgp64 -mno-odd-spreg
Did I miss something?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104637
--- Comment #14 from Vladimir Makarov ---
I've just ported the two patches to gcc-10 and gcc-11 release branches.
gcc-10 required additional work besides just cherry-picking.
The patches were successfully bootstrapped and tested on x86-64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105136
--- Comment #4 from Vladimir Makarov ---
I am just saying trivial things here that RA is a NP-complete task and there is
no optimal solution for all tests. For GCC it is even more complicated as RA
solves code selection tasks too. Basically
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105032
--- Comment #12 from Vladimir Makarov ---
GCC-11 branch needs a bit different patch. I'll commit a modified patch to
gcc-11 branch on Friday.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105032
--- Comment #10 from Vladimir Makarov ---
I've reproduced the bug also on the trunk. The loop in question assumes a
specific order for reload insns. In this case order of insns involving the
reload pseudos is violated because the pseudo is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105032
--- Comment #9 from Vladimir Makarov ---
Cycling is the worst what can happen to compiler (even crash is better).
This is the highest priority PR right now for me. I can not say why the cycle
does not finish. It should as it works only for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104961
--- Comment #2 from Vladimir Makarov ---
I've reproduced the bug. The mentioned patch is not the cause but a trigger.
The origin of the problem is actually a removal of hard reg propagation before
RA which happened about year ago.
I hope the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104637
--- Comment #6 from Vladimir Makarov ---
(In reply to CVS Commits from comment #5)
> The master branch has been updated by Jakub Jelinek :
>
> https://gcc.gnu.org/g:d7b4c8feee11ea04b83f9996654c96b130588570
>
> commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104686
--- Comment #19 from Vladimir Makarov ---
(In reply to Richard Biener from comment #16)
> it doesn't make a difference for this testcase but profiling shows that
> allocnos_conflict_p is quite expensive so it's best to do it after the other
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104637
--- Comment #3 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #2)
> If I change the testcase to following (so that it doesn't rely on
> __builtin_convertvector), it started ICEing with
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104400
--- Comment #3 from Vladimir Makarov ---
(In reply to Jeffrey A. Law from comment #2)
> NP on the timing. My biggest concern (as always) is whether or not this is
> a generic issue or a bug in the v850 target files. The former is obviously
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102178
--- Comment #30 from Vladimir Makarov ---
(In reply to Richard Biener from comment #29)
> (In reply to Vladimir Makarov from comment #28)
> > Could somebody benchmark the following patch on zen2 470.lbm.
>
> Code generation changes quite a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104117
--- Comment #21 from Vladimir Makarov ---
(In reply to Iain Sandoe from comment #20)
> (In reply to Iain Sandoe from comment #15)
> > (In reply to Vladimir Makarov from comment #13)
> > > I think there are two code spots whose pitfalls resulted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102178
--- Comment #28 from Vladimir Makarov ---
Could somebody benchmark the following patch on zen2 470.lbm.
diff --git a/gcc/lra-constraints.cc b/gcc/lra-constraints.cc
index 9cee17479ba..76619aca8eb 100644
--- a/gcc/lra-constraints.cc
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104400
--- Comment #1 from Vladimir Makarov ---
Thank you for reporting this, Jeff.
I've reproduced the bug. I hope to fix this on this week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104117
--- Comment #13 from Vladimir Makarov ---
I think there are two code spots whose pitfalls resulted in the PR.
The first one is in rs6000.cc::legitimate_lo_sum_address_p which permits wrong
pic low-sum address.
Another one is in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102178
--- Comment #27 from Vladimir Makarov ---
(In reply to Richard Biener from comment #17)
> So in .reload we have (with unpatched trunk)
>
> 401: NOTE_INSN_BASIC_BLOCK 6
> 462: ax:DF=[`*.LC0']
> REG_EQUAL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102178
--- Comment #26 from Vladimir Makarov ---
(In reply to Richard Biener from comment #7)
> make costs in a way that IRA/LRA prefer re-materialization of constants
> from the constant pool over spilling to GPRs (if that's possible at all -
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103616
--- Comment #1 from Vladimir Makarov ---
I can not reproduce ICE on this week GCC. Probably it was fixed (or switched
off) by some recent RA patch.
As for the second issue (code generation for function foo), I thought for some
time how it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104049
--- Comment #3 from Vladimir Makarov ---
(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 quite reasonable registers. LRA just generates 2 reloads for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103676
--- Comment #23 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #22)
> If we consider such an inline asm invalid, we could error on it, ICE is not
> the right thing. But what exactly should we error on? Alternative
I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103676
--- Comment #21 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #19)
> r10-3981-gf6ff841bc8dd87ce364deb217dc6d1ec5dc31de8 still doesn't ICE,
> r10-3984-g22060d0e575e7754eb1355763d22bbe37c3caa13 already ICEs.
>
> I guess there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103722
--- Comment #1 from Vladimir Makarov ---
(In reply to Joseph S. Myers from comment #0)
> Created attachment 52003 [details]
> preprocessed source
>
> Build the attached code (from glibc) with -O2 for sh4-linux-gnu. This
> produces an ICE:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99531
--- Comment #4 from Vladimir Makarov ---
Thank you for reporting this. It is true my patch caused this.
I've reproduced the bug on master too. I will be working on this PR. I
think a fix will be ready on the next week the best as the fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103437
--- Comment #5 from Vladimir Makarov ---
Thank you for reporting this. This problem seems not that important as it is
only about heuristic costs and might be result only in worse performance code
generation (but might be in better code -- it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102842
--- Comment #12 from Vladimir Makarov ---
The patch just hid the bug. I believe the bug is still present on the trunk
too.
The insn in question is
(insn 26 64 109 3 (parallel [
(set (reg:SI 134 [ _12 ])
(plus:SI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102627
--- Comment #8 from Vladimir Makarov ---
I've committed the patch to gcc-11 branch too after nobody made complaints
about the patch in the trunk. I've also successfully tested and bootstrapped
the patch on the branch too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102627
--- Comment #4 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #3)
> The assembly difference r11-8007 to r11-8008 is:
> --- pr102627.s2021-10-06 06:32:46.0 -0400
> +++ pr102627.s2021-10-06
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102147
--- Comment #7 from Vladimir Makarov ---
I've been thinking about ways to fix this problem but only come to the
following patch. The patch results in working mostly the same for 64-bit
targets and different for 32-bit targets. In any case the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102356
--- Comment #3 from Vladimir Makarov ---
(In reply to Martin Liška from comment #2)
> If I see correctly, it started with r11-209-g74dc179a6da33cd0.
Yes, I am confirming that my patch triggered the slow down. But the actual
problem is not RA,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102147
--- Comment #6 from Vladimir Makarov ---
(In reply to David Edelsohn from comment #5)
> Vlad privately commented: "I suspect order of processing conflicts might
> depend on their representation."
>
> The two representations may produce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100328
--- Comment #2 from Vladimir Makarov ---
(In reply to Kewen Lin from comment #1)
> Created attachment 50715 [details]
> ira:consider matching cstr in all alternatives
>
> With little understanding on ira, I am not quite sure this patch is on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100066
--- Comment #2 from Vladimir Makarov ---
Thank you for reporting this. I've reproduced this bug. It seems something
wrong with hard reg live range splitting. This code is complicated so I can
not say when it will be fixed but I'll do my
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96264
--- Comment #22 from Vladimir Makarov ---
I've committed the patch to gcc-10 branch.
I also committed patch modifying the test -- see PR99233.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96264
--- Comment #19 from Vladimir Makarov ---
(In reply to Richard Biener from comment #18)
> Please somebody do it quick then (not omitting necessary testing, of course).
I am working on it. It is my highest priority work. The patch is ready.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96264
--- Comment #17 from Vladimir Makarov ---
(In reply to Peter Bergner from comment #16)
> (In reply to seurer from comment #15)
> > It still fails on gcc 10, though
>
> Vlad, can we get this backported to GCC 10? Maybe in time for GCC 10.3?
1 - 100 of 878 matches
Mail list logo
