[Bug rtl-optimization/55247] [4.8 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)

2012-11-09 Thread vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55247 Vladimir Makarov vmakarov at redhat dot com changed: What|Removed |Added CC

[Bug rtl-optimization/55330] [4.8 Regression] ICE: Maximum number of LRA constraint passes is achieved (15) on gfortran.dg/actual_array_constructor_1.f90

2012-11-16 Thread vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55330 Vladimir Makarov vmakarov at redhat dot com changed: What|Removed |Added CC

[Bug rtl-optimization/55458] [4.8 Regression] ICE: in assign_by_spills, at lra-assigns.c:1212 with -fPIC -m32 and simple asm volatile

2012-11-27 Thread vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55458 Vladimir Makarov vmakarov at redhat dot com changed: What|Removed |Added CC

[Bug rtl-optimization/55829] [4.8 Regression] ICE: in curr_insn_transform, at lra-constraints.c:3069 with -msse3

2013-01-08 Thread vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55829 Vladimir Makarov vmakarov at redhat dot com changed: What|Removed |Added CC

[Bug rtl-optimization/55153] [4.8 Regression] ICE: in begin_move_insn, at sched-ebb.c:205 with -fsched2-use-superblocks and __builtin_prefetch

2013-01-14 Thread vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55153 Vladimir Makarov vmakarov at redhat dot com changed: What|Removed |Added CC

[Bug rtl-optimization/56069] [4.6/4.7/4.8 Regression] RA pessimization

2013-01-22 Thread vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56069 Vladimir Makarov vmakarov at redhat dot com changed: What|Removed |Added CC

[Bug regression/55050] Regression test failure slp-21.c on arm-linux-gnueabi

2012-10-24 Thread vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55050 Vladimir Makarov vmakarov at redhat dot com changed: What|Removed |Added CC

[Bug rtl-optimization/55092] [4.8 Regression] LRA doesn't scale

2012-10-26 Thread vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55092 --- Comment #2 from Vladimir Makarov vmakarov at redhat dot com 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.

[Bug rtl-optimization/55092] [4.8 Regression] LRA doesn't scale

2012-10-26 Thread vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55092 --- Comment #4 from Vladimir Makarov vmakarov at redhat dot com 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

[Bug debug/54402] [4.8 Regression] var-tracking does not scale

2012-10-26 Thread vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54402 Vladimir Makarov vmakarov at redhat dot com changed: What|Removed |Added CC

[Bug rtl-optimization/55141] [4.8 Regression] wrong code with -fno-split-wide-types

2012-11-07 Thread vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55141 Vladimir Makarov vmakarov at redhat dot com changed: What|Removed |Added CC

[Bug rtl-optimization/56195] [4.8 Regression] Error: incorrect register `%rdi' used with `l' suffix (at -O2)

2013-02-07 Thread vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56195 Vladimir Makarov vmakarov at redhat dot com changed: What|Removed |Added CC

[Bug rtl-optimization/56195] [4.8 Regression] Error: incorrect register `%rdi' used with `l' suffix (at -O2)

2013-02-07 Thread vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56195 --- Comment #7 from Vladimir Makarov vmakarov at redhat dot com 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

[Bug inline-asm/56148] [4.8 Regression] inline asm matching constraint with different mode

2013-02-12 Thread vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56148 Vladimir Makarov vmakarov at redhat dot com changed: What|Removed |Added CC

