https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118067
--- Comment #11 from Vladimir Makarov ---
(In reply to Uroš Bizjak from comment #9)
> Unfortunately, the testcase still fails when -mtune=k8 is added to compile
> flags:
>
>
Thank you, Uros.
I tried to avoid finding longer reload loops but it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118067
--- Comment #7 from Vladimir Makarov ---
I've been working on thr PR this week. The case is complicated as it contains
cycle of reloads of more one step length. LRA has a mechanism to avoid
choosing insn alternatives which can results in a loo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117999
--- Comment #8 from Vladimir Makarov ---
I reverted the 1st patch variant for PR117248 which resulted in this PR.
I submitted a different patch for PR117248 which does not create new failures
for libgo tests on arm.
Still it would be nice to r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117248
--- Comment #23 from Vladimir Makarov ---
(In reply to GCC Commits from comment #15)
> The master branch has been updated by Vladimir Makarov
> :
>
> https://gcc.gnu.org/g:75e7d1600f47859df40b2ac0feff5a71e0dbb040
>
> commit r15-5997-g75e7d1600
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117999
--- Comment #6 from Vladimir Makarov ---
I've tried arm GCC before and after the patch. I see failures before the patch
too (e.g. net failed with the same wrong address or nil dereference as crypto)
although, I should acknowledge, less than af
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117999
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117248
--- Comment #18 from Vladimir Makarov ---
(In reply to John David Anglin from comment #16)
> Things are improved but a similar error occurs in the second umod:SI
> call in /testsuite/gcc.c-torture/execute/arith-rand-ll.c:
>
>
> (insn 341 339 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117946
--- Comment #11 from Vladimir Makarov ---
I've reproduced it and started to work on it. I think the fix will be ready
during the next 2 days.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117248
--- Comment #13 from Vladimir Makarov ---
(In reply to Vladimir Makarov from comment #12)
>
> I see. Thank you. I've reproduced it with using -mlra.
This case is really non-trivial and involves inheritance. Also the live
analysis in LRA af
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117248
--- Comment #12 from Vladimir Makarov ---
(In reply to John David Anglin from comment #11)
> LRA is not yet enabled by default on hppa. To enable, use "-mlra" option
> or hack pa.opt to enable by default:
>
> mlra
> Target Var(pa_lra_p) Init(1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117248
--- Comment #10 from Vladimir Makarov ---
(In reply to John David Anglin from comment #7)
>
> Compile command:
> /home/dave/gnu/gcc/objdir/./prev-gcc/cc1plus -fpreprocessed
> tree-vect-slp.ii -quiet -dumpbase tree-vect-slp.cc -dumpbase-ext .cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117770
--- Comment #6 from Vladimir Makarov ---
(In reply to John David Anglin from comment #5)
> I'm working on trying to split the code after reload.
OK. But there is a still LRA bug which incorrectly makes r25 dead before the
division insn and anal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117770
--- Comment #4 from Vladimir Makarov ---
(In reply to John David Anglin from comment #3)
> I suspect explicitly setting hard registers prior to reload confuses
> LRA:
>
> ;;; Division and mod.
> (define_expand "divsi3"
> [(set (reg:SI 26) (ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115521
--- Comment #9 from Vladimir Makarov ---
(In reply to Vladimir Makarov from comment #8)
> (In reply to Uroš Bizjak from comment #7)
> > PR117105 exhibits the same underlying probem with much smaller testcase.
>
> I started to work on these 2 PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115521
--- Comment #8 from Vladimir Makarov ---
(In reply to Uroš Bizjak from comment #7)
> PR117105 exhibits the same underlying probem with much smaller testcase.
I started to work on these 2 PRs. I think the fix to be ready on the beginning
of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116587
--- Comment #11 from Vladimir Makarov ---
I consider it is a LRA bug.
We have
281: {r360:DI=~227:DI&[r363:SI+r362:SI];clobber flags:CC;}
and choose alternative "(0) &r (1) r (2) o"
LRA assigns (hr0,hr1) to spilled p227, then assigns (hr4,h
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. T
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 f
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,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 (match_o
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 ‘^’ need
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 optimizatio
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
dependen
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 analysis.
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 accu
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 looke
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 @@
>[(s
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 risky
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 not
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 reason
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 work
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 cu
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 [r2
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 pref
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 post
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 it.
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 it.
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 t
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 r13-6846-g0d9e52675c0091
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 case
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
> @@ -5020
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 t
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 requ
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
> t
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
+++ b/gcc/ira.
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
>
> integr
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
> ne
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 we
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 als
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 rel
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 r12-7449-gd7b4c8feee11ea04
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
> co
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
> r0-122162-gb7aa4e9afcd3da4f09d6f982a663
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
> m
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 bit,
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
+++ b/gcc/lr
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 lra-constraints
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 9.850689972416730997792
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 -
> Vlad?)
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 coul
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 t
1 - 100 of 895 matches
Mail list logo
