https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21182
--- Comment #23 from Vladimir Makarov ---
(In reply to Jeffrey A. Law from comment #22)
> Vlad -- I was thinking more in the sense of whether or not IRA is presented
> with something reasonable (ie, can be colored) vs unreasonable (can not be
> c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21182
--- Comment #21 from Vladimir Makarov ---
(In reply to Jeffrey A. Law from comment #20)
>
> Anyway, just some thoughts. We're still not at a point where we really know
> if IRA is being presented with something that isn't actually colorable or i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79282
--- Comment #7 from Vladimir Makarov ---
(In reply to Vladimir Makarov from comment #6)
> I think changing pattern
>
> &r(1) = 0(2), r(3)
>
> to
>
> r(1) = 0(2), r(3)
>
> would be a right solution on the target side. The operand 1 can not
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79282
--- Comment #6 from Vladimir Makarov ---
Here is my analysis of the problem.
The test was successful as LRA actually did not work for the test.
LRA just checked that all insn constraints were satisfied. If LRA did
any transformation, the test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71374
--- Comment #6 from Vladimir Makarov ---
Author: vmakarov
Date: Fri Jan 27 18:08:14 2017
New Revision: 244991
URL: https://gcc.gnu.org/viewcvs?rev=244991&root=gcc&view=rev
Log:
2017-01-27 Vladimir Makarov
PR tree-optimization/71374
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79131
--- Comment #8 from Vladimir Makarov ---
I provided the final patch solving all the test cases for the PR. We should
wait for an ACK from Arnd or Dominik to close it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79131
--- Comment #7 from Vladimir Makarov ---
Author: vmakarov
Date: Fri Jan 27 16:50:11 2017
New Revision: 244989
URL: https://gcc.gnu.org/viewcvs?rev=244989&root=gcc&view=rev
Log:
2017-01-27 Vladimir Makarov
PR target/79131
* lr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79131
--- Comment #6 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #4)
> So, is this now fixed or is further work needed?
A further work is needed. There are a few different problems with the big
endian support. I'll submit more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71374
--- Comment #5 from Vladimir Makarov ---
The problem is in that p88 does not conflict with a new reload pseudo created
to match p88 and the 3rd output (p91). They do not conflict as the reload
pseudo has the same value as p88.
So the solution i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79131
--- Comment #3 from Vladimir Makarov ---
Author: vmakarov
Date: Thu Jan 26 17:08:12 2017
New Revision: 244942
URL: https://gcc.gnu.org/viewcvs?rev=244942&root=gcc&view=rev
Log:
2017-01-26 Vladimir Makarov
PR target/79131
* lr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71374
--- Comment #4 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #3)
>
> ICEs as well with -O1 and above. Vlad, do you think you could have a look?
Sure, I'll look at this when I am done with PR79131.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79131
--- Comment #2 from Vladimir Makarov ---
(In reply to Vladimir Makarov from comment #1)
>
> Probably the fix will need more time than for pr79058 but I hope to fix it
> on this week.
I have a fix for the PR. Unfortunately it brakes some GCC IP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79131
--- Comment #1 from Vladimir Makarov ---
This is a bug in LRA now. LRA should have reloaded the destination or the
operand as they conflicts in insn 31 (the destination is an early clobbered
operand). IRA does not take early clobbers into accou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79058
--- Comment #28 from Vladimir Makarov ---
(In reply to Vladimir Makarov from comment #27)
> (In reply to Vladimir Makarov from comment #26)
> > (In reply to Dominik Vogt from comment #24)
> > > While you're at it ... does it have the same or a si
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79058
--- Comment #27 from Vladimir Makarov ---
(In reply to Vladimir Makarov from comment #26)
> (In reply to Dominik Vogt from comment #24)
> > While you're at it ... does it have the same or a similar cause as the Avr
> > bug?
> > https://gcc.gnu.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79058
--- Comment #26 from Vladimir Makarov ---
(In reply to Dominik Vogt from comment #24)
> While you're at it ... does it have the same or a similar cause as the Avr
> bug?
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78883
>
> (A HImode quantity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79058
--- Comment #25 from Vladimir Makarov ---
Author: vmakarov
Date: Tue Jan 17 16:11:55 2017
New Revision: 244535
URL: https://gcc.gnu.org/viewcvs?rev=244535&root=gcc&view=rev
Log:
2017-01-17 Vladimir Makarov
PR target/79058
* i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79058
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78580
--- Comment #5 from Vladimir Makarov ---
Author: vmakarov
Date: Wed Dec 21 22:20:11 2016
New Revision: 243875
URL: https://gcc.gnu.org/viewcvs?rev=243875&root=gcc&view=rev
Log:
2016-12-21 Vladimir Makarov
PR rtl-optimization/78580
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516
--- Comment #15 from Vladimir Makarov ---
(In reply to Peter Bergner from comment #13)
> (In reply to Vladimir Makarov from comment #11)
> > Created attachment 40372 [details]
> > The proposed patch
>
> Agreed your additions to my change looks g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516
--- Comment #11 from Vladimir Makarov ---
Created attachment 40372
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40372&action=edit
The proposed patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516
--- Comment #10 from Vladimir Makarov ---
(In reply to Peter Bergner from comment #8)
> where "src" is the subreg:SI ..., so the new_reg mode will be SImode and we
> then replace the whole SET_SRC (curr_insn_set) which is the subreg:SI
> (reg:DF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78580
--- Comment #3 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #2)
>
> So, is the bug that i?86 needs Q_REGS to be an allocno class always (shall
> ix86_additional_allocno_class_p return true also for Q_REGS? Just for -m32
> or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78671
--- Comment #5 from Vladimir Makarov ---
Author: vmakarov
Date: Thu Dec 8 21:14:42 2016
New Revision: 243462
URL: https://gcc.gnu.org/viewcvs?rev=243462&root=gcc&view=rev
Log:
2016-12-08 Vladimir Makarov
PR rtl-optimization/78671
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78671
--- Comment #3 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #2)
> Started with r243038.
It has just triggered a latent bug. It is a pretty interesting bug. The
problem is that a TImode pseudo has class INT_SSE_REGS and r15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77761
--- Comment #2 from Vladimir Makarov ---
Thanks for reporting this, Zdenek.
After some time staring at the generated code I believe the problem is in
hard register splitting optimization. LRA uses wrongly smaller mode for
splitting than nec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77856
--- Comment #4 from Vladimir Makarov ---
Author: vmakarov
Date: Wed Nov 30 17:35:40 2016
New Revision: 243038
URL: https://gcc.gnu.org/viewcvs?rev=243038&root=gcc&view=rev
Log:
2016-11-30 Vladimir Makarov
PR tree-optimization/77856
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77856
--- Comment #3 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #2)
> So, %ebx doesn't hold 1 as it is supposed to, but 1 << %ecx (64).
> Vlad, could you please have a look?
It is a bug in a new optimization (invariant inherita
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77541
--- Comment #8 from Vladimir Makarov ---
Author: vmakarov
Date: Fri Nov 25 17:42:21 2016
New Revision: 242881
URL: https://gcc.gnu.org/viewcvs?rev=242881&root=gcc&view=rev
Log:
2016-11-25 Vladimir Makarov
PR rtl-optimization/77541
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77541
--- Comment #5 from Vladimir Makarov ---
Author: vmakarov
Date: Thu Nov 24 19:54:27 2016
New Revision: 242848
URL: https://gcc.gnu.org/viewcvs?rev=242848&root=gcc&view=rev
Log:
2016-11-24 Vladimir Makarov
PR rtl-optimization/77541
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77541
--- Comment #4 from Vladimir Makarov ---
(In reply to Uroš Bizjak from comment #2)
> (In reply to Uroš Bizjak from comment #1)
> > This is RA failure, where reload tries to fix up:
>
> To be clear, it is LRA pass, not reload.
Yes, it is a LRA b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78355
--- Comment #5 from Vladimir Makarov ---
(In reply to Eric Botcazou from comment #1)
>
> if (!(MEM_ALIGN (reg) < GET_MODE_ALIGNMENT (mode)
> && SLOW_UNALIGNED_ACCESS (mode, MEM_ALIGN (reg)))
> || (MEM_ALIGN (reg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77416
--- Comment #10 from Vladimir Makarov ---
Author: vmakarov
Date: Mon Sep 19 21:38:27 2016
New Revision: 240247
URL: https://gcc.gnu.org/viewcvs?rev=240247&root=gcc&view=rev
Log:
2016-09-19 Vladimir Makarov
PR rtl-optimization/77416
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77416
--- Comment #8 from Vladimir Makarov ---
Sorry for delay with the answer. I had a long vacation.
LRA remat sub-pass did not check relation between the hard coded insn
registers. It checked only relations between operand registers and other
ope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77416
--- Comment #7 from Vladimir Makarov ---
Created attachment 39637
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39637&action=edit
A patch candidate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77289
--- Comment #5 from Vladimir Makarov ---
(In reply to Peter Bergner from comment #4)
Thank you for working on this PR.
> Adding Vlad since there are IRA and LRA questions.
>
>
>
> I'm not sure if IRA is supposed to always assign operand 1 the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69847
--- Comment #25 from Vladimir Makarov ---
Author: vmakarov
Date: Fri Aug 5 21:31:31 2016
New Revision: 239180
URL: https://gcc.gnu.org/viewcvs?rev=239180&root=gcc&view=rev
Log:
2016-08-05 Vladimir Makarov
PR rtl-optimization/69847
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69847
--- Comment #23 from Vladimir Makarov ---
(In reply to mwahab from comment #22)
> I believe that this patch is the cause of compilation failures for a number
> of tests on arm-none-linux-gnueabihf and arm-none-eabi.
>
> E.g. arm-none-linux-gnuea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72778
--- Comment #8 from Vladimir Makarov ---
Author: vmakarov
Date: Wed Aug 3 18:54:49 2016
New Revision: 239091
URL: https://gcc.gnu.org/viewcvs?rev=239091&root=gcc&view=rev
Log:
2016-08-03 Vladimir Makarov
PR middle-end/72778
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72778
--- Comment #7 from Vladimir Makarov ---
(In reply to Uroš Bizjak from comment #6)
Hi, Uros. Thanks for reporting this. It was my mistake that I did not check
bootstrap with GO. I am going to fix it soon.
> Before the patch, register allocato
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72778
--- Comment #2 from Vladimir Makarov ---
Author: vmakarov
Date: Tue Aug 2 20:57:04 2016
New Revision: 239000
URL: https://gcc.gnu.org/viewcvs?rev=239000&root=gcc&view=rev
Log:
2016-08-02 Vladimir Makarov
PR middle-end/72778
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72778
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69847
--- Comment #20 from Vladimir Makarov ---
(In reply to Bill Schmidt from comment #17)
> Vlad, the patch checks out very well on powerpc64le. 403.gcc no longer
> degrades. We are seeing some very nice improvements from LRA over reload on
> a few
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69847
--- Comment #19 from Vladimir Makarov ---
Author: vmakarov
Date: Tue Aug 2 16:07:36 2016
New Revision: 238991
URL: https://gcc.gnu.org/viewcvs?rev=238991&root=gcc&view=rev
Log:
2016-08-02 Vladimir Makarov
PR rtl-optimization/69847
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69847
--- Comment #13 from Vladimir Makarov ---
Hi, on the next week I am going to commit the patch I've just attached. The
final version of the patch will have more comments.
With the patch LRA generates the same code for the test case as reload (th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69847
--- Comment #12 from Vladimir Makarov ---
Created attachment 39029
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39029&action=edit
A patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71621
--- Comment #4 from Vladimir Makarov ---
Author: vmakarov
Date: Fri Jul 8 20:29:12 2016
New Revision: 238178
URL: https://gcc.gnu.org/viewcvs?rev=238178&root=gcc&view=rev
Log:
2016-07-08 Vladimir Makarov
PR rtl-optimization/71621
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71621
--- Comment #3 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #1)
> Started with r237556, but that just likely made it no longer latent.
Yes, it is a latent bug permitting wrong combination of class and mode for a
reload pseud
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70751
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69847
--- Comment #10 from Vladimir Makarov ---
I've been working on this for about 2 weeks and still I don't see the problem
will be solved soon. Therefore I've decided to write some update.
First of all after analyzing hot functions, I found that L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70904
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70689
--- Comment #4 from Vladimir Makarov ---
Author: vmakarov
Date: Tue Apr 19 02:49:54 2016
New Revision: 235184
URL: https://gcc.gnu.org/viewcvs?rev=235184&root=gcc&view=rev
Log:
2016-04-18 Vladimir Makarov
PR middle-end/70689
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70689
--- Comment #3 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #2)
>
> Vlad, could you please have a look at this?
I've started work on it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70398
--- Comment #3 from Vladimir Makarov ---
Author: vmakarov
Date: Wed Apr 6 16:48:36 2016
New Revision: 234792
URL: https://gcc.gnu.org/viewcvs?rev=234792&root=gcc&view=rev
Log:
2016-04-06 Vladimir Makarov
PR rtl-optimization/70398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70465
--- Comment #9 from Vladimir Makarov ---
(In reply to Jeffrey A. Law from comment #8)
> I understand the issues around heuristics.
>
> Presumably this is the code which identifies cases where we have a single
> use register with an associated RE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70465
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70478
--- Comment #2 from Vladimir Makarov ---
The difference I see is that LRA chooses alternative "Q,0,Q" and reload chooses
"d,0,R".
For the "Q,O,Q" LRA reports:
2 Spill pseudo into memory: reject+=3
alt=11,overall=9,losers=1,r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70461
--- Comment #3 from Vladimir Makarov ---
Author: vmakarov
Date: Thu Mar 31 17:51:13 2016
New Revision: 234649
URL: https://gcc.gnu.org/viewcvs?rev=234649&root=gcc&view=rev
Log:
2016-03-31 Vladimir Makarov
PR rtl-optimization/70461
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70461
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69614
--- Comment #28 from Vladimir Makarov ---
Author: vmakarov
Date: Wed Mar 30 15:58:10 2016
New Revision: 234577
URL: https://gcc.gnu.org/viewcvs?rev=234577&root=gcc&view=rev
Log:
2016-03-30 Vladimir Makarov
Backported from the mainlin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68695
--- Comment #25 from Vladimir Makarov ---
Author: vmakarov
Date: Tue Mar 29 16:20:39 2016
New Revision: 234527
URL: https://gcc.gnu.org/viewcvs?rev=234527&root=gcc&view=rev
Log:
2016-03-29 Vladimir Makarov
PR rtl-optimization/68695
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68695
--- Comment #23 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #22)
> Going back to variants of the original testcase:
> int
> foo (int x, int y, int a)
> {
> int i = x;
> int j = y;
> #ifdef EX1
> if (__builtin_expect (x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70164
--- Comment #10 from Vladimir Makarov ---
(In reply to Jeffrey A. Law from comment #9)
> I think that's a fair characterization. The extra copy emitted by the older
> compiler gives the allocator more freedom. With coalescing getting more
> ag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70326
--- Comment #4 from Vladimir Makarov ---
Thanks.
(In reply to Jakub Jelinek from comment #3)
> Created attachment 38047 [details]
> gcc6-pr70326.patch
>
> So do you mean something like this? Or check !INSN_P instead of checking
> for NOTE_P &&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70326
--- Comment #2 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #1)
> Don't have our bisect seed built with --enable-checking=rtl, so can't bisect
> this easily. But what I see is that this insn is marked as deleted during
> LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70030
--- Comment #6 from Vladimir Makarov ---
Created attachment 38033
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38033&action=edit
A patch
Here is the patch which might solve the problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70030
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70245
--- Comment #5 from Vladimir Makarov ---
(In reply to Vladimir Makarov from comment #4)
>
> I see in peephole a wrong transformation:
>
> 190: cx:SI=dx:SI
> REG_DEAD dx:SI
>95: {cx:SI=cx:SI+[cx:SI];clobber flags:CC;}
>
> into
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70245
--- Comment #4 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #3)
> The difference between r227381 and r227382 on the testcase is:
> --- r227382-1.s1 2016-03-15 20:34:52.699640513 +0100
> +++ r227382-1.s2 2016-03-15 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70219
--- Comment #4 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #3)
> Created attachment 37953 [details]
> gcc6-pr70219.patch
>
> Untested fix. The code had assertion dregno > 0, but I don't see anything
> special on register 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69614
--- Comment #25 from Vladimir Makarov ---
Author: vmakarov
Date: Sat Mar 12 14:56:24 2016
New Revision: 234162
URL: https://gcc.gnu.org/viewcvs?rev=234162&root=gcc&view=rev
Log:
2016-03-12 Vladimir Makarov
PR target/69614
* l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69614
--- Comment #24 from Vladimir Makarov ---
I have a patch and will commit it today.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69614
--- Comment #23 from Vladimir Makarov ---
(In reply to Bernd Schmidt from comment #22)
> Ok Vlad, I'll sign off for tonight and let you have a look.
Ok, Bernd. Have a good weekend.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69614
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70098
--- Comment #5 from Vladimir Makarov ---
(In reply to Anton Blanchard from comment #0)
> I hit the following ICE when building eigen:
>
> # g++ -O3 -c test2.cpp
> test2.cpp: In function ‘void fn3(Matrix)’:
> test2.cpp:59:1: error: unable to gene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70025
--- Comment #7 from Vladimir Makarov ---
Author: vmakarov
Date: Wed Mar 2 01:39:30 2016
New Revision: 233876
URL: https://gcc.gnu.org/viewcvs?rev=233876&root=gcc&view=rev
Log:
2016-03-01 Vladimir Makarov
PR middle-end/70025
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69847
--- Comment #8 from Vladimir Makarov ---
(In reply to Michael Meissner from comment #7)
> The following options were used for LRA code generation:
> -DSPEC_CPU -DNDEBUG -I. -g -mlittle -save-temps=obj -ffast-math -O3
> -mveclibabi=mass -mcpu=pow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57676
--- Comment #10 from Vladimir Makarov ---
(In reply to Jeffrey A. Law from comment #9)
> Vlad, would it make sense to record what insns needed a reload & what insns
> were generated for reloads. Then on the next iteration, if the insns
> needing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69148
--- Comment #6 from Vladimir Makarov ---
Author: vmakarov
Date: Wed Feb 10 18:01:40 2016
New Revision: 233283
URL: https://gcc.gnu.org/viewcvs?rev=233283&root=gcc&view=rev
Log:
2016-02-10 Vladimir Makarov
PR target/69148
* lr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69468
--- Comment #1 from Vladimir Makarov ---
Author: vmakarov
Date: Wed Feb 10 18:01:40 2016
New Revision: 233283
URL: https://gcc.gnu.org/viewcvs?rev=233283&root=gcc&view=rev
Log:
2016-02-10 Vladimir Makarov
PR target/69148
* lr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69671
--- Comment #13 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #9)
> But something like that might remove the flexibility from the register
> allocator.
>
> Wonder why the RA in this case doesn't see that the value loaded into
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69667
--- Comment #8 from Vladimir Makarov ---
(In reply to Michael Meissner from comment #7)
> The error is LRA requires that every register that a constraint targets be a
> valid register for the mode. In this case, the 3 move insns that target
> TF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69195
--- Comment #10 from Vladimir Makarov ---
(In reply to Peter Bergner from comment #9)
> I think we have another bug in addition to the bug where we reuse a register
> that is already in use. We have the rtl below which is used to initialize
> a[
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69461
--- Comment #15 from Vladimir Makarov ---
(In reply to Alexandre Oliva from comment #12)
> Vlad, thanks for taking this over. Let me just point out, just in case you
> missed, that I believe it is important for any register allocator to test
> H
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69461
--- Comment #13 from Vladimir Makarov ---
Author: vmakarov
Date: Wed Feb 3 17:58:34 2016
New Revision: 233107
URL: https://gcc.gnu.org/viewcvs?rev=233107&root=gcc&view=rev
Log:
2016-02-03 Vladimir Makarov
Alexandre Oliva
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69461
--- Comment #11 from Vladimir Makarov ---
I have patches fixing the two issues but when I started to test the patches I
found that LRA actually has >800 additional failures on power8 in comparison
with reload. So I am going to look at this and t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69577
--- Comment #4 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #3)
> This looks like a RA issue or backend bug, perhaps the r215450 change needs
> to be narrowed down?
>
> In *.ira we have:
> (insn 3 2 4 2 (set (reg/v:V2TI 102
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69461
--- Comment #10 from Vladimir Makarov ---
(In reply to Alexandre Oliva from comment #6)
> Created attachment 37498 [details]
> Patch I'm testing to fix the bug
>
> LRA wants harder than reload to avoid creating a stack slot to satisfy insn
> con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69461
--- Comment #9 from Vladimir Makarov ---
(In reply to Alexandre Oliva from comment #6)
> Created attachment 37498 [details]
> Patch I'm testing to fix the bug
>
> LRA wants harder than reload to avoid creating a stack slot to satisfy insn
> cons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69299
--- Comment #8 from Vladimir Makarov ---
Author: vmakarov
Date: Fri Jan 29 18:47:17 2016
New Revision: 232993
URL: https://gcc.gnu.org/viewcvs?rev=232993&root=gcc&view=rev
Log:
2016-01-29 Vladimir Makarov
PR target/69299
* co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69530
--- Comment #14 from Vladimir Makarov ---
(In reply to H.J. Lu from comment #13)
> (In reply to Vladimir Makarov from comment #12)
> > (In reply to H.J. Lu from comment #11)
> > > (In reply to H.J. Lu from comment #10)
> > > > Created attachment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69530
--- Comment #12 from Vladimir Makarov ---
(In reply to H.J. Lu from comment #11)
> (In reply to H.J. Lu from comment #10)
> > Created attachment 37512 [details]
> > A new patch
> >
> > I am testing this now.
>
> No regressions on x86-64. I wil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69447
--- Comment #14 from Vladimir Makarov ---
(In reply to Richard Henderson from comment #13)
> (In reply to Jakub Jelinek from comment #11)
> > Without knowing the lra-remat code at all, I just wonder if subreg_regs
> > needs to be one per the whol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69299
--- Comment #7 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #3)
> Maybe we really need to have two types of memory
> constraints, ones which can be worst case always satisfied by reloading
> their address into an address regi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69447
--- Comment #7 from Vladimir Makarov ---
(In reply to Richard Henderson from comment #6)
> ... except that's not the same set of live ranges
> computed by IRA:
>
>Insn 55(l0): point = 9
>Insn 70(l0): point = 11
>...
>Insn 50(l0):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69195
--- Comment #7 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #4)
> I think I can reproduce it with powerpc64le-linux too (though, have just
> eyeballed assembly, not tried to run it).
> This looks like an IRA or reload problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69377
--- Comment #10 from Vladimir Makarov ---
I believe that the patch I've just committed for PR68990 solves this problem
too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68990
--- Comment #7 from Vladimir Makarov ---
Author: vmakarov
Date: Thu Jan 21 16:01:22 2016
New Revision: 232679
URL: https://gcc.gnu.org/viewcvs?rev=232679&root=gcc&view=rev
Log:
2016-01-21 Vladimir Makarov
PR rtl-optimization/68990
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68990
--- Comment #6 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #4)
> I think the problem is:
> ** Pseudos coalescing #1: **
>
> Coalescing move 5:r91(91)-r103(103) (freq=1)
> Removing move 5 (freq=1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69030
--- Comment #7 from Vladimir Makarov ---
Author: vmakarov
Date: Fri Jan 15 19:33:33 2016
New Revision: 232445
URL: https://gcc.gnu.org/viewcvs?rev=232445&root=gcc&view=rev
Log:
2016-01-15 Vladimir Makarov
PR rtl-optimization/69030
401 - 500 of 879 matches
Mail list logo
