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