[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling

2013-02-14 Thread vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 Vladimir Makarov vmakarov at redhat dot com changed: What|Removed |Added CC

[Bug rtl-optimization/56847] [4.8/4.9 Regression] '-fpie' triggers - internal compiler error: in gen_add2_insn, at optabs.c:4705

2013-04-05 Thread vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56847 Vladimir Makarov vmakarov at redhat dot com changed: What|Removed |Added CC

[Bug rtl-optimization/56999] [4.8/4.9 Regression] LRA caused miscompilation of xulrunner

2013-04-18 Thread vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56999 Vladimir Makarov vmakarov at redhat dot com changed: What|Removed |Added CC

[Bug rtl-optimization/56847] [4.8/4.9 Regression] '-fpie' triggers - internal compiler error: in gen_add2_insn, at optabs.c:4705

2013-04-18 Thread vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56847 --- Comment #9 from Vladimir Makarov vmakarov at redhat dot com 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.

[Bug target/57018] [4.8/4.9 Regression] Miscompilation of bison 2.7.1 under -Os -fomit-frame-pointer

2013-04-22 Thread vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57018 Vladimir Makarov vmakarov at redhat dot com changed: What|Removed |Added CC

[Bug rtl-optimization/57046] [4.8/4.9 Regression] wrong code generated by gcc 4.8.0 on i686

2013-04-23 Thread vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57046 Vladimir Makarov vmakarov at redhat dot com changed: What|Removed |Added CC

[Bug rtl-optimization/57131] [4.8/4.9 Regression] Wrong register assignment?

2013-05-01 Thread vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57131 Vladimir Makarov vmakarov at redhat dot com changed: What|Removed |Added CC

[Bug rtl-optimization/55278] [4.8/4.9 Regression] Botan performance regressions apparently due to LRA

2013-05-09 Thread vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55278 --- Comment #11 from Vladimir Makarov vmakarov at redhat dot com --- 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

[Bug target/57293] [4.8/4.9 Regression] not needed frame pointers on IA-32 (performance regression?)

2013-05-16 Thread vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57293 Vladimir Makarov vmakarov at redhat dot com changed: What|Removed |Added CC||vmakarov

[Bug rtl-optimization/53125] Very slow register allocation on SPARC

2012-04-28 Thread vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53125 --- Comment #2 from Vladimir Makarov vmakarov at redhat dot com 2012-04-29 00:08:54 UTC --- I'll look at this PR in a week.

[Bug rtl-optimization/53125] Very slow register allocation on SPARC

2012-05-10 Thread vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53125 --- Comment #3 from Vladimir Makarov vmakarov at redhat dot com 2012-05-10 18:30:19 UTC --- I've tried a recent trunk on gcc63 of the compiler farm with -O0. The compilation takes about 300sec. I checked also gcc-4.3 (this last version

[Bug rtl-optimization/57462] ira-costs considers only a single register at a time

2013-05-31 Thread vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57462 Vladimir Makarov vmakarov at redhat dot com changed: What|Removed |Added CC||vmakarov

[Bug bootstrap/57604] LRA related bootstrap comparison failure on s390x --with-arch=zEC12

2013-06-17 Thread vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57604 Vladimir Makarov vmakarov at redhat dot com changed: What|Removed |Added CC||vmakarov

[Bug rtl-optimization/57960] S/390: LRA ICE building glibc

2013-07-24 Thread vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57960 Vladimir Makarov vmakarov at redhat dot com changed: What|Removed |Added CC||vmakarov

[Bug rtl-optimization/51041] g++ strange optimisation behaviour

2013-07-29 Thread vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51041 Vladimir Makarov vmakarov at redhat dot com changed: What|Removed |Added CC||vmakarov

[Bug target/57293] [4.8/4.9 Regression] not needed frame pointers on IA-32 (performance regression?)

2013-08-04 Thread vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57293 --- Comment #5 from Vladimir Makarov vmakarov at redhat dot com --- 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

[Bug rtl-optimization/58048] [4.8/4.9 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)

2013-08-08 Thread vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58048 Vladimir Makarov vmakarov at redhat dot com changed: What|Removed |Added CC||vmakarov

[Bug target/58110] Useless GPR push and pop when only xmm registers are used.

2013-08-09 Thread vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58110 --- Comment #3 from Vladimir Makarov vmakarov at redhat dot com --- 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

[Bug target/58166] ARMv5: poor register allocation in function containing smull instruction

2013-08-25 Thread vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58166 --- Comment #6 from Vladimir Makarov vmakarov at redhat dot com --- 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 rearnsha at gcc dot gnu.org

[Bug middle-end/58419] [4.9 Regression] wrong code at -O3 on x86_64-linux-gnu in 32-bit mode

2013-09-16 Thread vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58419 --- Comment #3 from Vladimir Makarov vmakarov at redhat dot com --- (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.

[Bug rtl-optimization/57915] [4.8/4.9 Regression] ICE in set_address_disp, at rtlanal.c:5537

2013-09-20 Thread vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57915 Vladimir Makarov vmakarov at redhat dot com changed: What|Removed |Added CC||vmakarov

[Bug target/38811] [4.4 Regression] internal compiler error: in compensate_edge, at reg-stack.c:2754

2009-01-12 Thread vmakarov at redhat dot com
--- 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

[Bug c/38869] [4.4 Regression] valgrind find problem with -O -mtune=generic

2009-01-18 Thread vmakarov at redhat dot com
--- 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

[Bug middle-end/38587] [4.4 Regression] psim miscompiled #2

2009-01-20 Thread vmakarov at redhat dot com
--- 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 code

[Bug middle-end/38587] [4.4 Regression] psim miscompiled #2

2009-01-21 Thread vmakarov at redhat dot com
--- 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'). That is good that Andrew

[Bug target/38941] CX isn't preserved with shift

2009-01-23 Thread vmakarov at redhat dot com
--- 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

[Bug rtl-optimization/37534] [4.4 Regression] IRA causes 17% degradation in 187.facerec benchmark

2009-02-03 Thread vmakarov at redhat dot com
--- 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

[Bug target/37437] [4.4 regression] speed regression

2009-02-03 Thread vmakarov at redhat dot com
--- 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

[Bug debug/39432] [4.4 Regression] gdb.base/store.exp failures

2009-03-11 Thread vmakarov at redhat dot com
--- 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 vmaka...@redhat.com PR debug/39432 * ira-int.h (struct allocno

[Bug debug/39432] [4.4 Regression] gdb.base/store.exp failures

2009-03-11 Thread vmakarov at redhat dot com
--- 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. -- http://gcc.gnu.org/bugzilla

[Bug debug/39432] [4.4 Regression] gdb.base/store.exp failures

2009-03-11 Thread vmakarov at redhat dot com
--- 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

[Bug rtl-optimization/24319] [4.2/4.3/4.4 regression] amd64 register spill error with -fschedule-insns

2009-03-23 Thread vmakarov at redhat dot com
--- 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

[Bug rtl-optimization/39522] [4.4 Regression] fix for PR37514 gives FAIL: gcc.c-torture/execute/stdarg-3.c compilation, -O3 -fomit-frame-pointer -funroll-loops (internal compiler error)

2009-03-25 Thread vmakarov at redhat dot com
--- 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

[Bug target/32855] [4.3 Regression] g++.dg/tree-ssa/pr28003.C

2007-08-20 Thread vmakarov at redhat dot com
--- 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

[Bug target/33624] [4.3 Regression] ICE in speculate_insn, at haifa-sched.c:4053

2007-11-02 Thread vmakarov at redhat dot com
--- Comment #4 from vmakarov at redhat dot com 2007-11-02 15:20 --- I've tried GfxFont.ii and the reduced test on Itanium-2 under RHEL 4.4 for today gcc (revision 129849). There are no crashes anymore. Everything looks fine. Probably, latest Maxim Kuvyrkov's patches fixed

[Bug target/33624] [4.3 Regression] ICE in speculate_insn, at haifa-sched.c:4053

2007-11-02 Thread vmakarov at redhat dot com
--- Comment #3 from vmakarov at redhat dot com 2007-11-02 13:23 --- I'll look at this. -- vmakarov at redhat dot com changed: What|Removed |Added CC

[Bug target/33624] [4.3 Regression] ICE in speculate_insn, at haifa-sched.c:4053

2007-11-02 Thread vmakarov at redhat dot com
--- Comment #8 from vmakarov at redhat dot com 2007-11-02 17:54 --- I've checked patch http://gcc.gnu.org/viewcvs?root=gccview=revrev=129378 and as Jakub I confirm too that the patch fixed the bug. So it is really fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33624

[Bug bootstrap/39631] f951 seg faults while building libgfortran

2009-04-03 Thread vmakarov at redhat dot com
--- 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

[Bug rtl-optimization/39762] [4.4/4.5 Regression] IRA ICE with -msoft-float

2009-04-15 Thread vmakarov at redhat dot com
--- 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

[Bug tree-optimization/39839] [4.3/4.4/4.5 regression] loop invariant motion causes stack spill

2009-04-22 Thread vmakarov at redhat dot com
--- 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

[Bug target/39856] [4.4 Regression] ICE in subst_stack_regs_pat, at reg-stack.c:1386

2009-04-23 Thread vmakarov at redhat dot com
--- 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

[Bug rtl-optimization/39836] [4.4/4.5 regression] unoptimal code generated

2009-04-26 Thread vmakarov at redhat dot com
--- 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

[Bug target/37488] register allocation spills floats needlessly

2009-06-29 Thread vmakarov at redhat dot com
--- 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

[Bug target/37488] register allocation spills floats needlessly

2009-06-30 Thread vmakarov at redhat dot com
--- 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 leaves

[Bug target/40587] [4.4/4.5 Regression] Revision 139590 caused ICE in emit_swap_insn at reg-stack.c:827

2009-07-03 Thread vmakarov at redhat dot com
--- 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

[Bug target/40587] [4.4/4.5 Regression] Revision 139590 caused ICE in emit_swap_insn at reg-stack.c:827

2009-07-03 Thread vmakarov at redhat dot com
--- 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

[Bug rtl-optimization/41171] register allocator undoing optimal schedule

2009-10-30 Thread vmakarov at redhat dot com
--- 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

[Bug target/37633] [4.4 Regression] wrong register use on sh64

2008-10-08 Thread vmakarov at redhat dot com
--- 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

[Bug middle-end/37674] [4.4 Regression] Bootstrap failure due to miscompilation of genattrtab

2008-10-10 Thread vmakarov at redhat dot com
--- 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.cgi?id

[Bug target/37633] [4.4 Regression] wrong register use on sh64

2008-10-14 Thread vmakarov at redhat dot com
--- 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 chance

[Bug middle-end/37674] [4.4 Regression] Bootstrap failure due to miscompilation of genattrtab

2008-10-14 Thread vmakarov at redhat dot com
--- 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

[Bug middle-end/37813] assert with IRA_COVER_CLASSES with singleton

2008-10-22 Thread vmakarov at redhat dot com
--- 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

[Bug rtl-optimization/37534] [4.4 Regression] IRA causes 17% degradation in 187.facerec benchmark

2008-10-22 Thread vmakarov at redhat dot com
--- 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

[Bug middle-end/37884] [4.4 Regression] Bootstrap failure due to miscompilation of tree-vrp.c

2008-10-24 Thread vmakarov at redhat dot com
--- 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

[Bug rtl-optimization/37948] [4.4 Regression] IRA generates slower code

2008-11-10 Thread vmakarov at redhat dot com
--- 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

[Bug rtl-optimization/37514] [4.4 Regression] Wrong code generated for 20021120-1.c with -O3 -fomit-frame-pointer on sh4

2008-11-11 Thread vmakarov at redhat dot com
--- 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 different stack

[Bug bootstrap/37859] Bootstrap failure on mips64octeon-unknown-linux-gnu

2008-11-13 Thread vmakarov at redhat dot com
--- 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

[Bug middle-end/37790] limits-fnargs.c takes very long time to compile at -O2

2008-11-16 Thread vmakarov at redhat dot com
--- 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

[Bug rtl-optimization/37514] [4.4 Regression] Wrong code generated for 20021120-1.c with -O3 -fomit-frame-pointer on sh4

2008-11-24 Thread vmakarov at redhat dot com
--- 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

[Bug rtl-optimization/38280] [4.4 regression] Revision 142207 breaks 416.gamess/481.wrf in SPEC CPU 2006

2008-11-27 Thread vmakarov at redhat dot com
--- 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

[Bug rtl-optimization/38272] [4.4 Regression] Revision 142207 caused libgomp.fortran/threadprivate2.f90

2008-11-28 Thread vmakarov at redhat dot com
--- 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[...]. I am

[Bug rtl-optimization/38495] [4.4 Regression] ACATS tests cxa4004 cxa4005 cxa4026 fail

2008-12-19 Thread vmakarov at redhat dot com
--- 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

[Bug rtl-optimization/38583] [4.4 Regression] ira memory explosion

2008-12-30 Thread vmakarov at redhat dot com
--- 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 case

[Bug tree-optimization/35805] [ira] error in start_allocno_priorities, at ira-color.c:1806

2008-04-02 Thread vmakarov at redhat dot com
--- 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 situations

[Bug rtl-optimization/35841] [ira] segfault while building libgcc

2008-04-07 Thread vmakarov at redhat dot com
--- 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

[Bug rtl-optimization/35875] [ira] Error in process_bb_node_lives, at ira-lives.c:680

2008-04-08 Thread vmakarov at redhat dot com
--- 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

[Bug target/36028] [IRA] ICE in reload_cse_simplify_operands

2008-05-06 Thread vmakarov at redhat dot com
--- Comment #3 from vmakarov at redhat dot com 2008-05-06 19:11 --- Thanks for decreasing the test case. The problem was in wrong mode of save/restore stack slot when it was reused for another hard register. It resulted in generation of wrong save/restore insn and after

[Bug tree-optimization/26854] Inordinate compile times on large routines

2008-05-18 Thread vmakarov at redhat dot com
--- Comment #66 from vmakarov at redhat dot com 2008-05-19 02:00 --- The problem with IRA was in too many allocnos to be chosen for spilling. The most tome was spent in choosing the best allocno for spilling. The patch solving the problem is coming. -- http://gcc.gnu.org/bugzilla

[Bug tree-optimization/26854] Inordinate compile times on large routines

2008-05-18 Thread vmakarov at redhat dot com
--- Comment #68 from vmakarov at redhat dot com 2008-05-19 02:08 --- The patch solving IRA problem is described in http://gcc.gnu.org/ml/gcc-patches/2008-05/msg01093.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854

[Bug target/36450] [IRA] ICE in insert_restore with GET_MODE_ALIGNMENT mem

2008-06-09 Thread vmakarov at redhat dot com
--- Comment #3 from vmakarov at redhat dot com 2008-06-09 17:22 --- The test is ok. Thanks. The problem is very simple. The assertion causing abort is simply wrong. I reproduced the same bug for the old register allocator. I just used wetstone for this. The assertion is wrong

[Bug rtl-optimization/24319] [4.3/4.4/4.5 regression] amd64 register spill error with -fschedule-insns

2009-09-02 Thread vmakarov at redhat dot com
--- 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

[Bug rtl-optimization/24319] [4.3/4.4/4.5 regression] amd64 register spill error with -fschedule-insns

2009-09-02 Thread vmakarov at redhat dot com
--- 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 (for power6) on x86

[Bug bootstrap/41241] [4.5 regression] bootstrap comparison failure

2009-09-03 Thread vmakarov at redhat dot com
--- 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

[Bug rtl-optimization/41239] Scheduler reorders division by zero before a call that might not return

2009-09-03 Thread vmakarov at redhat dot com
--- 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

[Bug bootstrap/41241] [4.5 regression] bootstrap comparison failure

2009-09-04 Thread vmakarov at redhat dot com
--- 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 regmove

[Bug bootstrap/41241] [4.5 regression] bootstrap comparison failure

2009-09-04 Thread vmakarov at redhat dot com
--- 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

[Bug bootstrap/41241] [4.5 regression] bootstrap comparison failure

2009-09-06 Thread vmakarov at redhat dot com
--- 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

[Bug middle-end/22072] bizarre code for int*int/2 for -Os

2009-10-06 Thread vmakarov at redhat dot com
--- 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

[Bug rtl-optimization/36672] IRA + -fno-pic ICE in emit_swap_insn, at reg-stack.c:829

2008-07-07 Thread vmakarov at redhat dot com
--- Comment #2 from vmakarov at redhat dot com 2008-07-07 18:07 --- Incorrect order in reload insn chain results in wrong reload inheritance which crashed the compiler. The patch solving the problem will follow soon. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36672

[Bug rtl-optimization/36673] IRA -O3 -fno-pic ICE in save_con_fun_n, at caller-save.c:1389

2008-07-07 Thread vmakarov at redhat dot com
--- Comment #3 from vmakarov at redhat dot com 2008-07-07 18:21 --- The case when saving mode or saving pseudo are different in the data-flow equation was missed when the save/restore placement optimization was written. Fortunately, the case was catched by the assertion. The patch

[Bug rtl-optimization/36663] IRA ICE in save_call_clobbered_regs at caller-save.c:1949

2008-07-07 Thread vmakarov at redhat dot com
--- Comment #3 from vmakarov at redhat dot com 2008-07-07 18:30 --- Liveness info was missed in data-flow equation calculation for set free when the save/restore placement optimization was written. Fortunately, the case was catched by an assertion. The patch solving the problem has

[Bug middle-end/37243] [4.4 Regression] Revision 139590 caused many regressions

2008-08-27 Thread vmakarov at redhat dot com
--- 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

[Bug rtl-optimization/37251] [4.4 Regression] ICE with ira: delete_allocno_from_bucket

2008-08-27 Thread vmakarov at redhat dot com
--- 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

[Bug middle-end/37243] [4.4 Regression] IRA causes wrong code generation

2008-08-29 Thread vmakarov at redhat dot com
--- 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

[Bug target/36539] [4.4 regression] IRA doesn't allocate asm output being returned to eax

2008-08-29 Thread vmakarov at redhat dot com
--- 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

[Bug middle-end/37243] [4.4 Regression] IRA causes wrong code generation

2008-08-30 Thread vmakarov at redhat dot com
--- 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

  1   2   >