[LLVMdev] Latency of true depency of store followed by aliased load in ScheduleDAGInstrs

[Andrew Trick]

On Jun 12, 2012, at 7:20 AM, Jordy Potman <jordy.potman at recoresystems.com> wrote:
> 
> So in the volatile case the latency of the chain dependency is 0, while
> in the non volatile case it is 1.
> 
> I am using ScheduleDAGInstrs in a scheduler for a VLIW target and in the
> volatile case the load gets incorrectly scheduled in the same cycle as
> the store. Is ScheduleDAGInstrs incorrect in the volatile case or
> shouldn't I rely on the latency being non zero for getting a correct
> schedule?

I don't like the inconsistency. There's no reason for it other than sloppy implementation. I tried to clean this up in r158380. Memory dependence latency should now be conservative in this respect.

That said, this was really meant to be a heuristic, and a fairly unimportant one at that, so I never paid much attention to the inconsistency. Whether memory dependencies can be bundled in the same group is cpu specific. Register anti-dependencies are also zero cycle. Do you bundle those in the same group? What about register output dependencies? They can result from dead register defs. You may need to add your own checks to determine valid instruction groups. For example, you may not want to allow any DAG dependencies at all within the group. If the basic ScheduleHazardRecognizer is insufficient, you could try the approach that the Hexagon target uses. One of the engineers who works on that backend should be able to explain it better.

-Andy