As Richard Earnshaw wrote:
There's no need to hack everything up. As long as you have bash
installed on your machine, it's straight-forward to run CSiBE on
*BSD machines: simply invoke the makefiles with SHELL=.../bash.
That's what I did, but it doesn't help for the non-standard usage of
On Tue, 2007-05-01 at 09:07 +0200, Joerg Wunsch wrote:
As Richard Earnshaw wrote:
There's no need to hack everything up. As long as you have bash
installed on your machine, it's straight-forward to run CSiBE on
*BSD machines: simply invoke the makefiles with SHELL=.../bash.
That's
On Tue, 2007-05-01 at 12:43 +0200, Joerg Wunsch wrote:
As Richard Earnshaw wrote:
That's what I did, but it doesn't help for the non-standard usage
of /usr/bin/time (-f option). They even explicitly used
/usr/bin/time rather than bash's builtin.
No, it uses whichever time program
Please take this up with the CSiBE people. This is highly off-topic here.
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
On Fri, 2007-04-27 at 22:51 +0200, Joerg Wunsch wrote:
As Steven Bosscher wrote:
The idea behind that tool is great, I only wish the authors had
taken a class in portable shell scripting before. It's not that
all the world's a Vax these days...
Patches welcome, I guess.
Well,
Richard Earnshaw [EMAIL PROTECTED] writes:
There's no need to hack everything up. As long as you have bash
installed on your machine, it's straight-forward to run CSiBE on *BSD
machines: simply invoke the makefiles with SHELL=.../bash.
Or (pd)?ksh, for that matter.
Andreas.
--
Andreas
I'd rather remove this hack and use the inliners code size estimator, like
that patch from early 2005 (attached)...
Uh yes, I think it is way to go (and additionally making -O2 to
autoinline small functions like -Os does).
The patch would be OK if it still works ;) Even if CSiBE regress, I
On 27 April 2007 21:51, Joerg Wunsch wrote:
As Steven Bosscher wrote:
The idea behind that tool is great, I only wish the authors had
taken a class in portable shell scripting before. It's not that
all the world's a Vax these days...
Patches welcome, I guess.
Well, quite an amount of
On Saturday 28 April 2007 13:50:01 Dave Korn wrote:
On 27 April 2007 21:51, Joerg Wunsch wrote:
As Steven Bosscher wrote:
The idea behind that tool is great, I only wish the authors had
taken a class in portable shell scripting before. It's not that
all the world's a Vax these
René Rebe [EMAIL PROTECTED] writes:
sed -i is an evil GNU extension, likewise :-)
Also a FreeBSD extension.
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
On 28 April 2007 16:13, Andreas Schwab wrote:
René Rebe [EMAIL PROTECTED] writes:
sed -i is an evil GNU extension, likewise :-)
Also a FreeBSD extension.
I wasn't proposing it be put *into* the source, I was suggesting it be used
/on/ the source...
cheers,
DaveK
--
Can't
As René Rebe wrote:
find | sed -i would take most of the pain out of that if you
did want to try it...
sed -i is an evil GNU extension, likewise :-)
No, it's similarly available on FreeBSD. That would be fine with me
here, as it's only required to tweak the code, but would not be left
As Ian Lance Taylor wrote:
What's that test suite that has been mentioned here, and how to
run it?
http://www.inf.u-szeged.hu/csibe/
Thanks for the pointer. Got it. Alas, that tool is completely
unportable, and requires Linux to run. It suffers from bashomania
(like using $((I--)) when
On 4/27/07, Joerg Wunsch [EMAIL PROTECTED] wrote:
As Ian Lance Taylor wrote:
What's that test suite that has been mentioned here, and how to
run it?
http://www.inf.u-szeged.hu/csibe/
Thanks for the pointer. Got it. Alas, that tool is completely
unportable, and requires Linux to run.
As Steven Bosscher wrote:
The idea behind that tool is great, I only wish the authors had
taken a class in portable shell scripting before. It's not that
all the world's a Vax these days...
Patches welcome, I guess.
Well, quite an amount of work, alas. There's no central template in
CSiBE
On 4/25/07, Joerg Wunsch [EMAIL PROTECTED] wrote:
As Ian Lance Taylor wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31528
The relevant code is in opts.c:
if (optimize_size)
{
/* Inlining of very small functions usually reduces total size. */
set_param_value
As Ian Lance Taylor wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31528
The relevant code is in opts.c:
if (optimize_size)
{
/* Inlining of very small functions usually reduces total size. */
set_param_value (max-inline-insns-single, 5);
set_param_value
Joerg Wunsch [EMAIL PROTECTED] writes:
What's that test suite that has been mentioned here, and how to run
it?
http://www.inf.u-szeged.hu/csibe/
Ian
Kenneth Hoste [EMAIL PROTECTED] writes:
A related question: how is decided which priority a bug gets?
In general the release manager, Mark Mitchell, sets the priorities of
bugs in the bug database. He follows general guidelines where
wrong-code is more important, primary platforms are more
Hiya,
I'm doing research on which optimization passes to enable in the
various -On flags, and I've stumbled onto a/some minor bug(s) and
problems with the GCC documentation for the 4.1.2 version:
* When using -falign-loops or -fno-align-loops the corresponding
internal variable
On 4/17/07, Kenneth Hoste [EMAIL PROTECTED] wrote:
* On x86, -fschedule-insns is disabled, but -fschedule-insns2 (or the
corresponding internal flag flag_schedule_insns_after_reload) is
still being used... The reason for disabling fschedule-insns is
increased register pressure (and x86 has few
-Original Message-
From: Kenneth Hoste [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 17, 2007 3:23 AM
To: gcc@gcc.gnu.org
Subject: GCC -On optimization passes: flag and doc issues
- finline-functions is enabled at -Os, but isn't listed so
And it seems to have some issues:
http
Kenneth Hoste [EMAIL PROTECTED] writes:
* When using -falign-loops or -fno-align-loops the corresponding
internal variable 'align-loops' should be set to 0 (= use default
setting) or 1 (= no aligning) resp. When parsing the various flags, a
variable 'value' is used to set (value=1) or unset
On 17 Apr 2007, at 18:18, Eric Weddington wrote:
-Original Message-
From: Kenneth Hoste [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 17, 2007 3:23 AM
To: gcc@gcc.gnu.org
Subject: GCC -On optimization passes: flag and doc issues
- finline-functions is enabled at -Os, but isn't
On 4/17/07, Eric Weddington [EMAIL PROTECTED] wrote:
- finline-functions is enabled at -Os, but isn't listed so
And it seems to have some issues:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31528
Comments #4 and #6.
The only real issue here is a wrong expectation: That a certain
combination
-Original Message-
From: Steven Bosscher [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 17, 2007 2:52 PM
To: Eric Weddington
Cc: Kenneth Hoste; gcc@gcc.gnu.org
Subject: Re: GCC -On optimization passes: flag and doc issues
On 4/17/07, Eric Weddington [EMAIL PROTECTED] wrote
As Eric Weddington wrote:
And it seems to have some issues:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31528 Comments #4
and #6.
The only real issue here is a wrong expectation: That a certain
combination of flags magically does the best thing for every
target.
No, the issue is
On 4/17/07, Eric Weddington [EMAIL PROTECTED] wrote:
when perhaps they should
also notice that the efficiency of GCC for -Os has increased
tremendously in the past few years...
That is what you think is important. To AVR users, compile time could
increase by 100% and they wouldn't care, but
-Original Message-
From: Steven Bosscher [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 17, 2007 2:52 PM
To: Eric Weddington
Cc: Kenneth Hoste; gcc@gcc.gnu.org
Subject: Re: GCC -On optimization passes: flag and doc issues
On 4/17/07, Eric Weddington [EMAIL PROTECTED] wrote
Eric Weddington [EMAIL PROTECTED] writes:
Also, as you mention the target code has a chance to tune this ..., can you
give me a hint about
where to look for these knobs? I might give it a try to see whether I
can find a more optimal set of parameters.
This was in response to your comment
As Steven Bosscher wrote:
Maybe you can look at the development of code size of AVR over time,
and show a different trend, but I'd be surprised.
Most AVR users use -Os, as small code is fast code in most of the
cases on the AVR. The `overall summary' is that GCC continuously
decreased its
On 4/18/07, Joerg Wunsch [EMAIL PROTECTED] wrote:
As Eric Weddington wrote:
And it seems to have some issues:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31528 Comments #4
and #6.
The only real issue here is a wrong expectation: That a certain
combination of flags magically does
As Ian Lance Taylor wrote:
If the code size increases for AVR, when using -Os, when comparing an
older release to mainline or 4.2 branch, you should report that as a
regression in bugzilla. Thanks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31528
--
cheers, Jorg .-.-.
On Apr 17, 2007, at 2:56 PM, Eric Weddington wrote:
Well this begs the question of why, when there are so many
different targets, are there are only 4 optimization flags
(1,2,3,s), especially when they only get tuned to certain targets?
If you count again, you'll see there are more than 4
No, the issue is that the -Os option is *documented* to *only* include
those optimizations that are known to not increase the code size.
Where exactly is the documented? My documentation says It
enables optimisations that do not *typically* increase code size (emphasis
mine).
Many
-Original Message-
From: Ian Lance Taylor [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 17, 2007 4:20 PM
To: Eric Weddington
Cc: 'Steven Bosscher'; gcc@gcc.gnu.org; 'Joerg Wunsch';
'Anatoly Sokolov'
Subject: Re: GCC -On optimization passes: flag and doc issues
Eric
As Steven Bosscher wrote:
And now that you've shown that for this test case GCC actually may
have regressed on every target, you've shown that perhaps the global
inlining heuristics should be changed. May well be, for all I know.
Tuning heuristics is always hard and never provably optimal.
I
-Original Message-
From: Mike Stump [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 17, 2007 4:28 PM
To: Eric Weddington
Cc: 'Steven Bosscher'; gcc@gcc.gnu.org; 'Joerg Wunsch';
'Anatoly Sokolov'
Subject: Re: GCC -On optimization passes: flag and doc issues
On Apr 17, 2007
Joerg Wunsch [EMAIL PROTECTED] writes:
As Ian Lance Taylor wrote:
If the code size increases for AVR, when using -Os, when comparing an
older release to mainline or 4.2 branch, you should report that as a
regression in bugzilla. Thanks.
increase code size? I feel I must be missing something really
obvious... is
it just that the other optimisations that become possible on inline
code
usually compensate?
That or the savings from not having to save/restore registers, set up
the frame, etc as well.
-eric
On Tue, Apr 17, 2007 at 03:44:36PM -0700, Ian Lance Taylor wrote:
The relevant code is in opts.c:
if (optimize_size)
{
/* Inlining of very small functions usually reduces total size. */
set_param_value (max-inline-insns-single, 5);
set_param_value
On Wed, Apr 18, 2007 at 12:16:32AM +0100, Dave Korn wrote:
Sorry for butting in, but I just can't follow the reasoning here.
Unless a function is only ever used once and is inlined at the single
callsite, or unless the prolog and epilog are several times the size of
the function body, isn't
On 4/18/07, Joe Buck [EMAIL PROTECTED] wrote:
Perhaps the number of arguments should be taken into account as well.
We've been doing that for years.
Gr.
Steven
43 matches
Mail list logo
