[LLVMdev] Artificial deps and stores
atrick at apple.com
Fri Jan 17 16:36:27 PST 2014
On Jan 17, 2014, at 4:16 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote:
> On Jan 17, 2014, at 4:03 PM, Andrew Trick <atrick at apple.com> wrote:
>> On Jan 17, 2014, at 3:54 PM, Hal Finkel <hfinkel at anl.gov> wrote:
>>> Andy, et al.,
>>> In ScheduleDAGInstrs::buildSchedGraph, the code for handling stores has this:
>>> if (!ExitSU.isPred(SU))
>>> // Push store's up a bit to avoid them getting in between cmp
>>> // and branches.
>>> ExitSU.addPred(SDep(SU, SDep::Artificial));
>>> This code does not seem to be in any way specific to compares; and in any case, at least on the PPC A2, scheduling stores in between the compare and the branch would not be a bad thing (because the core is in order, and the compare has a 2-cycle latency, so if there is nothing else to do, a store would not be a bad thing to put there).
>>> Can you explain the motivation for this (why or for what it is bad), and what else it might do (aside from the commented cmp/branch pairing)? I'm wondering if we should make this target dependent.
>> I don’t agree with the existing comment. It’s possible that somewhere, maybe in target specific code, we make use of the extra store->exit edge, but I can’t remember any reason for it now.
> Do you have another mechanism for encouraging macro fusion?
The MI scheduler does it now via a proper mechanism. However, for targets that haven’t switched over it could be a minor, temporary issue (the old mechanism shown above didn’t work well anyway).
For the time being it is probably best to leave it under a target option with a FIXME to avoid perturbing non-PPC/x86 targets.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev