llvm dev - Oct 2013 - [LLVMdev] Enabling MI Scheduler on x86 (was Experimental Evaluation of the Schedulers in LLVM 3.3)

On Sep 25, 2013, at 11:24 PM, Andrew Trick <atrick at apple.com> wrote:
> 
> On Sep 23, 2013, at 11:36 PM, Chandler Carruth <chandlerc at
google.com> wrote:
> 
>> 
>> On Tue, Sep 24, 2013 at 1:11 AM, Andrew Trick <atrick at
apple.com> wrote:
>> This week, I'll see if we can enable MI scheduling by default for
x86. I'm not sure which flags you're using to test it now. But by making
it default and enabling the corresponding coalescer changes, we can be confident
that benchmarking efforts are improving on the same baseline.
>> 
>> While I'm generally really excited by this, I would ask for a bit
more staging of this change.
>> 
>> Specifically, I would really like for a single, clear switch to enable
exactly what you want benchmark data on *before* it becomes the default, and to
give various folks time to run benchmarks and report serious regressions.
>> 
>> I don't want our ability to ship LLVM from top-of-tree to be
seriously impaired by this, and enabling a feature that can have dramatic
performance impact without a giving folks a really simple way to try it out and
a period of time to run benchmarks and collect data seems to do that. =/
>> 
>> Once it is the default, it would be really good to leave in the single,
simple switch for a period of time for folks to disable it if need be.
> 
> 
> I just added a flag: -misched-bench. You can use it to flip back and forth
between your target's default SD scheduler and the machine scheduler.
It's doesn't affect whether the postRA scheduler is also run.
If there are still no objections, I’ll plan to switch the x86 default to MI
scheduler on Monday.

-Andy

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131004/95cbf76a/attachment.html>

On 05.10.2013, at 08:01, Andrew Trick <atrick at apple.com> wrote:
> 
> On Sep 25, 2013, at 11:24 PM, Andrew Trick <atrick at apple.com>
wrote:
> 
>> 
>> On Sep 23, 2013, at 11:36 PM, Chandler Carruth <chandlerc at
google.com> wrote:
>> 
>>> 
>>> On Tue, Sep 24, 2013 at 1:11 AM, Andrew Trick <atrick at
apple.com> wrote:
>>> This week, I'll see if we can enable MI scheduling by default
for x86. I'm not sure which flags you're using to test it now. But by
making it default and enabling the corresponding coalescer changes, we can be
confident that benchmarking efforts are improving on the same baseline.
>>> 
>>> While I'm generally really excited by this, I would ask for a
bit more staging of this change.
>>> 
>>> Specifically, I would really like for a single, clear switch to
enable exactly what you want benchmark data on *before* it becomes the default,
and to give various folks time to run benchmarks and report serious regressions.
>>> 
>>> I don't want our ability to ship LLVM from top-of-tree to be
seriously impaired by this, and enabling a feature that can have dramatic
performance impact without a giving folks a really simple way to try it out and
a period of time to run benchmarks and collect data seems to do that. =/
>>> 
>>> Once it is the default, it would be really good to leave in the
single, simple switch for a period of time for folks to disable it if need be.
>> 
>> I just added a flag: -misched-bench. You can use it to flip back and
forth between your target's default SD scheduler and the machine scheduler.
It's doesn't affect whether the postRA scheduler is also run.
> 
> If there are still no objections, I’ll plan to switch the x86 default to MI
scheduler on Monday.
What happened to this plan?

- Ben

