On Sat, Nov 14, 2009 at 2:13 PM, Steven Bosscher wrote:
> On Sat, Nov 14, 2009 at 8:51 PM, Richard Guenther
> wrote:
>> Note that some optimizers (for example value-numbering) contain cut-offs
>> so that they are turned off for large functions as otherwise compile-time
>> issues appear as algorit
Richard Guenther wrote:
2009/11/14 Toon Moene :
However, my endeavour is to boldly go where no inliner has gone before, and
implement -falways-inline-functions-only-called-once, along the following
lines:
...
(Sugg. b. Rich. G.), because inlining functions that are only called once is
a
On Sat, Nov 14, 2009 at 8:51 PM, Richard Guenther
wrote:
> Note that some optimizers (for example value-numbering) contain cut-offs
> so that they are turned off for large functions as otherwise compile-time
> issues appear as algorithms are non-linear in the size of the function.
>
> So it might
2009/11/14 Toon Moene :
> Jan Hubicka wrote:
>
>> -fno-ipa-cp should work around your problem for time being.
>
> Indeed it did. Some figures:
>
> hlprog (the main forecast program):
>
> link time optimization time: 3:20 minutes
> top memory usage: 920 Mbyte
>
> Inliner report:
>
> Inli
On Sun, Nov 8, 2009 at 19:10, Larry Evans wrote:
> Does someone know of a way to view this in a graphical way,
> somewhat like what xvcg does for its cfg's?
When I've needed to visualize a CFG, I just used a very simplistic
script to paw through the dump file to produce graphviz output
(attached
Jan Hubicka wrote:
-fno-ipa-cp should work around your problem for time being.
Indeed it did. Some figures:
hlprog (the main forecast program):
link time optimization time: 3:20 minutes
top memory usage:920 Mbyte
Inliner report:
Inlined 764 calls, eliminated 226 functions, siz
Hi all,
Just a small update, that after some discussions with Joern we think that based
on our
time constraints and the current state of GCC, instead of trying to push full
ICI into GCC
we start from the opposite approach:
We take all our plugins (support pass selection and reordering from MILE
LIBOBJS includes a strcasecmp.s$U.s
That suffix is certainly strange-looking though. I checked in
config.log and I can see that it automatically detected that
my "object code" has a ".s" extension, which is basically
correct given that I forced the "-S" option.
Why do you pass -S in the compil
* Paul Edwards wrote on Sat, Nov 14, 2009 at 09:51:39AM CET:
> >Well, the configure process should result in the variable LIBOBJS
> >in the generated libiberty Makefile to be set to list of objects
> >containing implementations of replacement system routines.
> >
> >So if you do not have HAVE_STRCA
Well, the configure process should result in the variable LIBOBJS
in the generated libiberty Makefile to be set to list of objects
containing implementations of replacement system routines.
So if you do not have HAVE_STRCASECMP in config.h, you should
have been getting strcasecmp.o in LIBOBJS ...
The submission deadline is extended until the 22nd of November, 2009.
Apologies if you receive multiple copies of this call.
CALL FOR PAPERS
2nd Workshop on
11 matches
Mail list logo
