Branch created for PR46489 (target macro elimination from frontends / tree optimizers)
I have created the branch: svn://gcc.gnu.org/svn/gcc/branches/pr46489-20101217-branch to continue working on PR46489 while trunk is in slush / freeze mode. The branch does not use the usual distributed ChangeLog scheme, but a single ChangeLog.46489 in svn://gcc.gnu.org/svn/gcc/branches/pr46489-20101217-branch/gcc that has entries like for a patch submission. That keep our options open to either review the branch as a whole, or to convert the check-ins back into patches and submit them when 4.7 phase 1 opens. Yesterday I checked in two of the still unreviewed patches I had posted previously on gcc-patches. As the goal is no longer inclusion in 4.6 phase 3, but but 4.7 phase 1 or 2, it now makes sense to look beyond the issue of front-end instability, and also include further macro->hook conversions that make the design more consistent. In that spirit, I've checked a patch into the branch today to hookize INIT_CUMULATIVE_ARGS and its two variants into a single hook. Is there sufficient interest to post the branch patches to gcc-patches as I go? FWIW my current contract under which I do this work ends at the end of December, so I might not have much time to discuss the patches afterwards.
gcc-4.6-20101218 is now available
Snapshot gcc-4.6-20101218 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20101218/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 168034 You'll find: gcc-4.6-20101218.tar.bz2 Complete GCC (includes all of below) MD5=1cd476cd4159eb90a101c1764555c1df SHA1=12a316fc6f818d8575b9c80e0823093a27fb8bea gcc-core-4.6-20101218.tar.bz2C front end and core compiler MD5=39c6b9ab8f5cb6d487c1860638ff07ac SHA1=98ad2f63a3a200ee5eadb95a389ee0647d4e8ddd gcc-ada-4.6-20101218.tar.bz2 Ada front end and runtime MD5=0b4b1bddd6f369d4e49b880f6ddcd26e SHA1=9f6d979457bef7e9ebc9e81b6d5079bc2b1d8776 gcc-fortran-4.6-20101218.tar.bz2 Fortran front end and runtime MD5=ff7749c5adb8712c4159cda7ad1ca201 SHA1=609dd926dca3e2627415b008fd0977f393c8037c gcc-g++-4.6-20101218.tar.bz2 C++ front end and runtime MD5=8daaf9f8f85e74a1c85d9fb052288b7e SHA1=081fc83db3981d45b58d9911804a9bf5e1b1ca52 gcc-go-4.6-20101218.tar.bz2 Go front end and runtime MD5=cd615726cf2ab7062278aadf8c20a044 SHA1=2a5204b6a7f13cf081348584ed0c6b6260723cf2 gcc-java-4.6-20101218.tar.bz2Java front end and runtime MD5=34825b253d545e26f9841b8d0ff8f058 SHA1=c59fac9c05872c59524746241920d5b8f8935b68 gcc-objc-4.6-20101218.tar.bz2Objective-C front end and runtime MD5=9923d15dcb6ecaeb519ad8e83b05f7cc SHA1=387f00adde8b0914e07c78912c57a9a34bb1673f gcc-testsuite-4.6-20101218.tar.bz2 The GCC testsuite MD5=08ce9a8eab7b3886560e3d7ab999b653 SHA1=c023c0015ef758b7b7e24a5cfa5f78bf060d0ede Diffs from 4.6-20101211 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: RFA: patch to prohibit IRA undoing sched1 [was IRA undoing sched1]
On Thu, Dec 2, 2010 at 2:17 PM, Vladimir Makarov wrote: > On 12/01/2010 02:14 PM, Paul Koning wrote: >> >> On Nov 29, 2010, at 9:51 PM, Vladimir Makarov wrote: >> >>> On 11/29/2010 08:52 PM, Paul Koning wrote: I'm doing some experiments to get to know GCC better, and something is puzzling me. I have defined an md file with DFA and costs describing the fact that loads take a while (as do stores). Also, there is no memory to memory move, only memory to/from register. Test program is basically a=b; c=d; e=f; g=h; Sched1, as expected, turns this into four loads followed by four stores, exploiting the pipeline. Then IRA kicks in. It shuffles the insns back into load/store, load/store pairs, essentially the source code order. It looks like it's doing that to reduce the number of registers used. Fair enough, but this makes the code less efficient. I don't see a way to tell IRA not to do this. >>> Most probably that happens because of ira.c::update_equiv_regs. This >>> function was inherited from the old register allocator. The major goal of >>> the function is to find equivalent memory/constants/invariants for pseudos >>> which can be used by reload pass. Pseudo equivalence also affects live >>> range splitting decision in IRA. >>> >>> Update_equiv_regs can also move insns initiating pseudo equivalences >>> close to the pseudo usage. You could try to prevent this and to see what >>> happens. IMO preventing such insn moving will do more harm on performance >>> on SPEC benchmarks for x86/x86-64 processors. As it happens, there's a secondary reload involved: the loads are into one set of registers but the stores from another, so a register to register move is added in by reload. Does that explain the behavior? I tried changing the cover_classes, but that doesn't make a difference. >>> It is hard to say without the dump file. If everything is correctly >>> defined, it should not happen. >>> >> I extended the test code a little, and fed it to a mips64el-elf targeted >> gcc. It showed the same pattern in one of the two functions but not the >> other. The test code is test8.c (attached). >> >> What I see in the assembly output (test8.s, also attached) is that foo() >> has a load then store then load then store pattern, which contradicts what >> sched1 constructed and doesn't take advantage of the pipeline. However, >> bar() does use the pipeline. I don't know what's different between these >> two. >> >> Do you want some dump file (which ones)? Or you could just reproduce this >> with the current gcc, it's a standard target build. The compile was -O2 >> -mtune=mips64r2 -mabi=n32. >> > As I guessed the problem is in update_reg_equiv transformation > trying to move initialization insn close to its single use to decrease > the register pressure. A lot of people already complaint about > undoing scheduling by this function. > > The following patch solves the problem when you use > -fsched-pressure. I would not like to do that for regular (not > register pressure-sensitive) insn scheduling for obvious reasons. > > I think most RISC targets (including MIPS ones) should make > -fsched-pressure by default. > > > 2010-12-02 Vladimir Makarov > > * ira.c (update_equiv_regs): Prohibit move insns if > pressure-sensitive scheduling was done. > > Jeff, sorry for bothering you. Is it ok to commit the patch to the > trunk? > This caused: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46880 -- H.J.
The GNU Compiler Collection should be renamed the Jewish Compiler Collection
I'm just kidding, I was going to make a joke about being conservative about memory but then I realized I would be making fun of my own heritage. Anyway, I love what you guys are doing. The GCC really is the embodiment of the ideal GNU project, and it is for this reason that I will be donating to the Free Software Foundation later this year. You make programming as a teenager enjoyable, so keep doing what you guys are doing.
