https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92796
--- Comment #10 from Vladimir Makarov ---
(In reply to Vladimir Makarov from comment #7)
>
>
> I'm guessing this was never a problem before I added the code to not add
> conflicts for copies. Before then, any two pseudos/registers that were li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92796
--- Comment #8 from Vladimir Makarov ---
(In reply to Vladimir Makarov from comment #7)
> A very interesting case, Peter. I reproduced the case too. I can take it
> from here if you don't mind. The solution I see for this problem is to
> chec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92796
--- Comment #7 from Vladimir Makarov ---
(In reply to Peter Bergner from comment #6)
>
> Vlad (or Jeff), can you point me to where this is supposed to be handled?
> I don't think I see where LRA verifies the reg_renumber[regno] values are
> stil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92176
--- Comment #9 from Vladimir Makarov ---
Thank you, Andreas. I've committed the patch with your changes in the test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92176
--- Comment #8 from Vladimir Makarov ---
Author: vmakarov
Date: Fri Dec 6 19:30:37 2019
New Revision: 279061
URL: https://gcc.gnu.org/viewcvs?rev=279061&root=gcc&view=rev
Log:
2019-12-06 Andreas Krebbel
Vladimir Makarov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92176
--- Comment #6 from Vladimir Makarov ---
(In reply to Vladimir Makarov from comment #5)
>
> I'll investigate this problem more.
Hi, Andreas. The rtlanal code (!lra_in_progress) was added to GCC since the
first patch introducing LRA. As I wrot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92176
--- Comment #5 from Vladimir Makarov ---
(In reply to Andreas Krebbel from comment #3)
> 276.ira:
>
>
> /* Give the backend a chance to disallow the mode change. */
> if (GET_MODE_CLASS (xmode) != MODE_COMPLEX_INT
> && GET_MODE_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
--- Comment #27 from Vladimir Makarov ---
Author: vmakarov
Date: Fri Nov 29 22:04:21 2019
New Revision: 278865
URL: https://gcc.gnu.org/viewcvs?rev=278865&root=gcc&view=rev
Log:
2019-11-29 Vladimir Makarov
PR rtl-optimization/92283
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
--- Comment #26 from Vladimir Makarov ---
I think I find the problem root. We have
** Local #2: **
Choosing alt 0 in insn 1804: (0) =v (1) %0 (2) vm (3) v
{*fma_fmadd_df}
Creating newreg=4707 from oldreg=1801,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90007
--- Comment #14 from Vladimir Makarov ---
(In reply to Segher Boessenkool from comment #13)
> Does that work? You cannot put all hard registers in memory I think?
> Or do we require that and it is just not documented?
It depends on insns. For
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90007
--- Comment #12 from Vladimir Makarov ---
Author: vmakarov
Date: Wed Nov 27 14:24:47 2019
New Revision: 278770
URL: https://gcc.gnu.org/viewcvs?rev=278770&root=gcc&view=rev
Log:
2019-11-27 Vladimir Makarov
PR rtl-optimization/90007
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
--- Comment #24 from Vladimir Makarov ---
(In reply to Richard Biener from comment #23)
> Vladimir, can you look into this LRA inheritance issue?
Yes, I've started to work on this. I can not reproduce it on the current
trunk. But yesterday, I'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90007
--- Comment #11 from Vladimir Makarov ---
(In reply to Alexander Monakov from comment #4)
> Well, often sel-sched just does not discriminate hardregs and pseudos when
> checking if renaming/substitution may be applied. Sure, as a matter of
> effi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91430
--- Comment #2 from Vladimir Makarov ---
(In reply to Martin Liška from comment #1)
> Fixed on trunk with r273357, thus probably a dup of PR91102.
> Vladimir?
Yes, it is definitely a dup.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91223
--- Comment #7 from Vladimir Makarov ---
Author: vmakarov
Date: Thu Jul 25 18:36:52 2019
New Revision: 273810
URL: https://gcc.gnu.org/viewcvs?rev=273810&root=gcc&view=rev
Log:
2019-07-25 Vladimir Makarov
PR rtl-optimization/91223
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91223
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91102
--- Comment #7 from Vladimir Makarov ---
Author: vmakarov
Date: Wed Jul 10 16:07:10 2019
New Revision: 273357
URL: https://gcc.gnu.org/viewcvs?rev=273357&root=gcc&view=rev
Log:
2019-07-10 Vladimir Makarov
PR target/91102
* lr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91102
--- Comment #5 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #1)
>
> Vlad, could you please have a look?
The culprit patch is actually
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=265942
Prohibiting reload for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90976
--- Comment #2 from Vladimir Makarov ---
(In reply to Jeffrey A. Law from comment #1)
> Agreed, looks suspicious. From my reading of the code, I think using
> "constraints" rather than "recog_data.constraints" is correct.
>
> The prior call to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88751
--- Comment #5 from Vladimir Makarov ---
(In reply to Andreas Krebbel from comment #4)
> (In reply to Babneet Singh from comment #3)
> > Hi Andreas and Richard: What's the status for this issue? Which approach
> > will be used to resolve this iss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90174
--- Comment #4 from Vladimir Makarov ---
(In reply to Feng Xue from comment #0)
> Current regional RA uses a top-down allocation order, which may not properly
> split a long live range that crosses sub-region with high register pressure.
>
> In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #25 from Vladimir Makarov ---
(In reply to Peter Bergner from comment #24)
> So improve_allocation() initially looks at using r0, but disregards it
> because check_hard_reg_p() returns false for r0, and that is because we fail
> this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #20 from Vladimir Makarov ---
(In reply to Wilco from comment #19)
> (In reply to Peter Bergner from comment #18)
> > (In reply to Segher Boessenkool from comment #15)
> > > Popping a5(r116,l0) -- assign reg 3
> > > Poppi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89865
--- Comment #22 from Vladimir Makarov ---
Author: vmakarov
Date: Mon Apr 1 16:18:30 2019
New Revision: 270060
URL: https://gcc.gnu.org/viewcvs?rev=270060&root=gcc&view=rev
Log:
2019-04-01 Vladimir Makarov
PR rtl-optimization/89865
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89865
--- Comment #20 from Vladimir Makarov ---
I'll be working on this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89676
--- Comment #9 from Vladimir Makarov ---
Author: vmakarov
Date: Mon Mar 25 21:14:40 2019
New Revision: 269924
URL: https://gcc.gnu.org/viewcvs?rev=269924&root=gcc&view=rev
Log:
2019-03-25 Vladimir Makarov
PR rtl-optimization/89676
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89676
--- Comment #8 from Vladimir Makarov ---
Author: vmakarov
Date: Fri Mar 22 16:59:21 2019
New Revision: 269878
URL: https://gcc.gnu.org/viewcvs?rev=269878&root=gcc&view=rev
Log:
2019-03-22 Vladimir Makarov
PR rtl-optimization/89676
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89676
--- Comment #7 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #6)
>
> That said, if you can handle it in the RA, it could handle even those
> variable shift cases better (just make sure it doesn't overlap ecx, but
> otherwise
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89676
--- Comment #5 from Vladimir Makarov ---
I am working on it. It is a non-trivial problem. We should somehow exclude
creation of conflicts in lra-lives.c for an early clobber matched with an
input.
I hope to fix it this week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85860
--- Comment #7 from Vladimir Makarov ---
Author: vmakarov
Date: Wed Mar 13 20:44:50 2019
New Revision: 269663
URL: https://gcc.gnu.org/viewcvs?rev=269663&root=gcc&view=rev
Log:
2019-03-13 Vladimir Makarov
PR target/85860
* lr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85860
--- Comment #6 from Vladimir Makarov ---
Author: vmakarov
Date: Wed Mar 13 20:35:18 2019
New Revision: 269662
URL: https://gcc.gnu.org/viewcvs?rev=269662&root=gcc&view=rev
Log:
2019-03-13 Vladimir Makarov
PR target/85860
* lr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87716
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88596
--- Comment #8 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #7)
> The above testcase reproduced, reduced to following, started with r266385.
> Note, this testcase ICEd in gcc 7.x and earlier too, got fixed with r258504
> (sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271
--- Comment #11 from Vladimir Makarov ---
(In reply to Alan Modra from comment #5)
> Created attachment 45760 [details]
> Current set of patches
>
> It turns out there is a lot more than just wrong register_move_cost. This
> patchset does fix t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271
--- Comment #1 from Vladimir Makarov ---
> This is because IRA does
>
> r125: preferred NO_REGS, alternative NO_REGS, allocno NO_REGS
>
>a1(r125,l0) costs: BASE_REGS:14004,14004 GENERAL_REGS:14004,14004-
>LINK_REGS:24010,24010 CTR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88560
--- Comment #13 from Vladimir Makarov ---
Author: vmakarov
Date: Fri Feb 8 19:01:10 2019
New Revision: 268705
URL: https://gcc.gnu.org/viewcvs?rev=268705&root=gcc&view=rev
Log:
2019-02-08 Vladimir Makarov
PR middle-end/88560
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89225
--- Comment #2 from Vladimir Makarov ---
Author: vmakarov
Date: Wed Feb 6 21:48:45 2019
New Revision: 268597
URL: https://gcc.gnu.org/viewcvs?rev=268597&root=gcc&view=rev
Log:
2019-02-06 Vladimir Makarov
PR rtl-optimization/89225
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89225
--- Comment #1 from Vladimir Makarov ---
It seems my latest patch for PR87246 caused this:
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=268404
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86487
--- Comment #11 from Vladimir Makarov ---
(In reply to avieira from comment #10)
> Hi Vlad,
>
> I don't think it is a duplication.
Sorry, I was not clear. My comment relates to test
#include
int32x2_t b(long c, ...) {}
$ arm-none-eabi-gcc -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88296
--- Comment #5 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #3)
> for Vlad the question
> is just whether r266862 is a real fix or just made it latent. Given that
> both are IRA costs changes, I assume it is a real fix.
I'v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88596
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86487
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87246
--- Comment #7 from Vladimir Makarov ---
Author: vmakarov
Date: Wed Jan 30 21:49:23 2019
New Revision: 268404
URL: https://gcc.gnu.org/viewcvs?rev=268404&root=gcc&view=rev
Log:
2019-01-30 Vladimir Makarov
PR rtl-optimization/87246
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87246
--- Comment #6 from Vladimir Makarov ---
I am working on this. I hope to fix the PR this week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88846
--- Comment #6 from Vladimir Makarov ---
Sorry, I wrote wrong PR number in the ChangeLog entry (I already fix the
number). Here is the info about the patch I've committed
Author: vmakarov
Date: Fri Jan 25 22:13:43 2019
New Revision: 268280
URL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88846
--- Comment #5 from Vladimir Makarov ---
There should be no REG_EQUIV as RTL doc says "it is valid for the compiler to
replace the pseudo-register by stack slot throughout the function". In this
case the substitution results in a wrong code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88560
--- Comment #9 from Vladimir Makarov ---
(In reply to Vladimir Makarov from comment #8)
> Created attachment 45485 [details]
> Proposed patch
Does this patch solves the problem?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88560
--- Comment #8 from Vladimir Makarov ---
Created attachment 45485
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45485&action=edit
Proposed patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88850
--- Comment #6 from Vladimir Makarov ---
(In reply to Tamar Christina from comment #5)
> So yeah it seems that there are three issues here:
>
> 1) We should probably have an r -> r alternative for *neon_mov.
> 2) The costs are now flipped from w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88560
--- Comment #7 from Vladimir Makarov ---
(In reply to Wilco from comment #6)
> (In reply to Vladimir Makarov from comment #5)
> > We have too many tests checking expected generated code. We should more
> > focus on overall effect of the change.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #14 from Vladimir Makarov ---
I've checked cvtf_1.c generated code and I don't see additional fmov anymore.
I guess it was fixed by an ira-costs.c change (a special consideration of
moves containing hard regs). I think this PR is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88560
--- Comment #5 from Vladimir Makarov ---
We have too many tests checking expected generated code. We should more focus
on overall effect of the change. SPEC would be a good criterium although it is
hard to check SPEC for each patch.
I've check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87305
--- Comment #6 from Vladimir Makarov ---
Author: vmakarov
Date: Fri Jan 11 19:25:31 2019
New Revision: 267854
URL: https://gcc.gnu.org/viewcvs?rev=267854&root=gcc&view=rev
Log:
2019-01-11 Vladimir Makarov
PR rtl-optimization/87305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87305
--- Comment #4 from Vladimir Makarov ---
Author: vmakarov
Date: Thu Jan 10 21:02:50 2019
New Revision: 267823
URL: https://gcc.gnu.org/viewcvs?rev=267823&root=gcc&view=rev
Log:
2019-01-10 Vladimir Makarov
PR rtl-optimization/87305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87305
--- Comment #3 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #2)
>
> Vlad, could you please have a look?
I've just started to work on it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88457
--- Comment #3 from Vladimir Makarov ---
Author: vmakarov
Date: Thu Dec 20 18:07:51 2018
New Revision: 267307
URL: https://gcc.gnu.org/viewcvs?rev=267307&root=gcc&view=rev
Log:
2018-12-20 Vladimir Makarov
PR target/88457
* ir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87759
--- Comment #3 from Vladimir Makarov ---
Author: vmakarov
Date: Tue Dec 18 21:20:16 2018
New Revision: 267244
URL: https://gcc.gnu.org/viewcvs?rev=267244&root=gcc&view=rev
Log:
2018-12-18 Vladimir Makarov
PR rtl-optimization/87759
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87759
--- Comment #2 from Vladimir Makarov ---
I've started to work on it. The patch will be probably ready on Monday or
Tuesday.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88414
--- Comment #5 from Vladimir Makarov ---
Author: vmakarov
Date: Thu Dec 13 20:54:27 2018
New Revision: 267109
URL: https://gcc.gnu.org/viewcvs?rev=267109&root=gcc&view=rev
Log:
2018-12-13 Vladimir Makarov
PR rtl-optimization/88414
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88414
--- Comment #4 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #3)
> Started with r257077. In any case, it seems to be a LRA error-recovery bug.
> We first properly diagnose that the inline asm has constraints that are
> imposs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88457
--- Comment #2 from Vladimir Makarov ---
(In reply to Richard Biener from comment #1)
> ira-max-conflict-table-size=0 might be an impossible value - Vlad?
Any size is possible. Simply in this case conflict table is not built and
simple RA (ki
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88349
--- Comment #2 from Vladimir Makarov ---
Author: vmakarov
Date: Fri Dec 7 16:08:17 2018
New Revision: 266894
URL: https://gcc.gnu.org/viewcvs?rev=266894&root=gcc&view=rev
Log:
2018-12-07 Vladimir Makarov
PR rtl-optimization/88349
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88282
--- Comment #9 from Vladimir Makarov ---
Author: vmakarov
Date: Thu Dec 6 18:41:46 2018
New Revision: 266862
URL: https://gcc.gnu.org/viewcvs?rev=266862&root=gcc&view=rev
Log:
2018-12-06 Vladimir Makarov
PR target/88282
* ir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88317
--- Comment #4 from Vladimir Makarov ---
Author: vmakarov
Date: Tue Dec 4 22:50:14 2018
New Revision: 266803
URL: https://gcc.gnu.org/viewcvs?rev=266803&root=gcc&view=rev
Log:
2018-12-04 Vladimir Makarov
PR rtl-optimization/88317
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88317
--- Comment #3 from Vladimir Makarov ---
(In reply to Richard Biener from comment #1)
> Vlad - can you look into the above? There's also lra_split_regs set
> (and maybe others) which will have similar problems. The following should
> make it e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88282
--- Comment #7 from Vladimir Makarov ---
Author: vmakarov
Date: Tue Dec 4 15:10:46 2018
New Revision: 266784
URL: https://gcc.gnu.org/viewcvs?rev=266784&root=gcc&view=rev
Log:
2018-12-04 Vladimir Makarov
PR target/88282
* ir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88179
--- Comment #2 from Vladimir Makarov ---
Author: vmakarov
Date: Fri Nov 30 20:15:56 2018
New Revision: 266682
URL: https://gcc.gnu.org/viewcvs?rev=266682&root=gcc&view=rev
Log:
2018-11-30 Vladimir Makarov
PR rtl-optimization/88179
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88282
--- Comment #4 from Vladimir Makarov ---
(In reply to Tamar Christina from comment #3)
> This is caused by the change in r266385 for PR87718.
>
> That causes the cost model to go completely off the rail and also changes
> the register classes.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88207
--- Comment #4 from Vladimir Makarov ---
Author: vmakarov
Date: Wed Nov 28 20:08:03 2018
New Revision: 266582
URL: https://gcc.gnu.org/viewcvs?rev=266582&root=gcc&view=rev
Log:
2018-11-28 Vladimir Makarov
PR target/88207
* ir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88179
--- Comment #1 from Vladimir Makarov ---
Thank you for reporting this. I am working on the PR. I think the solution
will be ready on this week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88207
--- Comment #3 from Vladimir Makarov ---
Thank you for reporting it. I've started to work on the PR. I'll keep you
informed about the progress.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88157
--- Comment #8 from Vladimir Makarov ---
Author: vmakarov
Date: Sun Nov 25 05:46:44 2018
New Revision: 266435
URL: https://gcc.gnu.org/viewcvs?rev=266435&root=gcc&view=rev
Log:
2018-11-25 Vladimir Makarov
PR bootstrap/88157
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88157
--- Comment #6 from Vladimir Makarov ---
Author: vmakarov
Date: Fri Nov 23 22:00:43 2018
New Revision: 266422
URL: https://gcc.gnu.org/viewcvs?rev=266422&root=gcc&view=rev
Log:
2018-11-23 Vladimir Makarov
PR bootstrap/88157
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87485
--- Comment #18 from Vladimir Makarov ---
(In reply to Vladimir Makarov from comment #17)
> I've reproduced it. Clearly, it is some bug in LRA conflict calculation.
> I will be working on it.
I investigated it more. Before scheduling we hav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88157
--- Comment #3 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #2)
> Note, no need to revert if it is something that can be resolved within a few
> days, I can just exclude go from the enabled languages till then.
OK, thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87718
--- Comment #7 from Vladimir Makarov ---
Author: vmakarov
Date: Thu Nov 22 17:25:57 2018
New Revision: 266385
URL: https://gcc.gnu.org/viewcvs?rev=266385&root=gcc&view=rev
Log:
2018-11-22 Vladimir Makarov
PR rtl-optimization/87718
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84757
--- Comment #7 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #6)
> Vlad, is this something that can be still done for GCC 9 or should we defer
> to GCC 10?
Adding live analysis on subreg level to LRA is a big work and I thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87485
--- Comment #17 from Vladimir Makarov ---
I've reproduced it. Clearly, it is some bug in LRA conflict calculation. I
will be working on it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87718
--- Comment #6 from Vladimir Makarov ---
The culprit for the bad code generation is the following insn description
(define_insn "*movsi_internal"
[(set (match_operand:SI 0 "nonimmediate_operand"
"=r,m ,*y,*y,?*y,?m,?r,?*y,*v,*v,*v,m ,?r,?*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87718
--- Comment #5 from Vladimir Makarov ---
In general moving from propagation of hard regs is good thing for RA.
Although there are exception as this PR.
The problem starts with IRA. It decides that r91 should be a general regs
based on cos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78127
--- Comment #7 from Vladimir Makarov ---
(In reply to Wilco from comment #6)
> (In reply to Vladimir Makarov from comment #3)
> > Author: vmakarov
> > Date: Thu Feb 16 19:47:15 2017
> > New Revision: 245514
> >
> > URL: https://gcc.gnu.org/viewc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86547
--- Comment #6 from Vladimir Makarov ---
(In reply to Ilya Leoshkevich from comment #5)
>
>
> Vladimir, could you please take a look at the attached patch? I
> ran regression with and without it on x86_64, and compare_tests did not
> show any n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79916
--- Comment #10 from Vladimir Makarov ---
Author: vmakarov
Date: Fri Apr 13 22:55:16 2018
New Revision: 259379
URL: https://gcc.gnu.org/viewcvs?rev=259379&root=gcc&view=rev
Log:
2018-04-13 Vladimir Makarov
PR rtl-optimization/79916
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79916
--- Comment #9 from Vladimir Makarov ---
I've reproduced one test bug on my machine by using:
./cc1 -I. ../../gcc/gcc/testsuite/gcc.dg/dfp/pr41049.c
-fno-expensive-optimizations --param ira-max-conflict-table-size=0 -mpopcntd
-O3
I think the fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85090
--- Comment #13 from Vladimir Makarov ---
(In reply to Uroš Bizjak from comment #11)
> (In reply to Jakub Jelinek from comment #5)
> > I guess it depends on what exactly a normal subreg on lhs means.
> > The documentation says:
> > When
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85090
--- Comment #10 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #5)
> I guess it depends on what exactly a normal subreg on lhs means.
> The documentation says:
> When used as an lvalue, 'subreg' is a word-based access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67486
--- Comment #7 from Vladimir Makarov ---
(In reply to David Binderman from comment #6)
> I wonder if changing type of static array full_costs from int to long would
> help solve the problem.
>
> Adding vmakarov, who seems to be the author of mos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84985
--- Comment #3 from Vladimir Makarov ---
Author: vmakarov
Date: Thu Mar 29 18:29:12 2018
New Revision: 258961
URL: https://gcc.gnu.org/viewcvs?rev=258961&root=gcc&view=rev
Log:
2018-03-29 Vladimir Makarov
PR inline-asm/84985
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85072
--- Comment #4 from Vladimir Makarov ---
(In reply to Richard Biener from comment #3)
> Doing a more "correct" patch like below shows that nearly all possible
> "starts" are covered:
>
> (gdb) p bitmap_count_bits(starts)
> $2 = 500039
> (gdb) p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85030
--- Comment #5 from Vladimir Makarov ---
Author: vmakarov
Date: Fri Mar 23 19:31:00 2018
New Revision: 258820
URL: https://gcc.gnu.org/viewcvs?rev=258820&root=gcc&view=rev
Log:
2018-03-23 Vladimir Makarov
PR inline-asm/85030
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85030
--- Comment #4 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #3)
> Trying to create BLKmode subreg of something (or subreg from BLKmode) is not
> going to work well, but don't know the LRA code enough to know how to safely
> g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84876
--- Comment #4 from Vladimir Makarov ---
Author: vmakarov
Date: Fri Mar 16 18:48:26 2018
New Revision: 258602
URL: https://gcc.gnu.org/viewcvs?rev=258602&root=gcc&view=rev
Log:
2018-03-16 Vladimir Makarov
PR target/84876
* lr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84876
--- Comment #3 from Vladimir Makarov ---
(In reply to Vladimir Makarov from comment #2)
> Sorry, my bad. It is easy to fix. I think the patch will be ready today.
Unfortunately, this test also triggers more serious problem of my last patch
(r2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84876
--- Comment #2 from Vladimir Makarov ---
Sorry, my bad. It is easy to fix. I think the patch will be ready today.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84757
--- Comment #4 from Vladimir Makarov ---
Sorry, the analysis took more time than I thought.
This PR can be solved only by introducing live range analysis in LRA on
**subreg level**. IRA already has such analysis and therefore it makes such
allo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83712
--- Comment #11 from Vladimir Makarov ---
Author: vmakarov
Date: Tue Mar 13 20:42:49 2018
New Revision: 258504
URL: https://gcc.gnu.org/viewcvs?rev=258504&root=gcc&view=rev
Log:
2018-03-13 Vladimir Makarov
PR target/83712
* l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83712
--- Comment #10 from Vladimir Makarov ---
Author: vmakarov
Date: Sat Mar 10 16:32:21 2018
New Revision: 258415
URL: https://gcc.gnu.org/viewcvs?rev=258415&root=gcc&view=rev
Log:
2018-03-10 Vladimir Makarov
Reverting patch:
20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84757
--- Comment #3 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #2)
> Started with r244942. Vlad, can you please have a look? Thanks.
Sure, I'll look at this. Some analysis will be ready today.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83712
--- Comment #7 from Vladimir Makarov ---
Author: vmakarov
Date: Fri Mar 9 16:00:36 2018
New Revision: 258390
URL: https://gcc.gnu.org/viewcvs?rev=258390&root=gcc&view=rev
Log:
2018-03-09 Vladimir Makarov
PR target/83712
* lr
201 - 300 of 879 matches
Mail list logo
