llvm dev - Aug 2018 - machine scheduler: pre-RA bidirectional scheduling

Hi,

I would like to get some feedback about the current status of the pre-RA 
machine scheduler bidirectional scheduling.

I have tried enabling this on SystemZ, and found that it slightly 
increases spilling generally (in one benchmark with as much as 5%). 
Benchmarking do not indicate that bidirectional would be a win, either. 
Is this within the expected, or does it indicate something in the 
backend that could be fixed?

Theoretically, it should be better since it enables pre-RA resource 
balancing and the second latency heuristic, right? It should also be 
better to take from two sides the best candidate, instead of just from 
one side, exposing the heuristics to more nodes and finding more good 
candidates.

AArch, AMDGPU and PowerPC seem to be the only ones enabling 
bidirectional scheduling, which indicates that bottom-up is still the norm.

So, I then would like to ask what is the general advice on when to 
enable it? What were the original intentions behind this? Any particular 
type of target that would benefit from this?

Thanks for any advice and explanation,

Jonas

On 07/31/2018 08:19 AM, Jonas Paulsson via llvm-dev
wrote:
> Hi,
>
> I would like to get some feedback about the current status of the
> pre-RA machine scheduler bidirectional scheduling.
>
> I have tried enabling this on SystemZ, and found that it slightly
> increases spilling generally (in one benchmark with as much as 5%).
> Benchmarking do not indicate that bidirectional would be a win,
> either. Is this within the expected, or does it indicate something in
> the backend that could be fixed?
>
> Theoretically, it should be better since it enables pre-RA resource
> balancing and the second latency heuristic, right? It should also be
> better to take from two sides the best candidate, instead of just from
> one side, exposing the heuristics to more nodes and finding more good
> candidates.
>
> AArch, AMDGPU and PowerPC seem to be the only ones enabling
> bidirectional scheduling, which indicates that bottom-up is still the
> norm.
For PowerPC, bidirectional scheduling was a net win from benchmarking,
and we use post-RA scheduling with aggressive anti-dependency breaking
for the same reason.

 -Hal
>
> So, I then would like to ask what is the general advice on when to
> enable it? What were the original intentions behind this? Any
> particular type of target that would benefit from this?
>
> Thanks for any advice and explanation,
>
> Jonas
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

Hi,


On 2018-07-31 18:26, Hal Finkel wrote:
> On 07/31/2018 08:19 AM, Jonas Paulsson via llvm-dev wrote:
>> Hi,
>>
>> I would like to get some feedback about the current status of the
>> pre-RA machine scheduler bidirectional scheduling.
>>
>> I have tried enabling this on SystemZ, and found that it slightly
>> increases spilling generally (in one benchmark with as much as 5%).
>> Benchmarking do not indicate that bidirectional would be a win,
>> either. Is this within the expected, or does it indicate something in
>> the backend that could be fixed?
>>
>> Theoretically, it should be better since it enables pre-RA resource
>> balancing and the second latency heuristic, right? It should also be to
>> better to take from two sides the best candidate, instead of just from
>> one side, exposing the heuristics to more nodes and finding more good
>> candidates.
>>
>> AArch, AMDGPU and PowerPC seem to be the only ones enabling
>> bidirectional scheduling, which indicates that bottom-up is still the
>> norm.
> For PowerPC, bidirectional scheduling was a net win from benchmarking,
> and we use post-RA scheduling with aggressive anti-dependency breaking
> for the same reason.
Thanks for the reply, Hal! It seems like PowerPC is using the pre-RA 
machine-scheduler, while
using the PostRASchedulerList with aggressive anti-dependency breaking. 
I wonder then if there
is any reason in particular not to run the anti-dep breaker post-RA if 
using the post-RA machine
scheduler instead (is the idea that it might not be needed if pre-ra 
machine-sched is enabled,
while PPC in particular still benefits from it)?

I suppose that if benchmarks do not benefit from bidirectional pre-RA 
scheduling on SystemZ,
there isn't any principal argument at the moment to enable it?

/Jonas
>   -Hal
>
>> So, I then would like to ask what is the general advice on when to
>> enable it? What were the original intentions behind this? Any
>> particular type of target that would benefit from this?
>>
>> Thanks for any advice and explanation,
>>
>> Jonas
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev