[PATCH] Bugfix for missed dependency from store to load in buildSchedGraph().

[Andrew Trick]

> On Feb 10, 2015, at 6:54 AM, Jonas Paulsson <jonas.paulsson at ericsson.com> wrote:
> 
> Looking at the possibility of refactorization / redesign, I wonder what are the main strong
> points of this implementation right now, in your opinion? The mapping to underlying objects
> looks nice to me, but I am not sure I understand why to go through the trouble of clearing
> lists and using a set of RejectMemNodes with adjustChainDeps(). It is very complex code, and
> I wonder what is gained in the end here. Does anyone have any thoughts about it?  Is it to handle
> huge regions with tons of memory accesses well?

Since you’ve taken the time to understand the algorithm, and are actively benchmarking, it would be great to take advantage of the opportunity to rewrite. Feel free to modify even the core DAG builder implementation, which hasn’t really changed since inception--way before my time. The alias-aware scheduling has been around long enough that it makes sense to redesign the core DAG builder code around it, rather than bolt it on. I agree, in its current form, the AA-aware logic is too hard to follow.

Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150210/538f5cb7/attachment.html>