On 02/05/12 14:13, nick clifton wrote:
> Hi Richard,
>
>> Well, given the replies from you, Ian and Vlad (when reviewing the patch),
>> I feel once again in a minority of one here :-) but... I just don't
>> think we should be advertising this sort of stuff to users.
>
> OK, what about Ian's sugge
Hi Richard,
Well, given the replies from you, Ian and Vlad (when reviewing the patch),
I feel once again in a minority of one here :-) but... I just don't
think we should be advertising this sort of stuff to users.
OK, what about Ian's suggestion of controlling the algorithm selection
via a -
On 2 May 2012 10:37, David Brown wrote:
> A second thing that would be hugely convenient for advanced users and
> testers (and people like me who just like to read manuals) would be a
> version number attached to each option, so that we can see which gcc
> versions support it. Some of us use multi
On 01/05/2012 20:11, Joern Rennecke wrote:
Quoting Richard Sandiford :
nick clifton writes:
OK, but what if it turns out that the new algorithm improves the
performance of some benchmarks/applications, but degrades others, within
the same architecture ? If that turns out to be the case (and I
Richard Sandiford writes:
> Well, given the replies from you, Ian and Vlad (when reviewing the patch),
> I feel once again in a minority of one here :-) but... I just don't
> think we should be advertising this sort of stuff to users. Not because
> I'm trying to be cliquey, but because any time
Quoting Richard Sandiford :
nick clifton writes:
OK, but what if it turns out that the new algorithm improves the
performance of some benchmarks/applications, but degrades others, within
the same architecture ? If that turns out to be the case (and I suspect
that it will) then having a docume
nick clifton writes:
>>> Also - why shouldn't it be a user-level option ? In my experience gcc's
>>> instruction scheduling tends to be very sensitive to the algorithm being
>>> compiled. For some applications it does a good job, but for others it
>>> actually makes the performance worth. Being
Hi Richard,
Also - why shouldn't it be a user-level option ? In my experience gcc's
instruction scheduling tends to be very sensitive to the algorithm being
compiled. For some applications it does a good job, but for others it
actually makes the performance worth. Being able to tune the behav
Richard Sandiford writes:
> nick clifton writes:
>> Hi Richard,
>>
I have just noticed that the new -fsched-pressure-algorithm= gcc
command line option is not documented in gcc/doc/invoke.texi. Was
this an oversight ?
>>>
>>> No, it was deliberate. It's not supposed to
nick clifton writes:
> Hi Richard,
>
>>>I have just noticed that the new -fsched-pressure-algorithm= gcc
>>>command line option is not documented in gcc/doc/invoke.texi. Was
>>>this an oversight ?
>>
>> No, it was deliberate. It's not supposed to be a user-level option.
>
> Then why
Hi Richard,
I have just noticed that the new -fsched-pressure-algorithm= gcc
command line option is not documented in gcc/doc/invoke.texi. Was
this an oversight ?
No, it was deliberate. It's not supposed to be a user-level option.
Then why is there a user-visible command line opti
Nick Clifton writes:
> I have just noticed that the new -fsched-pressure-algorithm= gcc
> command line option is not documented in gcc/doc/invoke.texi. Was
> this an oversight ?
No, it was deliberate. It's not supposed to be a user-level option.
Richard
Hi Richard,
I have just noticed that the new -fsched-pressure-algorithm= gcc
command line option is not documented in gcc/doc/invoke.texi. Was
this an oversight ?
Cheers
Nick
13 matches
Mail list logo