On Oct 8, 2013, at 2:05 PM, Benjamin Kramer <benny.kra at gmail.com>
wrote:
> On 05.10.2013, at 08:01, Andrew Trick <atrick at apple.com> wrote:
> 
>> 
>> On Sep 25, 2013, at 11:24 PM, Andrew Trick <atrick at apple.com>
wrote:
>> 
>>> 
>>> On Sep 23, 2013, at 11:36 PM, Chandler Carruth <chandlerc at
google.com> wrote:
>>> 
>>>> 
>>>> On Tue, Sep 24, 2013 at 1:11 AM, Andrew Trick <atrick at
apple.com> wrote:
>>>> This week, I'll see if we can enable MI scheduling by
default for x86. I'm not sure which flags you're using to test it now.
But by making it default and enabling the corresponding coalescer changes, we
can be confident that benchmarking efforts are improving on the same baseline.
>>>> 
>>>> While I'm generally really excited by this, I would ask for
a bit more staging of this change.
>>>> 
>>>> Specifically, I would really like for a single, clear switch to
enable exactly what you want benchmark data on *before* it becomes the default,
and to give various folks time to run benchmarks and report serious regressions.
>>>> 
>>>> I don't want our ability to ship LLVM from top-of-tree to
be seriously impaired by this, and enabling a feature that can have dramatic
performance impact without a giving folks a really simple way to try it out and
a period of time to run benchmarks and collect data seems to do that. =/
>>>> 
>>>> Once it is the default, it would be really good to leave in the
single, simple switch for a period of time for folks to disable it if need be.
>>> 
>>> I just added a flag: -misched-bench. You can use it to flip back
and forth between your target's default SD scheduler and the machine
scheduler. It's doesn't affect whether the postRA scheduler is also run.
>> 
>> If there are still no objections, I’ll plan to switch the x86 default
to MI scheduler on Monday.
> 
> What happened to this plan?
Distractions. I need to clean up some unit tests first. Otherwise I could flip
the switch now.
-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131008/66740e9f/attachment.html>

On Oct 8, 2013, at 2:05 PM, Benjamin Kramer <benny.kra at gmail.com>
wrote:
> On 05.10.2013, at 08:01, Andrew Trick <atrick at apple.com> wrote:
> 
>> 
>> On Sep 25, 2013, at 11:24 PM, Andrew Trick <atrick at apple.com>
wrote:
>> 
>>> 
>>> On Sep 23, 2013, at 11:36 PM, Chandler Carruth <chandlerc at
google.com> wrote:
>>> 
>>>> 
>>>> On Tue, Sep 24, 2013 at 1:11 AM, Andrew Trick <atrick at
apple.com> wrote:
>>>> This week, I'll see if we can enable MI scheduling by
default for x86. I'm not sure which flags you're using to test it now.
But by making it default and enabling the corresponding coalescer changes, we
can be confident that benchmarking efforts are improving on the same baseline.
>>>> 
>>>> While I'm generally really excited by this, I would ask for
a bit more staging of this change.
>>>> 
>>>> Specifically, I would really like for a single, clear switch to
enable exactly what you want benchmark data on *before* it becomes the default,
and to give various folks time to run benchmarks and report serious regressions.
>>>> 
>>>> I don't want our ability to ship LLVM from top-of-tree to
be seriously impaired by this, and enabling a feature that can have dramatic
performance impact without a giving folks a really simple way to try it out and
a period of time to run benchmarks and collect data seems to do that. =/
>>>> 
>>>> Once it is the default, it would be really good to leave in the
single, simple switch for a period of time for folks to disable it if need be.
>>> 
>>> I just added a flag: -misched-bench. You can use it to flip back
and forth between your target's default SD scheduler and the machine
scheduler. It's doesn't affect whether the postRA scheduler is also run.
>> 
>> If there are still no objections, I’ll plan to switch the x86 default
to MI scheduler on Monday.
> 
> What happened to this plan?
I decided to look at x86 benchmarks one more time before flipping the switch,
this time with corei7-avx and vectorize-slp.

I noticed very bad things happening in a couple of the benchmarks. As usual,
it's only the result of unlucky register assignment, not
instruction scheduling. But the impact was large enough that I decided to fix it
first in the interest of avoiding triaging scheduling performance bugs. There
will be plenty to deal with already.

I just got the AVX dependence breaking checkin in yesterday, so was able to flip
the switch today: r192750.

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131015/d37a0816/attachment.html>