Paolo Bonzini wrote:
We use to call this "benchmarketing"
I don't see why GNU would want to do that for anything.
Because (that's unfortunate, agreed) GCC does need some marketing.
Unfortunately people compare GCC with icc (or other compilers) using
SPEC,
Hmmm, that's not my experience
On Apr 19, 2006, at 11:52 AM, Daniel Berlin wrote:
So is this an object lesson for why optimizing for benchmarks is
a bad
idea?
If you're inclined to believe this, you could find a confirming
instance here, but there are other lessons that could be drawn. If
you go back to the original threa
> > So is this an object lesson for why optimizing for benchmarks is a bad
> > idea?
>
> If you're inclined to believe this, you could find a confirming
> instance here, but there are other lessons that could be drawn. If
> you go back to the original thread, you'll see this from Toon Moene:
Eric Botcazou wrote:
Unfortunately, GCC needs to do marketing of performance, just like
other compilers.
Not so obvious premise I'd personally think. Where would it come from?
Right, and even in the marketing domain, performance is just one
feature, and by no means the most important (compar
On Apr 19, 2006, at 12:04 AM, Kai Henningsen wrote:
[EMAIL PROTECTED] (Daniel Berlin) wrote on 18.04.06 in
<[EMAIL PROTECTED]>:
This is in fact, not terribly surprising, since the algorithm used
was the
result of Sebastian and I sitting at my whiteboard for 30 minutes
trying to
figure ou
> Unfortunately, GCC needs to do marketing of performance, just like
> other compilers.
Not so obvious premise I'd personally think. Where would it come from?
--
Eric Botcazou
On Apr 19, 2006, at 12:04 AM, Kai Henningsen wrote:
[EMAIL PROTECTED] (Daniel Berlin) wrote on 18.04.06 in
<[EMAIL PROTECTED]>:
This is in fact, not terribly surprising, since the algorithm used
was the
result of Sebastian and I sitting at my whiteboard for 30 minutes
trying to
figure
We use to call this "benchmarketing"
I don't see why GNU would want to do that for anything.
Because (that's unfortunate, agreed) GCC does need some marketing.
Unfortunately people compare GCC with icc (or other compilers) using
SPEC, and you want them to compare apples to apples -- compile
On Apr 19, 2006, at 9:00 AM, Neil Booth wrote:
So is this an object lesson for why optimizing for benchmarks is a
bad
idea?
We use to call this "benchmarketing"
I don't see why GNU would want to do that for anything.
Kai Henningsen wrote:-
> [EMAIL PROTECTED] (Daniel Berlin) wrote on 18.04.06 in <[EMAIL PROTECTED]>:
>
> > This is in fact, not terribly surprising, since the algorithm used was the
> > result of Sebastian and I sitting at my whiteboard for 30 minutes trying to
> > figure out what we'd need to d
[EMAIL PROTECTED] (Daniel Berlin) wrote on 18.04.06 in <[EMAIL PROTECTED]>:
> This is in fact, not terribly surprising, since the algorithm used was the
> result of Sebastian and I sitting at my whiteboard for 30 minutes trying to
> figure out what we'd need to do to make swim happy :).
> This w
Mark Mitchell wrote:
I'm going to send two messages to follow up because I think we've got
two different topics. This message is about:
> In any case, the broader question is: to what extent should we have
> experimental options in releases, and how should we warn users of their
> experimental n
Ok, point taken, and that is very reasonable.
What might be useful is a short article on the gcc web page for users
describing general guidelines regarding which features are generally
highly tested and supported and which are not.
This way you can add many experimental feautres and users wil
On Tue, Apr 18, 2006 at 06:14:27AM +, Ivan Novick wrote:
> Is it documented anywhere which gcc features should not be trusted or
> are known to have faults?
The only source of "known to have faults" is the bug database.
However, in any complex piece of software with many options, it simply
i
Daniel Berlin wrote:
> Thus, it is algorithmically unsound in it's current form :)
> Again, this is *only* the piece that attempts to convert loops
> to perfect nests.
> This is in fact, not terribly surprising, since the algorithm used was the
> result of
> Sebastian and I sitting at my whiteboa
On 17 Apr 2006 17:44:50 -0600, Tom Tromey <[EMAIL PROTECTED]> wrote:
> > "Mark" == Mark Mitchell <[EMAIL PROTECTED]> writes:
>
> Mark> In any case, the broader question is: to what extent should we have
> Mark> experimental options in releases, and how should we warn users of their
> Mark> expe
[apologies that this will come out threaded slightly wrong, none of my
handy mail clients feel like letting edit the references and in-reply-to
header, apparently it's not cool anymore]
> Dale Johannesen wrote:
>
> > I wasn't aware that it was supposed to be experimental either, and it
> > wasn't
This has been very enlightening information.
Is it documented anywhere which gcc features should not be trusted or
are known to have faults?
Regards,
Ivan
Richard Guenther wrote:
On 4/18/06, Ivan Novick <[EMAIL PROTECTED]> wrote:
I am a gcc user at a fininancial institution and IMHO it wou
> "Mark" == Mark Mitchell <[EMAIL PROTECTED]> writes:
Mark> In any case, the broader question is: to what extent should we have
Mark> experimental options in releases, and how should we warn users of their
Mark> experimental nature?
Why not put this into the option name? Something like '-Xop
On Mon, Apr 17, 2006 at 02:53:37PM -0700, Dale Johannesen wrote:
> >So from my point of view, the situation with -ftree-loop-linear is
> >fine - it's ICEing after all, not producing silently wrong-code. For
> >experimental options (where
> >I would include all options not enabled by -O[123s]) know
On Apr 17, 2006, at 2:53 PM, Dale Johannesen wrote:
I'd go further: you should not be trusting a compiler (gcc or any
other) to be correct in "mission critical" situations.
Or, to use the option that spits out the proof that the
transformation of the code that the compiler did was indeed va
On Apr 17, 2006, at 2:31 PM, Richard Guenther wrote:
On 4/18/06, Ivan Novick <[EMAIL PROTECTED]> wrote:
I am a gcc user at a fininancial institution and IMHO it would not
be a
good idea to have non-production ready functionality in gcc. We are
trying to use gcc for mission critical function
On 4/18/06, Ivan Novick <[EMAIL PROTECTED]> wrote:
> I am a gcc user at a fininancial institution and IMHO it would not be a
> good idea to have non-production ready functionality in gcc. We are
> trying to use gcc for mission critical functionality.
It has been always the case that additional op
I am a gcc user at a fininancial institution and IMHO it would not be a
good idea to have non-production ready functionality in gcc. We are
trying to use gcc for mission critical functionality.
Hope this helps,
Ivan
Mark Mitchell wrote:
Dan Berlin and I exchanged some email about PR 26435, w
On Mon, Apr 17, 2006 at 11:52:26AM -0700, Mark Mitchell wrote:
> My suggestion is that features that are clearly experimental (like this
> one) should be (a) documented as such, and (b) should generate a
> warning, like:
>
> warning: -ftree-loop-linear is an experimental feature and is not
> rec
> Mark Mitchell writes:
Mark> My understanding is we might be able to remove just the
Mark> problematic part (or segregate that into a separate option) -- but that
Mark> problematic part is the 177.swim bit, so that's an issue.
Well, yes and no. The 177.swim bit is loop interchange a
Dale Johannesen wrote:
> I wasn't aware that it was supposed to be experimental either, and it
> wasn't explained that way when it went in (Sep 2004). (Incomplete or
> buggy would not be surprising, but it sounds now like we're talking
> about fatally flawed design, which is different.)
My under
On Apr 17, 2006, at 11:52 AM, Mark Mitchell wrote:
Dan Berlin and I exchanged some email about PR 26435, which concerns a
bug in -ftree-loop-linear, and we now think it would make sense to
have
a broader discussion.
The PR in question is about an ice-on-valid regression in 4.1, when
using -O1
David Edelsohn wrote:
> -ftree-loop-linear enables a number of features and
> transformations. Which part, exactly, is experimental? You are quoting
> from the documentation for the option, but Dan may be referring to a
> particular transformation. I thought the failure and algorithm
> cor
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mark Mitchell wrote:
> Thoughts?
>
I don't know which of the loop linear transformations you folks were
debating (the loop linear stuff defines a family of transformations),
but I vote for having no experimental features in releases.
I
-ftree-loop-linear enables a number of features and
transformations. Which part, exactly, is experimental? You are quoting
from the documentation for the option, but Dan may be referring to a
particular transformation. I thought the failure and algorithm
correctness was related to creati
Dan Berlin and I exchanged some email about PR 26435, which concerns a
bug in -ftree-loop-linear, and we now think it would make sense to have
a broader discussion.
The PR in question is about an ice-on-valid regression in 4.1, when
using -O1 -ftree-loop-linear. Dan notes that this optimization o
32 matches
Mail list logo
