--- Comment #2 from vmakarov at redhat dot com 2008-11-14 03:13 ---
Removing redundant stores could be done by solving a dataflow
problem. Unfortunately such global solution would complicate IR
flattening.
I am going to submit a patch soon which solves the problem by
prohibiting
--- Comment #2 from vmakarov at redhat dot com 2008-11-16 16:14 ---
I waited more than hour to compile it on 1.2Ghz itanium and canceled the
compilation. The problem is in coalescing stack slots. The code was already
rewritten for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37448
--- Comment #7 from vmakarov at redhat dot com 2008-11-24 22:26 ---
This is a latent bug in reload inheritance which IRA triggered. Here
is the important info. r434 was assigned to hard register 2 and r551
was assigned to memory. After insn #1164, r434 and r551 are
synchronized and
--- Comment #2 from vmakarov at redhat dot com 2008-11-27 20:32 ---
The problem was in violation of allocno order in regno_allocno_map list.
This order is very important for many algorithms (allocno info propagation,
conflict propagation and IR flattening). For example,
loop 0
--- Comment #6 from vmakarov at redhat dot com 2008-11-28 22:17 ---
I think, H.J., that is one more latent bug (i already saw several of them) in
reload inheritance optimization triggered by IRA which allocates dx for p69 and
p87 in subsequent insns
47:p65<-p69
151:p87<-mem[..
--- Comment #5 from vmakarov at redhat dot com 2008-12-19 23:30 ---
Eric, thanks for analysis. It saved a lot of my time.
The problem was in wrong final live ranges of a379r452 therefore the conflicts
was not recognized and the pseudos were coalesced. One pseudo is a temporary
pseudo
--- Comment #1 from vmakarov at redhat dot com 2008-12-30 14:33 ---
I don't think that the problem occurred because of transition to IRA. The old
register allocator (-fno-ira) uses about the same size conflict table and peak
virtual memory (it is 9230MB for the old RA on this
--- Comment #6 from vmakarov at redhat dot com 2009-01-12 22:12 ---
Yes, it is an IRA bug. Code processing calls to functions can throw is
lost in IRA.
I'll submit a patch tomorrow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38811
--- Comment #8 from vmakarov at redhat dot com 2009-01-19 00:37 ---
H.J. is right. The problem is that IRA does not reinitialize some of its data
after changing ABI. config/i386/i386.c::ix86_maybe_switch_abi calls only
init_regs (this is the single port which does it). Function
--- Comment #34 from vmakarov at redhat dot com 2009-01-21 03:15 ---
C standard guarantees that automatic variable only with volatile will be
restored after longjmp. Gcc puts volatiles on stack and don't use pseudos for
them. So they will be never shared on stack.
I think the
--- Comment #39 from vmakarov at redhat dot com 2009-01-21 15:39 ---
Yes, right. I should have read the standard itself (not gcc manual which
states "ISO C says that automatic variables that are not declared `volatile'
have undefined values after a `longjmp'")
--- Comment #7 from vmakarov at redhat dot com 2009-01-23 15:58 ---
If it is a problem, it is not a problem of IRA. The usage of the old RA
results in the same abort. Neither the old RA, nor IRA assigns CX to pseudos.
CX is started to be used by reload, so I think it is reload
--- Comment #7 from vmakarov at redhat dot com 2009-06-29 19:44 ---
Paolo, Steven, thanks for looking into this problem. Using the mips approach
is a good idea. Although the costs of FLOAT_REGS and SSE_REGS are the same in
ira-costs.c, IRA should prefer SSE_REGS or FLOAT_REGS
--- Comment #8 from vmakarov at redhat dot com 2009-06-30 21:49 ---
I've checked gcc4.3. It has the same problem. So the reason is not only in
the chosen register class. The both RAs make the pseudo in question
conflicting with all call clobbered hard-regs because it leav
--- Comment #7 from vmakarov at redhat dot com 2009-07-03 12:38 ---
Thanks for reporting this. I started to work on the PR.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40587
--- Comment #8 from vmakarov at redhat dot com 2009-07-03 21:30 ---
The problem was in usage of df_get_live_out in ira.c::build_insn_chain instead
of DF_LR_OUT. Later contains r58 (assigned to st0 register) and it creates
restore insn for st0 after the call and prevents reg-stack
--- Comment #4 from vmakarov at redhat dot com 2007-08-20 18:46 ---
Yes, I belive my RA should manage the situation and use not only b0 register.
But in general, I think we need also register pressure heuristics in insn
scheduler before the register allocation to constrain insn
--- Comment #10 from vmakarov at redhat dot com 2008-08-27 16:33 ---
IRA degradation on rethrow6.C.
This test fails when compiled with -O0. The wrong code looks like
bb:
p93<-ax
p96<-dx
where p93 got dx and p96 got ax. The reason for this is that ax and dx are not
live regs
--- Comment #5 from vmakarov at redhat dot com 2008-08-27 21:59 ---
The problem occurs when a region and its nested region have more 4000
uncolorable allocnos. In this case splay tree is used to deal with the
uncolorable allocnos. Part of uncolorable_allocnos is temporarily stored
--- Comment #12 from vmakarov at redhat dot com 2008-08-29 15:55 ---
Here is the analysis of regressions on pr36222 and pr36246. PR36222 contains
the following code:
p64:V4SI=vec_concat (p66:V2SI, p65:V2SI) dead p66 and p65
xmm0:V2DI=subreg:V2DI (p64:V4SI)
IRA allocates p65, p66, and
--- Comment #4 from vmakarov at redhat dot com 2008-08-29 19:17 ---
I believe that patch
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02279.html
solves the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36539
--- Comment #16 from vmakarov at redhat dot com 2008-08-30 18:52 ---
This is an analysis of the SPEC2006 degradation.
First of all of thanks for reducing the test. I really appreciate
this. Finding it in spec20006 would be very time consuming for me.
The problem looks following
1
--- Comment #5 from vmakarov at redhat dot com 2008-09-01 03:24 ---
It might be an IRA bug.
Could you try two latest patches
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02279.html
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02377.html
I have not got an approval for them yet so they
--- Comment #18 from vmakarov at redhat dot com 2008-09-02 17:29 ---
I've looked at the cgraphbuild.i code and I think something is wrong with
inlining. There are two paths achieving L21 with different stack adjustments.
Here is the code. I marked insns adjusting SP by -> and
--- Comment #20 from vmakarov at redhat dot com 2008-09-02 18:13 ---
Isn't that supposed to be detected by reload?
Yea, right. I missed that. Eric, sorry for to be in hurry with the wrong
response.
I am still working on the issue. I hope to find a solution today or tom
--- Comment #25 from vmakarov at redhat dot com 2008-09-03 15:36 ---
The problem is in sorting insn chains according to their
frequencies to get a better reloads for most frequently executed
insns. This very simple optimization was introduced on IRA branch.
Correct updating
--- Comment #6 from vmakarov at redhat dot com 2008-09-04 01:18 ---
H.J, thanks for the investigation. You are right about REG_LIVE_LENGTH. I'll
submit the patch soon.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37359
--- Comment #6 from vmakarov at redhat dot com 2008-09-04 19:25 ---
First of all, I've check the generated code on Core2 and I found it is not
slower than using movd.
IRA assigns hard registers calculating their costs. It the memory is
cheaper, it assigns memory. The
--- Comment #3 from vmakarov at redhat dot com 2008-09-06 13:45 ---
Function ira_emit.c::update_costs does not take into account that new allocnos
(It is very rare event. New allocnos during code emitting are created only to
break a cycle in register shuffling on the region border) got
--- Comment #11 from vmakarov at redhat dot com 2008-09-08 14:11 ---
Eric, thanks a lot for your analysis. It was very helpful. I've reproduced the
bug.
IRA uses live ranges to find conflicts for spill slots during reload. Live
ranges for r376 were wrong after IR flattening. We
--- Comment #3 from vmakarov at redhat dot com 2008-09-09 22:14 ---
The bug occurs in eliminate_regs_in_insn because it is a first place where
insn generated in caller-save.c is checked. Caller-save.c tries to save
register in its mode SD but there is no insn for this. Functions
--- Comment #9 from vmakarov at redhat dot com 2008-09-10 21:16 ---
There are 66K allocnos and 3M live ranges in function testsuite. Fixing the
problem in IRA will take some time. I hope the patch will be ready in a few
days.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37448
--- Comment #6 from vmakarov at redhat dot com 2008-09-16 16:47 ---
John, thanks for detail analysis. IRA uses 25 for p171 because there is no
recorded conflicts for p171 and hard register 25. The problem was introduced
by recent patch
2008-09-04 Richard Sandiford <[EMAIL PROTEC
--- Comment #7 from vmakarov at redhat dot com 2008-09-17 01:10 ---
The patch I mentioned contains the following code at the end of
ira-lives.c::process_bb_node_lives
for all uses: mark uses as live
for all clobbers: mark them as live
for all clobbers: mark them dead
The r25 are in
--- Comment #2 from vmakarov at redhat dot com 2008-10-08 21:55 ---
Thanks for working on the problem. I am afraid that preventing to use
partially clobbered hard regs for allocnos living through calls is wrong. In
most general case I believe the problem should be fixed in caller
--- Comment #4 from vmakarov at redhat dot com 2008-10-10 20:16 ---
I am sorry that I was silent. I am working on this. Please don't worry,
Andreas. Simply I have a lot of IRA bugs. I hope the problem will be solved on
next week.
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #3 from vmakarov at redhat dot com 2008-10-14 19:42 ---
I've checked the old RA. It does not assigned partially clobbered hard
register because it is done only when non partially clobbered hard regs were
tried first. Sh has a lot of such registers therefore the chan
--- Comment #5 from vmakarov at redhat dot com 2008-10-14 19:50 ---
Updating of total_conflict_hard_regs in ira-build.c::ira_flattening was
completely wrong. So I rewrite the calculation of total_conflict_hard_regs and
total_no_stack_reg_p. It is now done from the scratch. The code
--- Comment #2 from vmakarov at redhat dot com 2008-10-22 13:51 ---
The problem is in that hard regs (like r10) which have class GENERAL_REGS (from
REGNO_REG_CLASS) are translated into ACR_REGS. Such translation results in
wrong register pressure calculation for ACR_REGS and failed
--- Comment #9 from vmakarov at redhat dot com 2008-10-22 14:00 ---
The performance status is still the same. But I am working on it and actually
biggest part of my work time (about 90%) I spent on performance problems
particular this one. They are the most hard to solve.
--
http
--- Comment #2 from vmakarov at redhat dot com 2008-10-24 22:21 ---
Andreas, thanks for the useful preliminary analysis. The problem is a bit
different than 37674. Loop4 contains Loop5 and there is an exit from Loop5
right to Loop1 and store (from hard reg in L5 to memory in L1) is
--- Comment #8 from vmakarov at redhat dot com 2008-11-10 16:12 ---
H.J., thanks for finding the problem and reducing the test case.
The problem could be solved by using extended register coalescing. Now IRA
coalesces only move insns (-fira-coalesce). But unfortunately usage of
--- Comment #6 from vmakarov at redhat dot com 2008-11-11 15:22 ---
Sorry, Kaz. I missed this PR. I've just found it after Bernd's email.
I don't think it is a right solution or stable workaround. In fact all
pseudos (551, 289, 288) involved in 2 wrong insns got
--- Comment #1 from vmakarov at redhat dot com 2008-04-02 18:34 ---
I've just fixed it on ira branch. The problem was in an assert requiring
nonzero number of references for an allocno. I permitted to have zero number
of references.
I've just realized that such situ
--- Comment #1 from vmakarov at redhat dot com 2008-04-08 02:39 ---
I think the problem has been solved by
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg00469.html
I need some time to check it because my sun machine is too slow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35841
--- Comment #2 from vmakarov at redhat dot com 2008-04-09 03:02 ---
It is fixed by
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg00750.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35875
--- Comment #11 from vmakarov at redhat dot com 2009-02-03 14:48 ---
I have a patch (a new spill heuristic) which makes facerec even faster with IRA
on power6. The patch is in
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00368.html
Unfortunately the new spill heuristic results in
--- Comment #7 from vmakarov at redhat dot com 2009-02-03 15:06 ---
I don't see anymore code difference (only a bit different hard registers are
used) on mentioned functions for code generated with the old RA and IRA.
Probably it was fixed with a fix in regmove which was submitted
--- Comment #1 from vmakarov at redhat dot com 2009-03-11 16:57 ---
Jakub, how is about the following patch. Is it ok for you? I mean correct
user variable identification.
2009-03-11 Vladimir Makarov
PR debug/39432
* ira-int.h (struct allocno): Fix comment for
--- Comment #3 from vmakarov at redhat dot com 2009-03-11 17:10 ---
Thanks, Richard.
So instead of "DECL_NAME (decl) != NULL" I should use "! DECL_ARTIFICIAL
(decl)". Right?
Ok, I'll test the new patch then and send it for approval after testing.
--
ht
--- Comment #5 from vmakarov at redhat dot com 2009-03-11 17:28 ---
As for DECL_HARD_REGISTER, such decl regs are never considered by IRA for
allocation. So I think there is no necessity to check them here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39432
--- Comment #12 from vmakarov at redhat dot com 2009-03-23 17:04 ---
I started my work on register pressure sensitive insn scheduling recently.
This bug will be fixed as byproduct of this work. I hope the code will be
available for gcc4.5.
--
http://gcc.gnu.org/bugzilla
--- Comment #3 from vmakarov at redhat dot com 2009-03-25 21:05 ---
Thanks for reporting this.
The compiler is broken on gcc_assert in the following code
+ else if ((code == PRE_INC || code == PRE_DEC
+ || code == POST_INC || code == POST_DEC
--- Comment #3 from vmakarov at redhat dot com 2009-04-03 21:36 ---
Steve, thanks for tracking it down. I did not reproduce the bug on x86-hppa
cross compiler. Therefore finding the patch is important to me.
This is not a single problem introduced by the patch. Another one is PR39607
--- Comment #1 from vmakarov at redhat dot com 2009-04-15 21:49 ---
The compiler is broken in IRA on this test because ira_register_move_cost is
not initialized for DFmode, AREG, GENERAL_REGS.
It is supposed that all necessary elements of this array are initialized in
ira-costs.c by
--- Comment #4 from vmakarov at redhat dot com 2009-04-16 17:35 ---
Yes, I do. Although I feel it is a safe patch, I'd like to check it on trunk
first for a week.
Jakub, please let me know if you can not wait that for a week.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39762
--- Comment #3 from vmakarov at redhat dot com 2009-04-22 20:37 ---
Actually YARA did not have a rematerialization as IRA. Reload has a primitive
rematerialization of constant values.
Although about 5 years I did implemented a register pressure relief through
rematerialization which
--- Comment #6 from vmakarov at redhat dot com 2009-04-23 17:27 ---
Jakub, thanks for reducing the test. I'll investigate this bug more.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39856
--- Comment #7 from vmakarov at redhat dot com 2009-04-24 15:53 ---
In gcc4.4 we have before reg-stack.c
(insn 96 82 97 4 /home/vmakarov/build/bb.ii:8 (parallel [
(set (mem/c:SI (plus:SI (reg/f:SI 7 sp)
(const_int 28 [0x1c])) [0 S4 A32
--- Comment #4 from vmakarov at redhat dot com 2009-04-26 17:38 ---
The first test case is just an example that RA is a heuristic
solution. Even heuristic algorithm which works worse in average
sometimes can generate a better solution than ones working better in
average.
Here is IRA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56195
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56195
--- Comment #7 from Vladimir Makarov 2013-02-07
20:08:47 UTC ---
(In reply to comment #6)
> Actually, that one doesn't really work, because we have pseudo rather than
> hard
> reg at that point, which will never simplify.
>
> With this
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56148
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56847
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56999
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56847
--- Comment #9 from Vladimir Makarov 2013-04-18
20:10:34 UTC ---
I am still working on this. I have a patch solving the problem but I'd like to
try other solutions too.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57018
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57046
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57131
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55278
--- Comment #11 from Vladimir Makarov ---
I don't see a code degradation because of LRA. Here what I got using gcc4.8
branch compiler with options -O3 -finline-functions -D_REENTRANT
-Wno-long-long -W -Wall -fPIC -fvisibility=hidden on Xeon X56
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55050
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55092
--- Comment #2 from Vladimir Makarov 2012-10-26
22:49:23 UTC ---
LRA reuses stack memory much better than reload (in all modes but especially
in -O0). May be that is the reason of the var-tracking problem.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55092
--- Comment #4 from Vladimir Makarov 2012-10-26
22:57:38 UTC ---
(In reply to comment #2)
> LRA reuses stack memory much better than reload (in all modes but especially
> in -O0). May be that is the reason of the var-tracking problem.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54402
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55141
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55247
Vladimir Makarov changed:
What|Removed |Added
CC||ubizjak at gmail dot com
---
--- Comment #2 from vmakarov at redhat dot com 2009-08-17 15:13 ---
Thanks for reporting this bug.
I've looked at the code and I think the patch in question probably triggered
some latent reload bug. All wrong code transformations are done in reload.
Although I think assigning
--- Comment #19 from vmakarov at redhat dot com 2009-09-02 16:14 ---
As I wrote, implementing register pressure-sensitive insn scheduling needs to
look at all insns (ready or not) with resolved dependencies. In an extreme
cases, such insns could b 10-100 more than the ready ones
--- Comment #21 from vmakarov at redhat dot com 2009-09-02 17:11 ---
I see. I though you compared '-fschedule-insns' and '-fschedule-insns
-fsched-pressure'.
Your numbers shows the same as I reported for SPEC2000. The -fsched-pressure
adds upto 3% compiler time
--- Comment #12 from vmakarov at redhat dot com 2009-09-03 15:01 ---
It looks as an old IRA rare hidden bug which was triggered by the new patches.
I check IRA on valgrind on a lot of tests but never saw it.
Update_equiv_reg imported from the old RA uses pseudo class but it was never
--- Comment #4 from vmakarov at redhat dot com 2009-09-03 21:40 ---
Oh well, another haifa-scheduler integration issue after so many years to
integrate it into GCC. It looks like the original haifa-scheduler treated
calls as always returning.
I think you should use
--- Comment #38 from vmakarov at redhat dot com 2009-09-04 15:25 ---
Finally, I think I found what is the reason for all these bootstrap failures.
I've changed code dealing with register preferences. Now regnfo::reg_pref is
not null from the start and some passes (now it is re
--- Comment #39 from vmakarov at redhat dot com 2009-09-04 16:05 ---
Uros, Eric, Rainer, could somebody of you check the following patch works. I
tried to reproduce the bug on several available to me machines since yesterday
night and I failed.
Index: ira.c
--- Comment #50 from vmakarov at redhat dot com 2009-09-06 13:46 ---
I tried several times to reproduce it without success. It is suspicious that
only gnat generated files are different. May be the bug is in gnat specific
files.
I found that gnat1 generated by a system compiler
--- Comment #14 from vmakarov at redhat dot com 2009-10-06 21:59 ---
IRA does not create a conflict for p66 and p67 (in function triangle). One
pseudo is earlyclobber. They should have a conflict. Therefore p67 gets wrong
hard register and reload fixes this by generation of
--- Comment #8 from vmakarov at redhat dot com 2009-10-30 21:57 ---
Unfortunately, not yet because I had some failures after applying the patch. I
postponed work on this but now I have time to continue the work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41171
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57293
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57462
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57604
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57960
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51041
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57293
--- Comment #5 from Vladimir Makarov ---
I've started this work. But unfortunately, i have too many things on my plate
now. I was too optimistic. Now I can say only that I am planning to fix it on
stage1 (so the fix should be in gcc4.9).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58048
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58110
--- Comment #3 from Vladimir Makarov ---
Thanks, Ondrej and Jan. GCC with reload generates code with the same problem.
I mentioned on RA BOF that we should look at postreload.c and postreload-gcse.c
to figure out what should and can be removed a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58166
--- Comment #6 from Vladimir Makarov ---
On 13-08-22 10:11 AM, rearnsha at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58166
>
> --- Comment #5 from Richard Earnshaw ---
> (In reply to Jay Foad from comment #3)
>> I've bi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58419
--- Comment #3 from Vladimir Makarov ---
(In reply to Zhendong Su from comment #2)
> (In reply to H.J. Lu from comment #1)
> > It is caused by r202468.
>
> So it may have been a dup of 58418?
Yes, it is a duplication.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57915
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49936
--- Comment #2 from Vladimir Makarov 2011-08-16
02:05:02 UTC ---
After thorough investigation of the problem I came to a conclusion that fixing
it in IRA requires to form regions on pseudo mode usage too (besides just
register pressure). Allocno
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49936
--- Comment #4 from Vladimir Makarov 2011-08-16
17:27:12 UTC ---
(In reply to comment #3)
> Hmmm. Is it possible to make the INT/memory/whatever decision based on move
> costs? Or use a target hook to supply a hint about what to do?
I think I
1 - 100 of 179 matches
Mail list logo
