[llvm-dev] machine scheduler: pre-RA bidirectional scheduling

[Jonas Paulsson via llvm-dev]

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