[PATCH] D14351: [Refactor] Replace RegionPasses by FunctionPasses

[Tobias Grosser via llvm-commits]

grosser added a comment.

As I already mentioned in discussions on the mailing list, I am concerned about moving to function passes, as building up all scops ahead of time then code generating the first may invalidate later scops. We had this problem maybe two years ago, which is why we moved away from this first-build-all-then-codegen-all model. I could see us using a different approach then what we do today, but I think there are various possible approaches that we should consider:

1. Model All - Then build all, but leave pass structure as today (this patch)
2. Have a single function pass that iteratively schedules scop detection / scop modeling / code generation just using library calls to implement this functionality
3. Keep the pass structure, but use on-demand scop modeling and caching similar to how the new pass manager caches objects.

It is not yet clear to me which approach is the best and I assume that the new pass manger will affect the decisions we take. Hence I suggest two things:

1. Most of the changes in ScopInfo go very much in a direction that will be useful for all of these approaches. What we want is to have a class that constructs a scop for a region and returns a scop object that is not connected with the ScopInfo pass. I suggest to introduce such a class to ensure that most of these changes do not bitrot and to reduce the diff needed to play around with these solutions.

2. I suggest to look into the new pass manager infrastructure and use this as a testbed to experiment with these different solutions. This should give us both necessary knowledge about the new pass manager as well as confidence on the stability of the different approaches without breaking the current behavior.


http://reviews.llvm.org/D14351