Re: RFC: Idea for code size reduction
Hello everybody, On Friday 07 March 2008 Philipp Marek wrote: > Here you are. > > > code_overlap.pl - disassembles a binary, and outputs a list > (address, name, instruction, bytes) to STDOUT. > > bytes_saved.pl - takes such a list, and tries to estimate > the amount of bytes that could be saved. > > > I normally use them this way: > #!/bin/sh > perl code_overlap.pl "$@" > overlap.txt > perl bytes_saved.pl has anyone acted on that already? I've got some more ideas, which I'd like to test (and implement) here. Regards, Phil -- Versioning your /etc, /home or even your whole installation? Try fsvs (fsvs.tigris.org)!
gcc-4.4-20090123 is now available
Snapshot gcc-4.4-20090123 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090123/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 143592 You'll find: gcc-4.4-20090123.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20090123.tar.bz2 C front end and core compiler gcc-ada-4.4-20090123.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20090123.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20090123.tar.bz2 C++ front end and runtime gcc-java-4.4-20090123.tar.bz2 Java front end and runtime gcc-objc-4.4-20090123.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20090123.tar.bz2The GCC testsuite Diffs from 4.4-20090116 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 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.
IRA vs. frame pointer elimination [PR38952]
Hi all,
re: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952
[Regression/4.4,P1 blocker IMHO: total failure of SjLj EH on Cygwin+MinGW]
I have a simple testcase showing breakage in SjLj EH on Cygwin. To cut
right to the chase, the RTL generated by the 130r.eh pass to save %ebp (the
frame pointer) into the jmp_buf struct embedded in the SjLj_Function_Context
struct that is about to be registered looks like so:
(insn 49 48 50 2 (set (mem:SI (reg:SI 63) [0 S4 A8])
(reg/f:SI 54 virtual-stack-vars)) -1 (nil))
Pass 133r.vregs turns it into:
(insn 49 48 50 2 (set (mem:SI (reg:SI 63) [0 S4 A8])
(reg/f:SI 20 frame)) 41 {*movsi_1} (nil))
Then it isn't touched again until pass 174.ira, which replaces it by:
(insn 73 48 49 2 (set (reg:SI 1 dx)
(plus:SI (reg/f:SI 7 sp)
(const_int 80 [0x50]))) 209 {*lea_1} (nil))
(insn 49 73 51 2 (set (mem:SI (reg/f:SI 0 ax [63]) [0 S4 A8])
(reg:SI 1 dx)) 41 {*movsi_1} (nil))
That is to say, it has performed frame-pointer elimination and replaced the
reference to the fp by a constant offset from the %esp. However, the offset
here is wrong; at least by the time we get to the final generated assembly,
the stack frame size is 0x60 bytes.
So, the question is: Is it valid for IRA to be doing this pre-reload? I
thought stack layout wasn't necessarily congealed until we enter strict mode,
but I could be wrong and/or IRA could have a "special understanding" with
reload about this. The other possibility is that the x86 backend is bogusly
growing the stack frame allocation at a later stage than it's allowed to;
perhaps something to do with stack alignment, which I haven't been following
but I see there were a whole bunch of new testcases added a while ago?[*]
cheers,
DaveK
[ NB. Gotta go AFK for a couple of hours now and get something to eat, so
won't be able to respond to any replies immediately; will check back later. ]
--
[*] - See PR38949, but note that of the new tests, the ones which /don't/
experience the link failure mentioned there all fail at runtime.
Re: IRA vs. frame pointer elimination [PR38952]
On Fri, Jan 23, 2009 at 5:29 PM, Dave Korn wrote: >Hi all, > > re: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952 > [Regression/4.4,P1 blocker IMHO: total failure of SjLj EH on Cygwin+MinGW] > > I have a simple testcase showing breakage in SjLj EH on Cygwin. To cut > right to the chase, the RTL generated by the 130r.eh pass to save %ebp (the > frame pointer) into the jmp_buf struct embedded in the SjLj_Function_Context > struct that is about to be registered looks like so: > An IRA setjmp bug was fixed recently: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38587 Does it fix your problem? -- H.J.
Re: GCC 4.4.0 Status Report (2009-01-06)
Richard Guenther wrote: > Status > == > > The trunk remains Stage 4, so only fixes for regressions (and changes > to documentation) are allowed. Sorry to be the bearer of bad news, but I think I should draw your attention to PR38952 (SjLj EH dead) which is a serious (I think justifiably P1) regression on at least two secondary platforms. I can only apologise for not having noticed it sooner but I've only just come across it during the testing I've been doing for recent patches, when I had a moment to start looking at pre-existing regressions. There's a reasonable amount of analysis and testcase in the PR: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952 and I'm hoping to hear from someone more familiar with IRA than me in order to zero in on where exactly the failure is arising: http://gcc.gnu.org/ml/gcc/2009-01/msg00350.html I'll be working full-time on trying to resolve this in time for the 4.4.0 branch. Hope this helps. cheers, DaveK
Re: IRA vs. frame pointer elimination [PR38952]
H.J. Lu wrote: > On Fri, Jan 23, 2009 at 5:29 PM, Dave Korn wrote: >>Hi all, >> >> re: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952 >> [Regression/4.4,P1 blocker IMHO: total failure of SjLj EH on Cygwin+MinGW] >> >> I have a simple testcase showing breakage in SjLj EH on Cygwin. To cut >> right to the chase, the RTL generated by the 130r.eh pass to save %ebp (the >> frame pointer) into the jmp_buf struct embedded in the SjLj_Function_Context >> struct that is about to be registered looks like so: >> > > An IRA setjmp bug was fixed recently: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38587 > > Does it fix your problem? I'm not sure, but my source tree is at r.143552, which is just a couple of revs before your fix went in. I will test it and report back; thanks for the hint. cheers, DaveK [ now really going AFK for a bit this time! ]
GCC RES: Restrictive Exception Specification: 0.1 - Alpha. Feedback Request.
I recently (on 18/12/2008) mailed a GCC patch to this mailing list, but I went on holiday after and have only just arrived back. I probably should have asked for some feedback then. The patch is for the C++ component of GCC. It adds some compiler warning options. The primary usage of these options generates warnings when compiling code that could terminate due to unhandled exceptions. Functionally, the code is pretty much alpha, although it is tidy, commented, tested (by me) and working as expected. MY REQUESTS: A) I'm hoping that someone else here may have the time to download and install it, to tell me at least whether it works for them. B) If possible it would also be nice if someone were to take a glance at the code and tell me whether it looks like it would be suitable. There's documentation describing it's workings and it's not very long or unusual, only around 1000 lines total. C) Lastly, it would be nice if someone could indicate whether a finished and fully functional version of this project would be likely to make it into the mainline as I have seen requests for its functionality many times, including on this mailing list, and it has no downside: - It does not alter the output in any way. - It has no impact on compilation and compilation speed when not explicitly invoked. - The code is structured to make any future maintenance painless. I really don't have much of an idea how things work around here, and as my patch isn't near being complete I'm not after a formal review or a branch or merge, just a few pointers as to whether I'm headed in the right direction. Thanks to anybody that can help out in any way. FILES INCLUDED: res.tgz: Contains the following: - res.txt: Documentation. - test.tgz: Test files and script. (See tests.txt for info) - res.diff: Patch file. I've never made patch files before, but hopefully this one is OK. I used [diff -Naur original/gcc-3.4.2/gcc res/gcc-3.4.2/gcc > res.diff] I tested it on a fresh gcc-3.4.2 extract and it worked with [patch -p1 < res.diff] TESTING: For a quick test, just call gcc with -Wres (or -Wres -Wres-debug to add the debug info). I haven't tested on much real-world code, there's a chance it may still have bugs and segfault or something, although I have tried to test for them. It's still alpha though. Testcases: Unzip test.tgz and read test/tests.txt for instructions, or call test/test.sh . All the testcases except the last work as they should. CODE: I tried to use GCC coding style but I didn't see an 80 character/line limit anywhere in the document, so I didn't use any limit. Perhaps someone will bite me for this or perhaps you'll all celebrate the beginning of a new era of sensible unlimited lines :) anyway it's alpha so it hardly matters at present - it's just far easier for me to read. MORE INFORMATION IF NOT ALREADY TL/DRd: The discussion prior to me starting this project were primarily: 1) Whether it was possible to accurately check exception specifications at compile-time, thus eliminating the issue of unhandled exceptions. 2) Whether it was possible to require exception specifications to always be accurate without in any way limiting the full power and flexibility of C++. 3) Whether using exception specifications could, in some cases, lead to slower execution when not handling an exception. I hope that, even at this early stage, this project shows that #1 and #2 are possible for non-template code. With a bit of work it should be possible to show that #1 is possible for template code also, although this will initially be limiting. I further hope to show (see documentation, the topic about extending C++) that it would be quite simple and painless to make minor changes to C++'s exception specification rules so that #2 is also possible for template code. If #3 is true it has to be the compilers fault. It should also be very easy to add a switch to instruct G++ to ignore all exception specifications when generating code, if necessary. Once that is done, it would not be very arduous to update (or fork) all major libraries, STL, Boost etc to make them compliant. In fact it could almost be automated. Then accidental unhandled exceptions could be a thing of the past. res.tgz Description: GNU Zip compressed data
Re: IRA vs. frame pointer elimination [PR38952]
Dave Korn wrote: > H.J. Lu wrote: >> On Fri, Jan 23, 2009 at 5:29 PM, Dave Korn wrote: >>>Hi all, >>> >>> re: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952 >>> [Regression/4.4,P1 blocker IMHO: total failure of SjLj EH on Cygwin+MinGW] >>> >>> I have a simple testcase showing breakage in SjLj EH on Cygwin. To cut >>> right to the chase, the RTL generated by the 130r.eh pass to save %ebp (the >>> frame pointer) into the jmp_buf struct embedded in the SjLj_Function_Context >>> struct that is about to be registered looks like so: >>> >> An IRA setjmp bug was fixed recently: >> >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38587 >> >> Does it fix your problem? > > I'm not sure, but my source tree is at r.143552, which is just a couple of > revs before your fix went in. I will test it and report back; thanks for the > hint. Unfortunately the patch for 38587 made no difference at all to the generated code, including the incorrect initial frame pointer offset calculation; my test case compiles identically. This is not unsurprising to me; there doesn't appear to be any stack slot sharing going on here. Thanks for trying to help, H.J. So, my main problem remains; I still don't know if what IRA is doing here is permitted: eliminating the FP to a constant offset from the SP, before reload. I'll have to see what any of the IRA or RTL maintainers have to say. cheers, DaveK
Probably not IRA [was Re: IRA vs. frame pointer elimination [PR38952]]
Dave Korn wrote:
> Dave Korn wrote:
>> H.J. Lu wrote:
>>> An IRA setjmp bug was fixed recently:
>>>
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38587
>>>
>>> Does it fix your problem?
>> I'm not sure, but my source tree is at r.143552, which is just a couple
>> of revs before your fix went in. I will test it and report back; thanks
>> for the hint.
>
> Unfortunately the patch for 38587 made no difference at all to the
> generated code, including the incorrect initial frame pointer offset
> calculation; my test case compiles identically. This is not unsurprising
> to me; there doesn't appear to be any stack slot sharing going on here.
> Thanks for trying to help, H.J.
>
> So, my main problem remains; I still don't know if what IRA is doing here
> is permitted: eliminating the FP to a constant offset from the SP, before
> reload. I'll have to see what any of the IRA or RTL maintainers have to
> say.
Hmm, or maybe I won't; -fno-ira doesn't make any difference, which suggests
that it's perhaps a problem in the backend. In a non-IRA build, pass
172r.lreg has:
(insn 49 48 51 2 (set (mem:SI (reg/f:SI 63) [0 S4 A8])
(reg/f:SI 20 frame)) 41 {*movsi_1} (nil))
and pass 173r.greg has
(insn 73 48 49 2 (set (reg:SI 1 dx)
(plus:SI (reg/f:SI 7 sp)
(const_int 80 [0x50]))) 209 {*lea_1} (nil))
(insn 49 73 51 2 (set (mem:SI (reg/f:SI 0 ax [63]) [0 S4 A8])
(reg:SI 1 dx)) 41 {*movsi_1} (nil))
and here we can see that it's reload doing the FP elimination:
Reloads for insn # 49
Reload 0: reload_out (SI) = (mem:SI (reg/f:SI 0 ax [63]) [0 S4 A8])
NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
reload_out_reg: (mem:SI (reg/f:SI 0 ax [63]) [0 S4 A8])
Reload 1: reload_in (SI) = (plus:SI (reg/f:SI 7 sp)
(const_int 80 [0x50]))
GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 1)
reload_in_reg: (plus:SI (reg/f:SI 7 sp)
(const_int 80 [0x50]))
reload_reg_rtx: (reg:SI 1 dx)
So... it's somewhere between reload and the back end.
cheers,
DaveK
Definitely not IRA [was Re: Probably not IRA [was Re: IRA vs. frame pointer elimination [PR38952]]]
Dave Korn wrote: [ ... snip ... ] Sorry, the conclusion of that post evolved a bit while I was writing it, but I forgot to update the subject. This is what I should have posted it as. I'll start a fresh thread when I know more about the cause of the failure. cheers, DaveK
