[LLVMdev] Latency of true depency of store followed by aliased load in ScheduleDAGInstrs
Jordy Potman
jordy.potman at recoresystems.com
Thu Jun 14 08:20:53 PDT 2012
On Tue, 2012-06-12 at 19:45 -0700, Andrew Trick wrote:
> 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
Thanks for cleaning up the inconsistency. Register anti-dependencies can
be bundled in the same group on our target and we treat dead register
defs specially in our scheduler so I guess that is why we did not run
into issues before. I now understand that checking explicitly for
allowed/not-allowed DAG dependencies within a group is a more robust
approach, so we'll start doing that.
Thanks,
Jordy
More information about the llvm-dev
mailing list