Re: PR63633: May middle-end come up width hard regs for insn expanders?

On 20/04/15 06:27 PM, Steven Bosscher wrote: On Mon, Apr 20, 2015 at 10:11 PM, Vladimir Makarov wrote: I might be wrong but I think you have a bloated code because you use scratches. I already told several times that usage of scratch is always a bad idea. It was a bad idea for an old RA and

Re: PR63633: May middle-end come up width hard regs for insn expanders?

On 21/04/15 02:04 AM, Segher Boessenkool wrote: On Tue, Apr 21, 2015 at 12:27:40AM +0200, Steven Bosscher wrote: On Mon, Apr 20, 2015 at 10:11 PM, Vladimir Makarov wrote: I might be wrong but I think you have a bloated code because you use scratches. I already told several times that usage

Re: PR63633: May middle-end come up width hard regs for insn expanders?

On 22/04/15 10:39 AM, Georg-Johann Lay wrote: Attached is a C test program which produces fine results with $ avr-gcc -S -O2 -mmcu=atmega8 Also attached is a respective patch against the trunk avr backend that indicates the transition from clobbers to hard-regs-by-constraint. I don't actu

Re: Compiler warnings while compiling gcc with clang‏ -- clang compilation speed on building GCC

On 05/05/2015 12:42 AM, Aditya K wrote: I was able to successfully bootstrap gcc by using clang as the stage 1 compiler. I configured gcc using the following arguments. ../configure --disable-multilib --enable-bootstrap --enable-languages=c,c++ CC=/work/llvm/install-release/bin/clang CXX=/wor

Re: [i386] Scalar DImode instructions on XMM registers

On 05/18/2015 08:13 AM, Ilya Enkovich wrote: 2015-05-06 17:18 GMT+03:00 Ilya Enkovich : 2015-04-25 4:32 GMT+03:00 Jan Hubicka : Hi, I am adding Vladimir and Richard into CC. I tried to solve similar problem with FP math years ago by having -mfpmath=sse,i387. The idea was to allow use of i387 re

Re: [i386] Scalar DImode instructions on XMM registers

On 20/05/15 04:17 AM, Ilya Enkovich wrote: On 19 May 11:22, Vladimir Makarov wrote: On 05/18/2015 08:13 AM, Ilya Enkovich wrote: 2015-05-06 17:18 GMT+03:00 Ilya Enkovich : Hi Vladimir, Could you please comment on this? Ilya, I think that the idea is worth to try but results might be

Re: [i386] Scalar DImode instructions on XMM registers

On 05/21/2015 05:54 AM, Ilya Enkovich wrote: Thanks. For me it looks like an inheritance bug. It is really hard >to fix the bug w/o the source code. Could you send me your patch in >order I can debug RA with it to investigate more. > Sure! Here is a patch and a testcase. I applied patch to r

Re: Should "can_create_pseudo_p" check "lra_in_progress"?

On 10/05/2018 01:19 PM, Jeff Law wrote: On 10/5/18 7:04 AM, Andrew Stubbs wrote: I just tracked down a "reload" bug and was very surprised to find that can_create_pseudo_p doesn't return false during register allocation when using LRA. It's still defined like this: #define can_create_pseudo_p(

Re: LRA reload produces invalid insn

On 11/01/2018 08:25 PM, Paul Koning wrote: I'm running the testsuite on the pdp11 target, and I get a failure when using LRA that works correctly with the old allocator. The issue is that LRA is producing an insn that is invalid (it violates the constraints stated in the insn definition). Th

Re: Indirect memory addresses vs. lra

On 2019-08-04 3:18 p.m., John Darrington wrote: I'm trying to write a back-end for an architecture (s12z - the ISA you can download from [1]). This arch accepts indirect memory addresses. That is to say, those of the form (mem (mem (...))) and although my TARGET_LEGITIMATE_ADDRESS function

Re: Indirect memory addresses vs. lra

On 2019-08-08 12:43 p.m., Paul Koning wrote: On Aug 8, 2019, at 12:25 PM, Vladimir Makarov wrote: On 2019-08-04 3:18 p.m., John Darrington wrote: I'm trying to write a back-end for an architecture (s12z - the ISA you can download from [1]). This arch accepts indirect memory addr

Re: Indirect memory addresses vs. lra

On 2019-08-09 4:14 a.m., John Darrington wrote: On Thu, Aug 08, 2019 at 01:57:41PM -0600, Jeff Law wrote: Yea, it's certainly designed with the more mainstream architectures in mind. THe double-indirect case that's being talked about here is well out of the mainstream and no

