[OT] Re: Git repository with full GCC history
On Fri, Jun 01, 2007 at 02:52:43AM -0400, Bernardo Innocenti wrote: > Harvey Harrison wrote: > > >Was this repo made with svnimport or git-svn? svnimport is faster but > >chooses bad delta bases as a result. git repack -a -d -f would allow > >git to choose better deltas rather than reusing the deltas that > >svnimport created. > > I used: > > git-svn fetch > git-fetch . remotes/git-svn > > > Yes, I did a "git-repack -a -d -f" too. And I even did > one with --window=20, but nothing changed. > > > >(I think, I'm not a git expert). > > Neither am I, but after all, who is? (Linus, you don't count) > > > >>What version of git did you use? 1.5.0.6 here. > > > >1.5.2 > > I shall try it... That's probably it. > This may be the pack depth which was increased to 50 according to 1.5.2 release notes: " - The default pack depth has been increased to 50, as the recent addition of delta_base_cache makes deeper delta chains much less expensive to access. Depending on the project, it was reported that this reduces the resulting pack file by 10% or so." I'm almost certain that the savings will be much larger than 10% for some files, for example the ChangeLogs. BTW, there is a strange line in the current ChangeLog, between May 30th and May 31st entries: ">>> .r125234". Is it just me, a subversion glitch or something else? Gabriel
Optimizations for itanium
Hello, Can someone tell me the back-end optimizations available for itanium (IA64)? We (HP) may be able to contribute to this from our side. Thanks -kamal
Re: Very Fast: Directly Coded Lexical Analyzer
> Like e.g. the generated code >IF match-char1 THEN .. >ELSIF match-char2 THEN .. >ELSIF match-char3 THEN .. >.. >END > ? Similar. It identifies ranges of character point sets and brackets them via binary bracketting. > Why to complicate the things? The determinist finite automaton (DFA) > table-driven helps us to express efficiently this with regular > expressions (RE). Because the directly coded approach avoids overhead of housekeeping for the lexer state. As you might have realized, the RE in quex follow the syntax of flex/lex. > Too, with the Ken Thompson & Kleene theories, it's not easy to be > hand-written the implementation of an analyzer or analyzer generator. The analyzer generator does, indeed, do the Thomson Construction and repetition of state machines according to Kleene Closure with epsilon transition. And it is done. If you have any critics about the coverage of the unit tests in core_engine/state_machine/TEST, you are free to add some new. Let me know. > It's possible to be unstable your quex analyzer generator while the > lex/flex generator is stable. Well, I tried to write unit tests for almost all functionalities and features of the core engine. This gives me confidence that the thing is to a high degree stable. > To obtain 200-250% in speed gain won't be possible for this GCC > optimizing compiler because of http://en.wikipedia.org/wiki/Amdahl%27s_law Amdahl's Law talks about paralellism. That is not the case here. He apply a different approach for lexical analysis as mentioned above. If you talk about the influence of a new lexer to the speed of the whole compiler, I would aggree that the a speed up factor 2 is not possible if lexical analysis constitutes less than 50% of the total computation effort (simple math). > GCC throws more time optimizing than analyzing lexically unless it > deactivates the optimizing option -O. Here I aggree, and this supports the previous point. > The basic transformations of the Ken Thomson & Kleene theories like > the NFA <-> DFA transformations are hard too. Well, textbooks pinpoint the process with enough clarity. If you doubt the functionality of my subset construction, again, please argue against the unit tests. Best Regards Frank -- // Dr.-Ing. Frank-René Schäfer, Bodelschwinghstr. 28 // D-50170 Kerpen // Tel.: 49+176/22 02 58 59;
Re: Git repository with full GCC history
Jan-Benedict Glaw wrote: On Thu, 2007-05-31 21:34:33 -0400, Bernardo Innocenti <[EMAIL PROTECTED]> wrote: I've set up a Git mirror of the entire GCC history on server space kindly provided by David Woodhouse. You can clone it with: git-clone git://git.infradead.org/gcc.git How often will it be synced with upstream SVN? I've setup a cron job every hour, but I can increase the frequency if needed. git-svn is not a cpu/bandwidth hog. While you're at it, would David mind to also place a binutils, glibc and glibc-ports GIT repo next to it? That way, there would be a nice single point of GIT repos for the whole toolchain. For this, I'd prefer waiting for David's answer. David, my guess is that all of these combined should be smaller than GCC alone. There should be fewer users, too. Thanks for the work, I'll just clone it right now :) Be our guest, and let me know if you find a way to repack the repo to a smaller size. Not that I care that much... 800MB is small enough for today's bandwidth. -- // Bernardo Innocenti \X/ http://www.codewiz.org/
__builtin_apply_args - GCC 4.1.1
Hello all,
I am working with a private target(GCC v4.1.1).
For my target the function arguments are passed through registers.
For this purpose 4 registers are used. If the no. of arguments are
more than 4, the remaining arguments are passed through stack.
But for varargs the arguments are pushed into the stack by the caller function.
I am getting a execution failure for the following test case.
#include
#include
#define INTEGER_ARG 5
void foo(char *name, int d, int e, int f, int g)
{
printf("\nname = %s\n13 = %d\n72 = %d\n89 = %d\n5 = %d\n", name,d,e,f,g );
}
void bar(char *name, ...)
{
void **arg;
arg = __builtin_apply_args();
__builtin_apply(foo, arg, 24);
}
int main(void)
{
bar("", 13, 72, 89, INTEGER_ARG);
return 0;
}
The above testcase is similar to gcc-src/gcc/testsuite/gcc.dg/builtin-apply2.c
Looking at the assembly file i find that __builtin_apply_args() is
where the problem lies.
Even though main pushes all the arguments in the stack
__builtin_apply_args is expecting the values in the argument
registers. More over when foo is called the arguments are to be
passed through registers ("", 13, 72, 89) and stack (INTEGER_ARG).
The problem is due to two things.
1. __builtin_apply_args is picking the arguments from the argument
registers even though they are not available there since its
varargs.So its actually storing garbage values in the block.
2. __builtin_apply_args is storing the arguments, even though garbage,
in wrong order in the block. From this block, stored in the wrong
order, __builtin_apply passes the arguments to foo, and
__builtin_apply function is doing the job properly.
Is there any way to control the behavior of __builtin_apply_args?
Regards,
Shafi
Re: Git repository with full GCC history
On Fri, 2007-06-01 04:47:11 -0400, Bernardo Innocenti <[EMAIL PROTECTED]> wrote: > Jan-Benedict Glaw wrote: > > On Thu, 2007-05-31 21:34:33 -0400, Bernardo Innocenti <[EMAIL PROTECTED]> > > wrote: > > > I've set up a Git mirror of the entire GCC history on > > > server space kindly provided by David Woodhouse. > > > > > > You can clone it with: > > > > > > git-clone git://git.infradead.org/gcc.git > > > > How often will it be synced with upstream SVN? > > I've setup a cron job every hour, but I can increase the > frequency if needed. git-svn is not a cpu/bandwidth hog. Can single (or a really small number of SVN commits) be pulled efficiently? A year ago, I had something similar in place and called the update script from procmail (so that it would pull the last commit right after receiving the commit email.) But hourly mirroring sounds like being more than enough, though. > > While you're at it, > > would David mind to also place a binutils, glibc and glibc-ports GIT > > repo next to it? That way, there would be a nice single point of GIT > > repos for the whole toolchain. > > For this, I'd prefer waiting for David's answer. David, > my guess is that all of these combined should be smaller > than GCC alone. There should be fewer users, too. I guess that'll be in the 150..200 MB range. > > Thanks for the work, I'll just clone it right now :) > > Be our guest, and let me know if you find a way to > repack the repo to a smaller size. You already did a full repack as I get from the other emails. I don't think it'll pack any smaller. You'd increase the window sizes, but that simply won't pack it to 400MB :) It's surely not worth burning lots of CPU cycles for one megabyte, or two... > Not that I care that much... 800MB is small enough for > today's bandwidth. Maybe we'd find one or two of these "root servers" offered by some ISPs with unlimited traffic and start to spread the load, or ask the kernel.org guys if they'd also host a copy of the repo. MfG, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED] +49-172-7608481 Signature of: Alles wird gut! ...und heute wirds schon ein bißchen besser. the second : signature.asc Description: Digital signature
Re: [OT] Re: Git repository with full GCC history
Gabriel Paubert <[EMAIL PROTECTED]> writes: > BTW, there is a strange line in the current ChangeLog, between May 30th > and May 31st entries: ">>> .r125234". Is it just me, a subversion > glitch or something else? It's a leftover conflict marker, I have removed it. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Git repository with full GCC history
On Fri, 2007-06-01 at 10:39 +0200, Jan-Benedict Glaw wrote: > How often will it be synced with upstream SVN? While you're at it, > would David mind to also place a binutils, glibc and glibc-ports GIT > repo next to it? That way, there would be a nice single point of GIT > repos for the whole toolchain. Sounds like a fine plan. Bernie, if you want to create these in your home directory I'll move them to /srv/git next to gcc.git. -- dwmw2
Re: Git repository with full GCC history
On Fri, Jun 01, 2007 at 04:47:11AM -0400, Bernardo Innocenti wrote: > Jan-Benedict Glaw wrote: > >On Thu, 2007-05-31 21:34:33 -0400, Bernardo Innocenti <[EMAIL PROTECTED]> > >wrote: > >>I've set up a Git mirror of the entire GCC history on > >>server space kindly provided by David Woodhouse. > >> > >>You can clone it with: > >> > >>git-clone git://git.infradead.org/gcc.git > > > >How often will it be synced with upstream SVN? > > I've setup a cron job every hour, but I can increase the > frequency if needed. git-svn is not a cpu/bandwidth hog. > > >While you're at it, > >would David mind to also place a binutils, glibc and glibc-ports GIT > >repo next to it? That way, there would be a nice single point of GIT > >repos for the whole toolchain. > > For this, I'd prefer waiting for David's answer. David, > my guess is that all of these combined should be smaller > than GCC alone. There should be fewer users, too. > > > >Thanks for the work, I'll just clone it right now :) > > Be our guest, and let me know if you find a way to > repack the repo to a smaller size. I just upgraded my git to 1.5.2 and repacked the git repository with git-gc --aggressive. It is quite impressive: the size of the pack file was almost cut in half, from ~23MB to ~12MB! Gabriel
Re: Very Fast: Directly Coded Lexical Analyzer
Hi, my questions is, why not use the element construction algorithm? The Thomson Algorithm creates an epsilon-NFA which needs quite a lot of memory. The element construction creates an NFA directly and therefor has fewer states. Well, this is only interesting in the scanner creation which is not so important than the scanner itself, but it can reduce the memory footprint of generator. It's a pity i can't find a url for the algorithmdescription, maybe i even have the wrong naming of it. I have only read it in script Compiler Construction at the University. cu, Ronny pgppPnWr9BDsO.pgp Description: PGP signature
Re: Git repository with full GCC history
On Thu, 2007-05-31 21:34:33 -0400, Bernardo Innocenti <[EMAIL PROTECTED]> wrote: > I've set up a Git mirror of the entire GCC history on > server space kindly provided by David Woodhouse. > > You can clone it with: > > git-clone git://git.infradead.org/gcc.git How often will it be synced with upstream SVN? While you're at it, would David mind to also place a binutils, glibc and glibc-ports GIT repo next to it? That way, there would be a nice single point of GIT repos for the whole toolchain. Thanks for the work, I'll just clone it right now :) MfG, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED] +49-172-7608481 Signature of:http://www.chiark.greenend.org.uk/~sgtatham/bugs.html the second : signature.asc Description: Digital signature
Re: Very Fast: Directly Coded Lexical Analyzer
2007/6/1, Frank Schaefer <[EMAIL PROTECTED]> wrote: > To obtain 200-250% in speed gain won't be possible for this GCC > optimizing compiler because of http://en.wikipedia.org/wiki/Amdahl%27s_law Amdahl's Law talks about paralellism. That is not the case here. He apply a different approach for lexical analysis as mentioned above. If you talk about the influence of a new lexer to the speed of the whole compiler, I would aggree that the a speed up factor 2 is not possible if lexical analysis constitutes less than 50% of the total computation effort (simple math). Amdahl's Law talks about sequential improvement too. http://en.wikipedia.org/wiki/Amdahl%27s_law#Speedup_in_a_sequential_program
Re: Git repository with full GCC history
On Fri, 2007-06-01 12:12:59 +0200, Gabriel Paubert <[EMAIL PROTECTED]> wrote: > On Fri, Jun 01, 2007 at 04:47:11AM -0400, Bernardo Innocenti wrote: > > Be our guest, and let me know if you find a way to > > repack the repo to a smaller size. > > I just upgraded my git to 1.5.2 and repacked the git repository > with git-gc --aggressive. It is quite impressive: the size of > the pack file was almost cut in half, from ~23MB to ~12MB! This is way more that I expected. I'm officially impressed right now. MfG, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED] +49-172-7608481 Signature of: Fortschritt bedeutet, einen Schritt so zu machen, the second : daß man den nächsten auch noch machen kann. signature.asc Description: Digital signature
synchronous cancel and "terminate called without an active exception"
Hi all,
please don't panish me, I know there were plenty of discussions concerning
this subject, however I'm a newbie in multi-threaded programming :-) and
couldn't find a good explanation to my problem in former discussions..
so, perhaps somebody could "redirect" my question to the appropriate thread..
At the end you can see a piece of code. The problem is the following:
for some reason the 'new operator' affects thread cancellation: namely
if one uses the 'new operator' which is able to throw exceptions then thread
cancellation results in abort with
"terminate called without an active exception"..
here is the gdb trace:
#0 0xb7c6783b in raise () from /lib/tls/libc.so.6
#1 0xb7c68fa2 in abort () from /lib/tls/libc.so.6
#2 0xb7f123ce in __gnu_cxx::__verbose_terminate_handler ()
at ../../.././libstdc++-v3/libsupc++/vterminate.cc:96
#3 0xb7f0fed5 in __cxxabiv1::__terminate (handler=0xb7f12260
<__gnu_cxx::__verbose_terminate_handler()>)
at ../../.././libstdc++-v3/libsupc++/eh_terminate.cc:43
#4 0xb7f0ff12 in std::terminate ()
at ../../.././libstdc++-v3/libsupc++/eh_terminate.cc:53
#5 0xb7f0fd74 in __gxx_personality_v0 (version=1, actions=10,
exception_class=3083066116, ue_header=0x0, context=0xb7c3d968)
at ../../.././libstdc++-v3/libsupc++/eh_personality.cc:420
#6 0xb7d78776 in _Unwind_ForcedUnwind_Phase2 (exc=0xb7c3ddd0,
context=0xb7c3d968) at unwind.inc:180
#7 0xb7d78857 in _Unwind_ForcedUnwind (exc=0xb7c3ddd0, stop=0,
stop_argument=0x0) at unwind.inc:211
#8 0xb7e4301a in _Unwind_ForcedUnwind () from /lib/tls/libpthread.so.0
#9 0xb7e411c3 in __pthread_unwind () from /lib/tls/libpthread.so.0
#10 0xb7e3ff33 in pthread_testcancel () from /lib/tls/libpthread.so.0
#11 0x08048ecc in thread_function (arg=0x0) at mt.C:166
#12 0xb7e3cb63 in start_thread () from /lib/tls/libpthread.so.0
#13 0xb7d1718a in clone () from /lib/tls/libc.so.6
Note that if one uses new(std::nothrow) version, the program works fine..
Of course in this case I can use nothrow version however this is only a small
piece of code and I need to understand the roots of this behavior otherwise I
cannot work around it in a real program..
I know this has to deal with an exception mechanism in gcc, as synchronous
cancellation is seemingly processed as c++ exception..
I also tried to compile the program with -fno-exceptions flag and it works..
I use gcc 3.4.5
gcc -v:
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--with-system-zlib --enable-nls --without-included-gettext
--enable-clocale=gnu --enable-debug
and compiled my program with -pthread flag.
below is the code:
class BigBug {
public:
BigBug() {
x = new(std::nothrow) int;
//x = new int; // uncomment this to get an error
}
~BigBug() {
delete x;
}
int *get_x() {
return x;
}
private:
int *x;
};
void* thread_function (void*)
{
BigBug *aa = new(std::nothrow) BigBug;
//BigBug *aa = new BigBug; // uncomment this to get an error
aa->get_x();
delete aa;
while(1) {
pthread_testcancel();
}
return NULL;
}
int main ()
{
pthread_t thread;
pthread_attr_t attr;
pthread_attr_init(&attr);
pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);
pthread_create (&thread, &attr, &thread_function, (void *)NULL);
sleep(2);
puts("cancelling thread..\n");
pthread_cancel(thread[0]);
sleep(1);
return 0;
}
best regards,
Pavel
[OT] Re: Git repository with full GCC history
On Fri, Jun 01, 2007 at 12:51:15PM +0200, Jan-Benedict Glaw wrote: > On Fri, 2007-06-01 12:12:59 +0200, Gabriel Paubert <[EMAIL PROTECTED]> wrote: > > On Fri, Jun 01, 2007 at 04:47:11AM -0400, Bernardo Innocenti wrote: > > > Be our guest, and let me know if you find a way to > > > repack the repo to a smaller size. > > > > I just upgraded my git to 1.5.2 and repacked the git repository > > with git-gc --aggressive. It is quite impressive: the size of > > the pack file was almost cut in half, from ~23MB to ~12MB! > > This is way more that I expected. I'm officially impressed right now. Apparently this was an exceptional case, I've been regularly repacking (git-repack -a -d) and more recently cleaning (git-gc) this repository since the early days of git (Mid 2005). This should therefore be compared to the first pack file generation and I don't believe that you will ever get that factor on any repository created with a more recent version of git. There is however a difference between even recent versions of git, the pack for the linux kernel is today: $ ls -l .git/objects/pack/ total 182140 -rw-r--r-- 1 paubert src 11887736 Jun 1 12:48 pack-dee9b723599778238ea89166583a609b415037bd.idx -rw-r--r-- 1 paubert src 174426948 Jun 1 12:48 pack-dee9b723599778238ea89166583a609b415037bd.pack with git (repack -a -d -f) from Debian Etch (1.4.4.4), and: $ ls -l .git/objects/pack/ total 164232 -r--r--r-- 1 paubert src 11887736 Jun 1 12:24 pack-dee9b723599778238ea89166583a609b415037bd.idx -r--r--r-- 1 paubert src 156105549 Jun 1 12:24 pack-dee9b723599778238ea89166583a609b415037bd.pack using a freshly compiled git (1.5.2.146.gb75c6) and git-gc --aggressive. That's in the ballpark of the 10% (actually a bit better) announced in the 1.5.2 release notes. Gabriel
signal unwind and fp state
Hi, While working on a vdso for Linux/m68k I stumbled again on a problem, I already had with the fallback unwind handler in gcc, where I'd like to hear some opinions. I'm looking at the i386 unwind handler and that doesn't bother to restore any fp registers. On m68k it's a little more difficult as the fp register are saved/restored conditionally. There are also a few fp control register on the stack, which are currently not restored via unwind. The question maybe here is what really needs to restored via the signal frame? If it's only for exception handling call clobbered registers wouldn't really need to be restored (often they are even immediately overwritten again to setup the exception handler) and even call saved register don't really need to restored as that should already be done via the frame of the signal handler itself (and depends on SA_SIGINFO anyway). So is there really any need to restore in the signal frame more than return address and frame address? AFAICT that should be enough for exception handling, but maybe there is something else... bye, Roman
Re: Optimizations for itanium
"Prasad, Kamal R" <[EMAIL PROTECTED]> writes: > Can someone tell me the back-end optimizations available for itanium > (IA64)? > We (HP) may be able to contribute to this from our side. GCC implements more or less the same set of optimizations for all targets. I don't think there are any IA64 specific optimizations in gcc. Obviously all the details related to code generation are IA64 specific, and the IA64 is the only user of several hooks into the instruction scheduler. Contributions would be very welcome. Ian
Re: __builtin_apply_args - GCC 4.1.1
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
> I am working with a private target(GCC v4.1.1).
> For my target the function arguments are passed through registers.
> For this purpose 4 registers are used. If the no. of arguments are
> more than 4, the remaining arguments are passed through stack.
>
> But for varargs the arguments are pushed into the stack by the caller
> function.
These days the usual style is to handle arguments for normal and
varargs functions in exactly the same way. This avoids errors when
calling a function without a proper prototype in scope. But certainly
what you describe is a valid way to implement a backend.
> void foo(char *name, int d, int e, int f, int g)
> {
> printf("\nname = %s\n13 = %d\n72 = %d\n89 = %d\n5 = %d\n", name,d,e,f,g );
> }
>
> void bar(char *name, ...)
> {
> void **arg;
> arg = __builtin_apply_args();
>__builtin_apply(foo, arg, 24);
> }
For your platform, __builtin_apply will only work when the callee has
the same signature as the caller. __builtin_apply has no support for
changing the way that arguments are passed. It simply passes the
arguments to the callee in the same way that they were passed to the
caller.
Before you really dig into this, do you care? __builtin_apply only
exists to implement the Objective C runtime. And in fact it is
generally considered desirable to change that code to use libffi
instead, in which case __builtin_apply will probably be deprecated and
removed. If you don't need to compile Objective C, I wouldn't worry
about __builtin_apply.
Ian
Re: signal unwind and fp state
Roman Zippel <[EMAIL PROTECTED]> writes: > While working on a vdso for Linux/m68k I stumbled again on a problem, I > already had with the fallback unwind handler in gcc, where I'd like to > hear some opinions. > I'm looking at the i386 unwind handler and that doesn't bother to restore > any fp registers. On m68k it's a little more difficult as the fp register > are saved/restored conditionally. There are also a few fp control register > on the stack, which are currently not restored via unwind. > > The question maybe here is what really needs to restored via the signal > frame? If it's only for exception handling call clobbered registers > wouldn't really need to be restored (often they are even immediately > overwritten again to setup the exception handler) and even call saved > register don't really need to restored as that should already be done via > the frame of the signal handler itself (and depends on SA_SIGINFO anyway). > > So is there really any need to restore in the signal frame more than > return address and frame address? AFAICT that should be enough for > exception handling, but maybe there is something else... I don't know the answer. But I do know that you need to think about -fasynchronous-unwind-tables, and you need to think about how your kernel handles registers when calling a handler, and you need to think about what unwind information is available in the kernel, if any. If the kernel does not provide unwind information showing that the signal handling call restores registers, then it seems to me that the stack unwinder needs to restore at least all caller saved registers from the signal frame. Whether it needs to restore the floating point registers depends upon whether the kernel can ever modify those registers. Ian
Re: [OT] Re: Git repository with full GCC history
Gabriel Paubert wrote: This may be the pack depth which was increased to 50 according to 1.5.2 release notes: I've repacked with 1.5.2, and it doesn't seem to decrease the repo size considerably. I'm now repacking with "git-repack -a -d -f --window=20 --depth=100", but it takes a lot of time on this old mule. -- // Bernardo Innocenti \X/ http://www.codewiz.org/
Re: Git repository with full GCC history
Gabriel Paubert wrote: I just upgraded my git to 1.5.2 and repacked the git repository with git-gc --aggressive. It is quite impressive: the size of the pack file was almost cut in half, from ~23MB to ~12MB! The --aggressive option is undocumented in 1.5.2. What is it supposed to do? -- // Bernardo Innocenti \X/ http://www.codewiz.org/
[OT] Re: Git repository with full GCC history
On Fri, Jun 01, 2007 at 11:00:29AM -0400, Bernardo Innocenti wrote: > Gabriel Paubert wrote: > > >I just upgraded my git to 1.5.2 and repacked the git repository > >with git-gc --aggressive. It is quite impressive: the size of > >the pack file was almost cut in half, from ~23MB to ~12MB! > > The --aggressive option is undocumented in 1.5.2. What > is it supposed to do? > It is documented in my freshly compiled and installed git: --aggressive Usually git-gc runs very quickly while providing good disk space utilization and performance. This option will cause git-gc to more aggressive optimize the repository at the expense of taking much more time. The effects of this optimization are persistent, so this option only needs to be sporadically; every few hundred changesets or so. Regards, Gabriel
Re: signal unwind and fp state
Hi, On Fri, 1 Jun 2007, Ian Lance Taylor wrote: > I don't know the answer. But I do know that you need to think about > -fasynchronous-unwind-tables, and you need to think about how your > kernel handles registers when calling a handler, and you need to think > about what unwind information is available in the kernel, if any. If > the kernel does not provide unwind information showing that the signal > handling call restores registers, then it seems to me that the stack > unwinder needs to restore at least all caller saved registers from the > signal frame. Whether it needs to restore the floating point > registers depends upon whether the kernel can ever modify those > registers. The kernel doesn't modify any register when entering the signal handler, so strictly speaking during unwind one only needs to undo changes done by the signal handler itself. Currently I'm more thinking in the direction of gdb, where the information about the call clobbered registers would be useful, so I'm thinking about two sets of unwind information in .eh_frame/.debug_frame. bye, Roman
Re: Optimizations for itanium
Prasad, Kamal R wrote: Hello, Can someone tell me the back-end optimizations available for itanium (IA64)? We (HP) may be able to contribute to this from our side. Sorry, it is ambiguous question. There are a lot of optimizations in GCC. Most of them are available for Itanium. If you are interesting in the state of optimizations specific and quite important for Itanium, then here is the list of a few of them: o data dependence and alias analysis. It is pretty good on tree-SSA level (you could ask Daniel Berlin [EMAIL PROTECTED] and Diego Novillo [EMAIL PROTECTED] about details) but this information is not propagated to RTL. ISP (institute for system programming) of RAS (Russian Academy of Sciences) have been working on this but I don't know the current status of the work. Please contact Andrew Belevantsev [EMAIL PROTECTED] if you want to know more. o modulo scheduling. GCC has swing modulo scheduling (please ask Ayal Zaks [EMAIL PROTECTED] about the details). Imho, major problem with the implementation is absence a good data-dependency analysis on this level, difficulties to use DFA for pipelining, and modulo scheduling is done early (there are code changes after that). A lot of thing can be done to improve it (including predicated prologue/epilogue loops). o instruction scheduling. GCC uses regional insn scheduler without insn cloning which is originated from Haifa scheduler and supports data and control speculation (that was implemented by ISP RAS). There is ongoing work to implement more sophisticated insn-scheduler (including enhanced software pipelining). This work is close to selective scheduling. The work is done by ISP RAS, so please contact to them about the details. o data prefetching. It has been implemented on tree-SSA level by Zdenek Dvorak ([EMAIL PROTECTED]). Imho, this implementation is in a pretty good shape. The major problem of the contribution of a code to GCC from other compilers is the different environment (IR, infrastructure, coding standards and so on). For example, Haifa insn scheduler has been contributed almost 10 years ago and imho still not fully integrated yet. There are also legal issue to bring the code. So I think it is more productive to work on improvement of the current GCC implementation. But may be I am wrong and your code has a very a good interface and can be easily integrated in any compiler. Vlad
RE: Optimizations for itanium
Hi! Has there been any contribution from HP at all on itanium specific optimizations? I am referring to instruction scheduling and stuff at that level. Our interfaces are derived largely from stanford (SUIF) -but if I had to contribute, I can contribute to the existing environment. It is a question of whether the gcc team needs optimizations and/or someone else from HP is already contributing towards that (and of course whether HP's policy allows for me to controbute). Regards -kamal -Original Message- From: Vladimir N. Makarov [mailto:[EMAIL PROTECTED] Sent: Friday, June 01, 2007 8:53 PM To: Prasad, Kamal R Cc: gcc@gcc.gnu.org Subject: Re: Optimizations for itanium Prasad, Kamal R wrote: >Hello, > > Can someone tell me the back-end optimizations available for itanium >(IA64)? >We (HP) may be able to contribute to this from our side. > > > Sorry, it is ambiguous question. There are a lot of optimizations in GCC. Most of them are available for Itanium. If you are interesting in the state of optimizations specific and quite important for Itanium, then here is the list of a few of them: o data dependence and alias analysis. It is pretty good on tree-SSA level (you could ask Daniel Berlin [EMAIL PROTECTED] and Diego Novillo [EMAIL PROTECTED] about details) but this information is not propagated to RTL. ISP (institute for system programming) of RAS (Russian Academy of Sciences) have been working on this but I don't know the current status of the work. Please contact Andrew Belevantsev [EMAIL PROTECTED] if you want to know more. o modulo scheduling. GCC has swing modulo scheduling (please ask Ayal Zaks [EMAIL PROTECTED] about the details). Imho, major problem with the implementation is absence a good data-dependency analysis on this level, difficulties to use DFA for pipelining, and modulo scheduling is done early (there are code changes after that). A lot of thing can be done to improve it (including predicated prologue/epilogue loops). o instruction scheduling. GCC uses regional insn scheduler without insn cloning which is originated from Haifa scheduler and supports data and control speculation (that was implemented by ISP RAS). There is ongoing work to implement more sophisticated insn-scheduler (including enhanced software pipelining). This work is close to selective scheduling. The work is done by ISP RAS, so please contact to them about the details. o data prefetching. It has been implemented on tree-SSA level by Zdenek Dvorak ([EMAIL PROTECTED]). Imho, this implementation is in a pretty good shape. The major problem of the contribution of a code to GCC from other compilers is the different environment (IR, infrastructure, coding standards and so on). For example, Haifa insn scheduler has been contributed almost 10 years ago and imho still not fully integrated yet. There are also legal issue to bring the code. So I think it is more productive to work on improvement of the current GCC implementation. But may be I am wrong and your code has a very a good interface and can be easily integrated in any compiler. Vlad
Re: Optimizations for itanium
Prasad, Kamal R wrote: Hi! Has there been any contribution from HP at all on itanium specific optimizations? I am referring to instruction scheduling and stuff at that level. Please, ask Steve Ellcey [EMAIL PROTECTED] about this. He is most active developer of GCC from HP. Our interfaces are derived largely from stanford (SUIF) -but if I had to contribute, I can contribute to the existing environment. It is a question of whether the gcc team needs optimizations and/or someone else from HP is already contributing towards that (and of course whether HP's policy allows for me to controbute). I think you should have figured out about HP policy first and do some legal paper work with FSF. Also I thnk contribution means maintaince too. Sorry, I don't understand question about gcc team needs optimizations. Many gcc developers are busy and not really interesting in Itanium (which is a niche platform). But there are a lof of GCC users which are interesting in better Itanium GCC. For example, as I rember about 70% of Gelato members would prefer to use gcc on Itanium than other compiler. Gcc Itanium performance is far behind Intel compiler and it needs to be improved. Vlad
Re: [OT] Re: Git repository with full GCC history
Gabriel Paubert wrote: On Fri, Jun 01, 2007 at 11:00:29AM -0400, Bernardo Innocenti wrote: Gabriel Paubert wrote: I just upgraded my git to 1.5.2 and repacked the git repository with git-gc --aggressive. It is quite impressive: the size of the pack file was almost cut in half, from ~23MB to ~12MB! The --aggressive option is undocumented in 1.5.2. What is it supposed to do? It is documented in my freshly compiled and installed git: In the source, I see it just passes "-f" to git-repack, which I already did manually, with no improvement. So there must be something strange in your repository if it packs that much better than mine. Could you please publish it somewhere so I can make some tests? -- // Bernardo Innocenti \X/ http://www.codewiz.org/
Predictive commoning miscompiles 482.sphinx3 in SPEC CPU 2006
The predictive commoning patch: http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01061.html miscompiles 482.sphinx3 in SPEC CPU 2006 with -O2 -ffast-math on Linux/x86-64. Zdenek, do you have any ideas? BTW, we are working on a small testcase. H.J.
Re: Predictive commoning miscompiles 482.sphinx3 in SPEC CPU 2006
On Fri, Jun 01, 2007 at 09:37:54AM -0700, H. J. Lu wrote: > The predictive commoning patch: > > http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01061.html > > miscompiles 482.sphinx3 in SPEC CPU 2006 with -O2 -ffast-math on > Linux/x86-64. Zdenek, do you have any ideas? > Something is wrong. Predictive commoning is supposed to be turned on at -O3. But it definitely afffects -O2. Why? H.J.
Re: Predictive commoning miscompiles 482.sphinx3 in SPEC CPU 2006
On 6/1/07, H. J. Lu <[EMAIL PROTECTED]> wrote: On Fri, Jun 01, 2007 at 09:37:54AM -0700, H. J. Lu wrote: > The predictive commoning patch: > > http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01061.html > > miscompiles 482.sphinx3 in SPEC CPU 2006 with -O2 -ffast-math on > Linux/x86-64. Zdenek, do you have any ideas? > Something is wrong. Predictive commoning is supposed to be turned on at -O3. But it definitely afffects -O2. Why? Because the patch had other effects like adding a DCE after Copyprop in the loop optimizer section. This actually speed up a couple of benchmarks in SPEC 2k too (mgrid and apsi comes to mind). Thanks, Andrew Pinski
DOC PATCH: attribute(alloc_size)
Hi, addition of alloc_size attribute to the changes.html. Ciao, Marcus Index: htdocs/gcc-4.3/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.3/changes.html,v retrieving revision 1.57 diff -u -r1.57 changes.html --- htdocs/gcc-4.3/changes.html 25 May 2007 17:20:59 - 1.57 +++ htdocs/gcc-4.3/changes.html 1 Jun 2007 16:28:01 - @@ -199,6 +199,18 @@ the diverse warnings enabled by -Wextra. + +A new function attribute alloc_size has been added to +mark up malloc style functions. For constant sized +allocations this can be used to find out the size of the returned +pointer using the __builtin_object_size() function +for buffer overflow checking and similar. +This supplements the already built-in malloc and +calloc constant size handling and is useful for any +allocator function like g_malloc() from glib2 or HeapAlloc() +from the Win32 implementation in Wine. + + C++
Re: DOC PATCH: attribute(alloc_size)
On Fri, Jun 01, 2007 at 06:28:52PM +0200, Marcus Meissner wrote: > Hi, > > addition of alloc_size attribute to the changes.html. > > Ciao, Marcus Less plugging of examples as suggested by Dirk... Index: htdocs/gcc-4.3/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.3/changes.html,v retrieving revision 1.57 diff -u -r1.57 changes.html --- htdocs/gcc-4.3/changes.html 25 May 2007 17:20:59 - 1.57 +++ htdocs/gcc-4.3/changes.html 1 Jun 2007 16:59:02 - @@ -199,6 +199,16 @@ the diverse warnings enabled by -Wextra. + +A new function attribute alloc_size has been added to +mark up malloc style functions. For constant sized +allocations this can be used to find out the size of the returned +pointer using the __builtin_object_size() function +for buffer overflow checking and similar. +This supplements the already built-in malloc and +calloc constant size handling. + + C++
Re: Predictive commoning miscompiles 482.sphinx3 in SPEC CPU 2006
On Fri, Jun 01, 2007 at 09:55:53AM -0700, Andrew Pinski wrote: > > Because the patch had other effects like adding a DCE after Copyprop > in the loop optimizer section. > Disable DCE after Copyprop in the loop optimizer section fixes my problem. Any idea why? Thanks. H.J.
Re: Predictive commoning miscompiles 482.sphinx3 in SPEC CPU 2006
On 6/1/07, H. J. Lu <[EMAIL PROTECTED]> wrote: On Fri, Jun 01, 2007 at 09:55:53AM -0700, Andrew Pinski wrote: > > Because the patch had other effects like adding a DCE after Copyprop > in the loop optimizer section. > Disable DCE after Copyprop in the loop optimizer section fixes my problem. Any idea why? No idea, you have to look into why the miscompiling is happening, are you sure that the program does not violate C/C++ aliasing rules? Thanks, Andrew Pinski
What is purpose of numbered variables??
Hi. What is purpose of introducing numbered variables kind of a.0 a.1...in pre-SSA pass, which are actually copies of local variable say a. I observed them specially in array references. In case of global variable it is fine as we have to re-read global variable and globals are treated as memory operations. Is this only purpose in case of globals?? e.g int b; //local variable array[b] = c will be translated to b.0 = b; array[b.0] = c anything to do with SSA? What if we disable them? -Seema Ravandale
Re: Optimizations for itanium
Prasad, Kamal R wrote: Hello, Can someone tell me the back-end optimizations available for itanium (IA64)? We (HP) may be able to contribute to this from our side. To add to the summary Vlad already did, you may want to take a look at the notes from the last meeting of the Gelato GCC Itanium group in Moscow available at http://gcc.gelato.org/MeetingNotes. This is a good summary of what is considered the most important works for Itanium in GCC. More information about the meeting is at http://gcc.gelato.org/MoscowMeeting. Our team is currently focused on performance tuning and compile time improvement of the new scheduler for Itanium, available on the sel-sched branch. As of data dependence propagation, there will be a Google SoC project about this; I hope to have more data in a few weeks to discuss. I have sent a patch to fix modulo scheduling on Itanium some time ago. It was considered acceptable by IBM folks, and I think that it will go in with the other fixes done by them, but I don't know the details. Also, Dmitry Zhurikhin from our team tried to use resource-aware constraints in modulo scheduling for his MS thesis, which worked for two tests from SPEC. He will work on better heuristics for scheduling in another SoC project this summer. I would also suggest to tune default parameters of some optimizations for Itanium. For example, there was a patch from Canqun Yang about increasing prefetching parameters for Itanium, which produced much better results than the default values. However, that was for the old RTL prefetch pass, which is replaced by the tree ssa implementation done by Zdenek. Inlining parameters for Itanium can be more aggressive too. This kind of work is quite simple, but requires a lot of machine resources, and people usually don't have access to many Itaniums. (We have only two, for example.) So maybe you can help here. Andrey
Re: Predictive commoning miscompiles 482.sphinx3 in SPEC CPU 2006
Hello, > > Because the patch had other effects like adding a DCE after Copyprop > > in the loop optimizer section. > > > > Disable DCE after Copyprop in the loop optimizer section fixes my > problem. Any idea why? no, not really; it could be anything (it may even have nothing to do with dce, performing dce can enable/alter other loop transformations). Zdenek
Re: Predictive commoning miscompiles 482.sphinx3 in SPEC CPU 2006
On Fri, Jun 01, 2007 at 10:30:52PM +0200, Zdenek Dvorak wrote: > Hello, > > > > Because the patch had other effects like adding a DCE after Copyprop > > > in the loop optimizer section. > > > > > > > Disable DCE after Copyprop in the loop optimizer section fixes my > > problem. Any idea why? > > no, not really; it could be anything (it may even have nothing to do > with dce, performing dce can enable/alter other loop transformations). I opened a bug report: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32183 H.J.
gcc-4.3-20070601 is now available
Snapshot gcc-4.3-20070601 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070601/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 125268 You'll find: gcc-4.3-20070601.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20070601.tar.bz2 C front end and core compiler gcc-ada-4.3-20070601.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20070601.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20070601.tar.bz2 C++ front end and runtime gcc-java-4.3-20070601.tar.bz2 Java front end and runtime gcc-objc-4.3-20070601.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20070601.tar.bz2The GCC testsuite Diffs from 4.3-20070525 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 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: __builtin_apply_args - GCC 4.1.1
On 01 Jun 2007 07:22:39 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
> I am working with a private target(GCC v4.1.1).
> For my target the function arguments are passed through registers.
> For this purpose 4 registers are used. If the no. of arguments are
> more than 4, the remaining arguments are passed through stack.
>
> But for varargs the arguments are pushed into the stack by the caller
function.
These days the usual style is to handle arguments for normal and
varargs functions in exactly the same way. This avoids errors when
calling a function without a proper prototype in scope. But certainly
what you describe is a valid way to implement a backend.
Initially implementation was same for both. But DWARF2 was going wrong
for varargs function. So we had to change the implementation for that.
What we did was removing the target hook TARGET_SETUP_INCOMING_VARARGS.
> void foo(char *name, int d, int e, int f, int g)
> {
> printf("\nname = %s\n13 = %d\n72 = %d\n89 = %d\n5 = %d\n", name,d,e,f,g );
> }
>
> void bar(char *name, ...)
> {
> void **arg;
> arg = __builtin_apply_args();
>__builtin_apply(foo, arg, 24);
> }
For your platform, __builtin_apply will only work when the callee has
the same signature as the caller. __builtin_apply has no support for
changing the way that arguments are passed. It simply passes the
arguments to the callee in the same way that they were passed to the
caller.
This test case passed before removing the target hook
TARGET_SETUP_INCOMING_VARARGS. All that changed is that now varable
arguments are pushed into the stack by the caller function. So i guess
the term "same signature" also include the way the arguments are
passed by the functions.
Before you really dig into this, do you care? __builtin_apply only
exists to implement the Objective C runtime. And in fact it is
generally considered desirable to change that code to use libffi
instead, in which case __builtin_apply will probably be deprecated and
removed. If you don't need to compile Objective C, I wouldn't worry
about __builtin_apply.
I am concerned about only C. If __builtin_apply is important only in
Objective C why is it that this test case is included in C test suites
?
If the outcome of the test cases involving __builtin_apply and
__builtin_apply_args doesnt matter for a C compiler is it proper to
include them in the C testsuites ?
Regards,
Shafi.
Re: __builtin_apply_args - GCC 4.1.1
"Mohamed Shafi" <[EMAIL PROTECTED]> writes: > On 01 Jun 2007 07:22:39 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > > "Mohamed Shafi" <[EMAIL PROTECTED]> writes: > > > > > I am working with a private target(GCC v4.1.1). > > > For my target the function arguments are passed through registers. > > > For this purpose 4 registers are used. If the no. of arguments are > > > more than 4, the remaining arguments are passed through stack. > > > > > > But for varargs the arguments are pushed into the stack by the caller > > > function. > > > > These days the usual style is to handle arguments for normal and > > varargs functions in exactly the same way. This avoids errors when > > calling a function without a proper prototype in scope. But certainly > > what you describe is a valid way to implement a backend. > > Initially implementation was same for both. But DWARF2 was going wrong > for varargs function. So we had to change the implementation for that. > What we did was removing the target hook TARGET_SETUP_INCOMING_VARARGS. That doesn't seem like the right approach to me, but, whatever. > > For your platform, __builtin_apply will only work when the callee has > > the same signature as the caller. __builtin_apply has no support for > > changing the way that arguments are passed. It simply passes the > > arguments to the callee in the same way that they were passed to the > > caller. > > This test case passed before removing the target hook > TARGET_SETUP_INCOMING_VARARGS. All that changed is that now varable > arguments are pushed into the stack by the caller function. So i guess > the term "same signature" also include the way the arguments are > passed by the functions. The signature is the type of the function, including the return type and the parameter types and whether an ellipsis is used, so, yes. > > Before you really dig into this, do you care? __builtin_apply only > > exists to implement the Objective C runtime. And in fact it is > > generally considered desirable to change that code to use libffi > > instead, in which case __builtin_apply will probably be deprecated and > > removed. If you don't need to compile Objective C, I wouldn't worry > > about __builtin_apply. > > I am concerned about only C. If __builtin_apply is important only in > Objective C why is it that this test case is included in C test suites > ? > If the outcome of the test cases involving __builtin_apply and > __builtin_apply_args doesnt matter for a C compiler is it proper to > include them in the C testsuites ? They need to work in C in order to implement the Objective C runtime. Besides, they are documented, so they should be tested. Ian