Re: Indirect memory addresses vs. lra

On 2019-08-10 2:05 a.m., John Darrington wrote: On Fri, Aug 09, 2019 at 01:34:36PM -0400, Vladimir Makarov wrote: If you provide LRA dump for such test (it is better to use -fira-verbose=15 to output full RA info into stderr), I probably could say more. I've att

Re: Indirect memory addresses vs. lra

On 8/10/19 2:05 AM, John Darrington wrote: On Fri, Aug 09, 2019 at 01:34:36PM -0400, Vladimir Makarov wrote: If you provide LRA dump for such test (it is better to use -fira-verbose=15 to output full RA info into stderr), I probably could say more. I've attached s

Re: Indirect memory addresses vs. lra

On 8/15/19 1:35 PM, John Darrington wrote: On Thu, Aug 15, 2019 at 12:29:13PM -0400, Vladimir Makarov wrote: Thank you for providing the sources.?? It helped me to understand what is going on.?? So the test crashes on /home/jmd/Source/GCC2/gcc/testsuite/gcc.c-torture

Re: Indirect memory addresses vs. lra

On 8/15/19 12:38 PM, Richard Biener wrote: On August 15, 2019 6:29:13 PM GMT+02:00, Vladimir Makarov wrote: On 8/10/19 2:05 AM, John Darrington wrote: On Fri, Aug 09, 2019 at 01:34:36PM -0400, Vladimir Makarov wrote: If you provide LRA dump for such test (it is better to use

Re: Special Memory Constraint [was Re: Indirect memory addresses vs. lra]

On 2019-08-16 7:23 a.m., John Darrington wrote: On Thu, Aug 15, 2019 at 02:23:45PM -0400, Vladimir Makarov wrote: > I tried this solution earlier. But unfortunately it makes things worse. What happens is it libgcc cannot > even be built -- ICEs occur on a memory from a

Re: Special Memory Constraint [was Re: Indirect memory addresses vs. lra]

On 2019-08-19 3:35 a.m., John Darrington wrote: On Fri, Aug 16, 2019 at 10:50:13AM -0400, Vladimir Makarov wrote: No I meant something like that (define_special_memory_constraint "a" ...) (define_predicate "my_sp

patch to fix PR92905

=== --- ChangeLog (revision 279595) +++ ChangeLog (working copy) @@ -1,3 +1,9 @@ +2019-12-19 Vladimir Makarov + + PR target/92905 + * lra-constraints.c (process_alt_operands): Check offmemok when + processing preferred_reload_class. + 2019-12-19 Andrew Stubbs * config/gcn/gcn-valu.md Index: lra

Re: [RFC] Further LRA subreg handling issues

On 01/16/2017 10:47 AM, Matthew Fortune wrote: Hi Vladimir, I'm working on PR target/78660 which is looking like a latent LRA bug. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660 I believe the problem is in the same area as a bug was fixed in 2015: https://gcc.gnu.org/ml/gcc-patches/2015

Re: [RFD] Simplifying subregs in LRA

On 02/01/2017 06:52 PM, Matthew Fortune wrote: Hi all, I've copied you as you have each made some significant change to a function in LRA which I guess makes you de-facto experts. I've spent a while researching the history of simplify_operand_subreg and in particular the behaviour for subregs

Re: reload ICE during ada and go bootstrap on x86_64

On 10/11/2017 10:43 PM, Martin Sebor wrote: Hi Vladimir, On a hunch I backed out r253656. That let the Ada and Go bootstrap complete. It looks like your fix for bug 82353 is triggering this ICE. Martin, thank you for informing me. I used the default bootstrap. I've reverted LRA changes be

Re: Handling prefetcher tag collisions while allocating registers

On 10/23/2017 07:44 PM, Kugan Vivekanandarajah wrote: Hi All, I am wondering if there is anyway we can prefer certain registers in register allocations. That is, I want to have some way of recording register allocation decisions (for loads in loop that are accessed in steps) and use this to infl

Re: Register Allocation Graph Coloring algorithm and Others

On 12/14/2017 10:18 PM, Leslie Zhai wrote: Hi GCC and LLVM developers, I am learning Register Allocation algorithms and I am clear that: * Unlimited VirtReg (pseudo) -> limited or fixed or alias[1] PhysReg (hard) * Memory (20 - 100 cycles) is expensive than Register (1 cycle), but it has

Re: Register Allocation Graph Coloring algorithm and Others

On 12/18/2017 07:07 PM, Michael Clark wrote: Hi Leslie, I suggest adding these 3 papers to your reading list. Register allocation for programs in SSA-form Sebastian Hack, Daniel Grund, and Gerhard Goos http://www.rw.cdl.uni-saarland.de/~grund/papers/cc06-ra_ssa.pdf

Re: Why does IRA force all pseudos live across a setjmp call to be spilled?

On 03/02/2018 02:45 PM, Peter Bergner wrote: While debugging the PR84264 ICE caused by the following test case: void _setjmp (); void a (unsigned long *); void b () { for (;;) { _setjmp (); unsigned long args[9]{}; a (args); } } I n

Re: count in spill_regs

On 03/28/2018 05:31 PM, Sirish Pande wrote: Hi, I am interested to know if there is any option that would tell me how many registers have spilled. I noticed that there is spilled_regs array in reload1.c - but I can't seem to find where it dumps that information. Potentially I could build compi

Re: Scheduling automaton question

On 02/11/2011 07:33 AM, Bernd Schmidt wrote: Suppose I have two insns, one reserving (A|B|C), and the other reserving A. I'm observing that when the first one is scheduled in an otherwise empty state, it reserves the A unit and blocks the second one from being scheduled in the same cycle. This is

Re: Why IRA stores in frame, not in callee-saved reg?

On 03/08/2011 06:36 AM, Georg-Johann Lay wrote: Georg-Johann Lay schrieb: In current trunk (r170704), 4.4-branch and 4.5-branch I observe the following optimization issue in IRA: It saves regs in the frame instead of in callee-saved registers which would be much smarter. In the following C sour

Re: Why IRA stores in frame, not in callee-saved reg?

On 03/09/2011 10:09 AM, Georg-Johann Lay wrote: Vladimir Makarov schrieb: On 03/08/2011 06:36 AM, Georg-Johann Lay wrote: Returning memory move costs 4 times higher (8 instead of 2) for QI memory moves, IRA/reload generates code as expected. Is there any other way than lying about the costs

Re: Error in ira-color.c while bootstrap trunk

On 03/30/2011 09:57 AM, Revital Eres wrote: Hello, I get the following error while bootstrap trunk -r171713 on arm-linux-gnueabi configured with: ../gcc/configure --prefix=/home/eres/mainline/ build_armv7 --enable-checking --enable-languages=c --enable-bootstrap --with-arch=armv7-a --with-mode

Re: IRA improvement patch

On 05/06/2011 10:21 AM, Hari Sandanagobalane wrote: Hi Vlad, I found a problem with your IRA improvement checkin r171649 on 29-3-2011. I can't get picochip port to build with this change. The problem is in the function "clarify_prohibited_class_mode_regs" in ira.c:1413. The code reproduced her

Re: IRA observation/question

On 05/16/2011 05:00 PM, Pat Haugen wrote: I'm seeing some odd behavior in ira for PowerPC, starting with the big ira merge best I can tell (r171649). void foo(float *f1, float*f2) { *f1 = *f2; } If I compile with gcc -S -m64 -O3 -mcpu=power7 and look at the ira dump, I see that the pseudo u

Re: Richard Sandiford appointed RTL maintainer

On 06/27/2011 06:39 PM, Gerald Pfeifer wrote: It's my pleasure to announce that, also based on the recommendation of Eric Botcazou as the current maintainer in that area¹, the steering committee is appointing Richard Sandiford as an additional RTL optimizers maintainer. Please adjust the MAINTAI

Re: Richard Sandiford appointed RTL maintainer

On 06/28/2011 08:51 AM, Richard Guenther wrote: On Tue, Jun 28, 2011 at 2:47 PM, Bernd Schmidt wrote: I think it's great that Richard was appointed. I also understand Vlad's frustration and can't imagine why he isn't RA maintainer. On 06/28/11 14:39, Richard Guenther wrote: We discussed the m

Re: Richard Sandiford appointed RTL maintainer

On 06/28/2011 09:27 AM, Gerald Pfeifer wrote: On Tue, 28 Jun 2011, Vladimir Makarov wrote: If RTL optimizers (in the email subject *RTL* maintainer) do not include areas mentioned by me above, I have no objects. In Richard case, I even could live with the bigger interpretation of term 

Re: Richard Sandiford appointed RTL maintainer

On 06/28/2011 09:15 AM, Diego Novillo wrote: On 11-06-28 09:02 , Vladimir Makarov wrote: Bernd and Richard, I'd like thank you for generous support of me. But the email was mostly not about my frustration. I raised several questions relative to the decision: * ambiguity of the decision.

Re: Vladimir Makarov appointed Register Allocation Maintainer

On 07/17/2011 08:26 PM, David Edelsohn wrote: I am pleased to announce that the GCC Steering Committee has promoted Vladimir Makarov to Register Allocation Maintainer. Please join me in congratulating Vlad. Please update your listing in the MAINTAINERS file. Happy hacking

Re: Does IRA support spilling to registers instead of stack?

On 07/18/2011 05:20 PM, dpadgett_mail-...@yahoo.com wrote: Hello, Does gcc IRA provide a mechanism to support spilling to registers instead of the stack? For the particular target I'm looking at, there are some non-general-purpose registers that can be copied to and from more quickly than th

Re: Does IRA support spilling to registers instead of stack?

On 07/19/2011 11:21 AM, Jeff Law wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/19/11 07:33, Vladimir Makarov wrote: On 07/18/2011 05:20 PM, dpadgett_mail-...@yahoo.com wrote: Hello, Does gcc IRA provide a mechanism to support spilling to registers instead of the stack? For the

Re: Register pressure analysis

On 07/27/2011 10:26 AM, Sergey Ostanevich wrote: Hello! Is there any scripts/tools that parse GCC dumps and report register pressure in the dump - either overall, or in different parts of the dump? -fdump-rtl-ira creates an info dump of IRA. There is info about maximal pressure for each regio

Re: IRA vs CANNOT_CHANGE_MODE_CLASS, + 4.7 IRA regressions?

On 07/27/2011 05:59 PM, Sandra Loosemore wrote: Consider this bit of code: extern double a[20]; double test1 (int n) { double accum = 0.0; int i; for (i=0; imipsisa32r2-sde-elf-gcc -O3 -fno-inline -fno-unroll-loops -march=74kf1_1 -S abstest.c With a GCC 4.6 compiler, this produces: ..

Re: Move insn out of the way

On 08/11/2011 04:49 AM, Richard Guenther wrote: On Thu, Aug 11, 2011 at 10:11 AM, Paulo J. Matos wrote: On Thu, Aug 11, 2011 at 1:01 AM, Vladimir Makarov wrote: I can not reproduce the problem. It would be nice to give all info (the code without includes and all options). In this case I

Re: Move insn out of the way

On 08/12/2011 06:00 AM, Paulo J. Matos wrote: On Thu, Aug 11, 2011 at 3:27 PM, Vladimir Makarov wrote: Yes, that is mostly correct. The first could be done by -fweb (if the live range where the pseudo is equal to the constant is disjoint). The first could be done also by Jeff Law's pr

Comparison of GCC-4.6.1 and LLVM-2.9 on x86/x86-64 targets

Some people asked me to do comparison of GCC-4.6 and LLVM-2.9 (both released this spring) as I did GCC-LLVM comparison in previous year. You can find it on http://vmakarov.fedorapeople.org/spec under 2011 GCC-LLVM comparison tab entry. This year the comparison is done on GCC 4.6 and LLVM

Re: Comparison of GCC-4.6.1 and LLVM-2.9 on x86/x86-64 targets

On 09/07/2011 11:55 AM, Xinliang David Li wrote: Why is lto/whole program mode not used in LLVM for peak performance comparison? (of course, peak performance should really use FDO..) Thanks for the feedback. I did not manage to use LTO for LLVM as it described on http://llvm.org/docs/LinkTim

Re: Comparison of GCC-4.6.1 and LLVM-2.9 on x86/x86-64 targets

On 09/07/2011 11:28 AM, Duncan Sands wrote: Hi Vladimir, thanks for doing this. The above said about compilation speed is true when GCC front-end is used for LLVM. It's not clear to me which GCC front-end you mean. There is llvm-gcc (based on gcc-4.2) and the dragonegg plugin (the 2.9 versio

Re: Comparison of GCC-4.6.1 and LLVM-2.9 on x86/x86-64 targets

On 09/07/2011 12:23 PM, Vladimir Makarov wrote: On 09/07/2011 11:55 AM, Xinliang David Li wrote: Why is lto/whole program mode not used in LLVM for peak performance comparison? (of course, peak performance should really use FDO..) Thanks for the feedback. I did not manage to use LTO for LLVM

Re: Comparison of GCC-4.6.1 and LLVM-2.9 on x86/x86-64 targets

On 09/08/2011 04:47 AM, Jakub Jelinek wrote: On Wed, Sep 07, 2011 at 11:15:39AM -0400, Vladimir Makarov wrote: This year I used -Ofast -flto -fwhole-program instead of -O3 for GCC and -O3 -ffast-math for LLVM for comparison of peak performance. I could improve GCC performance even more by

Re: GCC 4.7.0 Status Report (2011-09-09)

On 09/09/2011 03:09 AM, Jakub Jelinek wrote: Status == The trunk is in Stage 1, which, if we follow roughly the 4.6 release schedule, should end around end of October. At this point I'd like to gather the status of the various development branches that haven't been merged into trunk yet and

Re: Comparison of GCC-4.6.1 and LLVM-2.9 on x86/x86-64 targets

On 09/09/2011 07:30 PM, Lawrence Crowl wrote: On 9/7/11, Vladimir Makarov wrote: Some people asked me to do comparison of GCC-4.6 and LLVM-2.9 (both released this spring) as I did GCC-LLVM comparison in previous year. You can find it on http://vmakarov.fedorapeople.org/spec under 2011 GCC

Re: IRA confused about killed registers

On 09/14/2011 04:49 AM, Paulo J. Matos wrote: Hi, I am trying to fix 49801 from GCC 4.6.1. One of the first things I noticed it that one of the BB at asmconst looks like: ;; Start of basic block ( 2) -> 3 ;; bb 3 artificial_defs: { } ;; bb 3 artificial_uses: { u7(4){ }u8(5){ }u9(6){ }} ;; lr

Re: IRA misses register range overlap

On 09/15/2011 11:16 AM, Peter Bigot wrote: In the msp430 back end, hard registers 4 through 15 are HImode, with adjacent register sequences used for SImode and DImode. In preparation for a library call, I'm emitting RTL that assigns values directly to reg:SI 4. Despite that, in gcc 4.5.x IRA ch

Re: IRA misses register range overlap

On 09/15/2011 03:06 PM, Peter Bigot wrote: On Thu, Sep 15, 2011 at 10:34 AM, Vladimir Makarov wrote: On 09/15/2011 11:16 AM, Peter Bigot wrote: In the msp430 back end, hard registers 4 through 15 are HImode, with adjacent register sequences used for SImode and DImode. In preparation for a

Re: IRA issue with shuffle copies...

On 01/07/2012 12:24 AM, Peter Bergner wrote: Hi Vlad, While debugging a slightly modified version of the test case in PR16458: int foo (unsigned int a, unsigned int b) { if (a == b) return 1; if (a> b) return 2; if (a< b) return 3; if (a != b) return 4; ret

Re: IRA issue with shuffle copies...

On 01/10/2012 12:55 PM, Peter Bergner wrote: On Tue, 2012-01-10 at 12:20 -0500, Vladimir Makarov wrote: Do we really need or want to create shuffle copies for insns that do not have a two operand constraint? Yes, I think so. As I remember I did some benchmarking and it gave some "orde

Re: [IRA, regresssion] code size regression with IRA

Hariharan Sandanagobalane wrote: Hi Vlad, I am attaching a test function which has just a huge switch statement with multiple cases doing different things. This function register allocates on GCC 4.3.2 with no spills at all (at -Os). The function has lots of live ranges that span function call

Re: IRA undoing scheduling decisions

Peter Bergner wrote: On Mon, 2009-08-24 at 23:56 +, Charles J. Tabony wrote: I am seeing a performance regression on the port I maintain, and I would appreciate some pointers. When I compile the following code void f(int *x, int *y){ *x = 7; *y = 4; } with GCC 4.3.2, I get the des

Re: IRA undoing scheduling decisions

Peter Bergner wrote: On Tue, 2009-09-01 at 10:38 -0400, Vladimir Makarov wrote: We could do update_equiv_regs in a separate pass before the 1st insn scheduling as it was before IRA. IIRC, update_equiv_regs() was always called as part of local-alloc, so it was always after sched1 even

Re: IRA undoing scheduling decisions

Peter Bergner wrote: On Tue, 2009-09-01 at 16:46 -0400, Vladimir Makarov wrote: Peter Bergner wrote: Were you going to whip that patch up or did you want me to? I am going to do it by myself. Great! I'd like to see how your patch affects POWER6 performance. Do you

Re: what does the calling for min_insn_conflict_delay mean

Ian Lance Taylor wrote: "Amker.Cheng" writes: In function new_ready, it calls to min_insn_conflict_delay with "min_insn_conflict_delay (curr_state, next, next)". But the function's comments say that it returns minimal delay of issue of the 2nd insn after issuing the 1st in given state. W

Re: LTO: Speedup -- some preliminary SPEC2000 results

Jan Hubicka wrote: So things seems to work now plus minus as expected. I.e. LTO builds seems similar to combined builds and whole-programs improves code size quite noticeably. Runtime results for gzip are pretty much unchanged, but that is expected. I am quite curoius about full SPEC run. Bef

Re: Understanding IRA

Ian Bolton wrote: Hi Vladimir, I have just begun working for Icera Inc, on a private port of GCC, and my first task has been to investigate the performance impact of using the Chaitin-Briggs algorithm of IRA vs the priority algorithm that we currently have enabled in our production compiler (due

Re: Understanding IRA

Ian Bolton wrote: I hope you could also make some suggestions as to how I might help IRA work well with our instructions that can only use a subset of the register bank. I forgot to write: thanks, it would be interesting for me to see your suggestions :)

Re: Understanding IRA

Ian Bolton wrote: Hi Jeff and Vladimir. Jeff: I'd be interested in trying the patch if you can send it my way. Vladimir: Today I have seen reasonable improvements on progressively-trimmed-down versions of a *single* test case by applying some cost adjustments in the case when an operand wants o

Re: Understanding IRA

Jeff Law wrote: On 11/03/09 09:29, Ian Bolton wrote: Hi again, Vladimir, I am pleased to report some performance improvements after altering ira-costs.c. A key benchmark for us has improved by 5%. Specifically, in record_reg_classes(), after the alt_cost has been calculated and it will be app

Re: Understanding IRA

Ian Bolton wrote: Yesterday, I wrote: BTW, today I have achieved some good results with existing IRA by doing the following: 1) Changed the REG_ALLOC_ORDER so that TOP_CREGS are given out before BOTTOM_REGS. My previous hacked version worked by increasing the priority of those that wanted B

Re: Possible IRA bug in assign_hard_reg

Ian Bolton wrote: Near the end of assign_hard_reg in ira-color.c, there is this code: if (min_full_cost > mem_cost) { if (! retry_p && internal_flag_ira_verbose > 3 && ira_dump_file != NULL) fprintf (ira_dump_file, "(memory is more profitable %d vs %d) ", mem_cost

Re: Possible IRA bug in assign_hard_reg

Ian Bolton wrote: Thanks for the detailed answer. While we're on the subject of assign_hard_reg, I notice the costs and min_cost variable are set but never used (decisions are being made with the full_costs array and min_full_cost). Should they be referenced somehow or are they just redundant?

Re: Question about IRA (setup_allocno_priorities)

Ian Bolton wrote: Hi again, Thanks for your answer to my other question. I just found a case, where an allocno wasn't getting a register, when I thought it should, since it was referenced 24 times. I looked in setup_allocno_priorities() to see how this was used to determine the priority and fou

Re: Unwanted IRA copies via process_reg_shuffles

Jeff Law wrote: I was looking at a regression caused by having ira-reload utilize the existing copy detection code in IRA rather than my own and stumbled upon this... Consider this insn prior to IRA: (insn 72 56 126 8 j.c:744 (parallel [ (set (reg:SI 110) (minus:

Re: IRA conflict graph, multiple alternatives and commutative operands

Jie Zhang wrote: I'm looking at PR 42258. I have a question on IRA conflict graph and multiple alternatives. Below is an RTL insn just before register allocation pass: (insn 7 6 12 2 pr42258.c:2 (set (reg:SI 136) (mult:SI (reg:SI 137) (reg/v:SI 135 [ x ]))) 33 {*thumb_mulsi

Re: Some benchmark comparison of gcc4.5 and dragonegg (was dragonegg in FSF gcc?)

Duncan Sands wrote: Hi Steven, I think Jack wasn't suggesting that dragonegg should be changed to not be a plugin any more. I think he was suggesting that it should live in the gcc repository rather than the LLVM repository. So, no offense, but the suggestion here is to make this subversiv

Re: Some benchmark comparison of gcc4.5 and dragonegg (was dragonegg in FSF gcc?)

Steven Bosscher wrote: On Wed, Apr 21, 2010 at 6:53 PM, Vladimir Makarov wrote: One interesting thing is that dragonegg is a really fast compiler. It is 2.3 times faster than gcc. Yes, well, this is one thing "the crowd out there" complains about all the time. It just app

Re: Some benchmark comparison of gcc4.5 and dragonegg (was dragonegg in FSF gcc?)

Robert Dewar wrote: Vladimir Makarov wrote: Duncan Sands wrote: Hi Steven, I think Jack wasn't suggesting that dragonegg should be changed to not be a plugin any more. I think he was suggesting that it should live in the gcc repository rather than the LLVM repository. So, no offense

Re: Some benchmark comparison of gcc4.5 and dragonegg (was dragonegg in FSF gcc?)

Chris Lattner wrote: On Apr 21, 2010, at 9:53 AM, Vladimir Makarov wrote: Only SPECIn2000 for x86_64 has been compiled fully successfully by dragonegg. There were a few compiler crashes including some in LLVM itself for SPECFP2000 and for SPECINT2000 for x86. So here is SPECInt2000 for

Re: Some benchmark comparison of gcc4.5 and dragonegg (was dragonegg in FSF gcc?)

Duncan Sands wrote: Hi Vladimir, thank you for doing this benchmarking. Only SPECIn2000 for x86_64 has been compiled fully successfully by dragonegg. There were a few compiler crashes including some in LLVM itself for SPECFP2000 and for SPECINT2000 for x86. Sorry about that. Can you please se

Re: Some benchmark comparison of gcc4.5 and dragonegg (was dragonegg in FSF gcc?)

Chris Lattner wrote: On Apr 21, 2010, at 11:11 AM, Vladimir Makarov wrote: This is definitely interesting, but you're also comparing apples and oranges here (for both compile time and performance). Can you get numbers showing GCC -O3 and dragonegg with LTO to get a better compa

Re: Some benchmark comparison of gcc4.5 and dragonegg (was dragonegg in FSF gcc?)

Robert Dewar wrote: I am agree with this for moderately optimizing compilers. But for highly optimizing compilers it might be no true. Intel generates much better and bigger code than gcc. Although it might be mostly because of code versioning (including one for different subtargets). I

Re: Some benchmark comparison of gcc4.5 and dragonegg (was dragonegg in FSF gcc?)

Robert Dewar wrote: Vladimir Makarov wrote: Although it is not right argument to what you mean. But example about vectorization would be right. ICC vectorizes many more loops than gcc does. Vectorized loops is much bigger in size than their non-vectorized variants. So faster code does

Re: IRA accumulated costs

it is more profitable. 2008-10-01 Vladimir Makarov <[EMAIL PROTECTED]> * ira-int.h (ira_allocno): Add member updated_cover_class_cost. (ALLOCNO_UPDATED_COVER_CLASS_COST): New. (ira_fast_allocation): Remove the prototype. * ira-color.c (update_copy

Re: IRA compile time on gcc-c-torture/compile/limits-fnargs.c

[EMAIL PROTECTED] wrote: Is anyone else seeing a long compile time on gcc-c-torture/compile/limits-fnargs.c with -O2 optimization? limits-fnargs.c contains a single call to a function with 10,000 arguments. There is PR 31850 which talks about compile time on limits-fnargs.c, but this was fixed

Re: -fno-ira removal

Jakub Jelinek wrote: Hi! I think we are now almost a month past the deadline for removal of -fno-ira and ports that haven't been converted to IRA yet. Vladimir, do you plan to move forward with this step any time soon? I'd rather wait for 2-3 weeks more. People are still working on some ta

Re: GCC 4.4.0 Status Report (2008-11-27)

Jeff Law wrote: Joseph S. Myers wrote: Vladimir, is there any news on the patch to remove the old allocator since , or on getting m32c and IRA working together? Vlad is relatively busy dealing with PRs as they're reported, the optimization reg

Re: GCC 4.4.0 Status Report (2008-11-27)

Mark Mitchell wrote: Status == The trunk remains Stage 4, so only fixes for regressions (and changes to documentation) are allowed. As stated previously, the GCC 4.4 branch will be created when there are no open P1s and the total number of P1, P2, and P3 regressions is under 100. We're clo

Re: GCC 4.4.0 Status Report (2008-11-27)

Hans-Peter Nilsson wrote: On Tue, 9 Dec 2008, Vladimir Makarov wrote: Today Jeff Law (many thanks to him!) approved a big patch I wanted to commit before submitting patch removing the old register allocator. So nothing prevents to remove the old RA. I am going to submit the patch removing

Re: [IRA] New register allocator question

Bingfeng Mei wrote: I found if I define a new register class that covers both GR_REGS and PR_REGS, the issue can be solved. New IRA spill the predicate register to general regsister first instead of memory. Is this right approach? #define IRA_COVER_CLASSES \ { \ GRP

Re: [IRA] New register allocator question

Bingfeng Mei wrote: Hello, I recently ported our GCC to new IRA by following mainline development. The only interface I added is IRA_COVER_CLASSES. Our architecture has predicate register file. When predicate register has to be spilled, the new IRA produces inferior code to the old register a

Re: About Hazard Recognizer:DFA

daniel tian wrote: Hi Dr. Uday Khedker: Happy New Year! I met hazard problem. And I have debuged this error for a few days. I wrote DFA to avoid load hazard, but still it exists. I wonder whether in default the command './cc1 hazard.c' doesn't compile the file with DFA. And in default wit

Re: How to define 2 bypasses for a single pair of insn_reservation

Ye, Joey wrote: When I write schedule model for following instructions: Insn1: mov %r1, %r2 Insn2: mov %r1, %r3 Insn3: foo %r2, %r3 (foo is a 3 op insn, for example, %r3 = %r3 << %r2) Latency from insn1 to insn3 is x cycles, and latency from insn2 to insn3 is y cycles. x != y. Both insn1 and

Re: How to define 2 bypasses for a single pair of insn_reservation

Ye, Joey wrote: Vladimir Makarov [mailto:vmaka...@redhat.com] wrote: It was supposed to have two latency definitions at most (one in define_insn_reservation and another one in define_bypass). That time it seemed enough for all processors supported by GCC. It also simplified semantics

Re: IRA conflict graph & alternative selection

Jeff Law wrote: I've been thinking further about instruction alternative selection prior to allocation and one of the questions in my mind is how this interacts with IRA. We select an alternative for each insn based on some "best guess" heuristic -- the selection of an alternative will often

Re: IRA conflict graph & alternative selection

Ian Lance Taylor wrote: Paolo Bonzini writes: That is in brief how I see it and there are a lot of reload details missed (like virtual register eliminations or addressing displacement constraints etc). I suppose those would stay in reload? I see no reason for those to stay in

Re: changed_allocation_pseudos

Jeff Law wrote: What purpose does changed_allocation_pseudos serve? AFAICT we set/clear the bitmap, but never use it for anything. It was added as part of the IRA integration. Did you have some purpose in mind for this bitmap? If not can we just remove it? As I remember, it was used in an

Re: IRA conflict graph & alternative selection

Jeff Law wrote: Ian Lance Taylor wrote: Jeff Law writes: Ian Lance Taylor wrote: I see no reason for those to stay in reload (especially since I think reload should disappear entirely). It is reasonable to pick the total maximum size of the stack frame, and thus resolve all displaceme

Re: IRA conflict graph & alternative selection

Jeff Law wrote: Vladimir Makarov wrote: Jeff Law wrote: I've been thinking further about instruction alternative selection prior to allocation and one of the questions in my mind is how this interacts with IRA. We select an alternative for each insn based on some "best guess&q

Re: query automaton

Alex Turjan wrote: Hello, Some time ago I asked a question regarding the possibility to schedule an operation on alternative functional units (FUs) AND depending on the chosen FUs to generate a dedicated assembly mnemonic. To give a simple example suppose I have a move operation that can be is

Re: query automaton

Alex Turjan wrote: Dear Vladimir, Not really. There is no requirement for "the units part of the alternatives of a reservation must belong to the same automaton". Querying should also work in this case because function cpu_unit_reservation_p checks all automata for an unit reservation.

Re: query automaton

Alex Turjan wrote: Vladimir thanks for help! With respect to your answer I would like to point to you a possible way to solve the scheduling problem (which I think wont be too difficult to be implemented in genautomata). Alex, thanks for sharing your thoughts. I also thought about this a

Re: Typo or intended?

Bingfeng Mei wrote: Hello, I just updated our porting to include last 2-3 weeks of GCC developments. I noticed a large number of test failures at -O1 that use a user-defined data type (based on a special register file of our processor). All variables of such type are now spilled to memory whic

<    1   2   3   4   >