Implements a Loop Fusion Transformation

[kaushikcfd]

Loopy-flavored loop-fusion transformation corresponding to https://doi.org/10.1007/3-540-57659-2_18.

[inducer]

Suppose the CEESD version (see above) is the desired one, it's algorithmically wrong. If we presume the existence of a "fusable-with" relation, and if we also assume that that relation is transitive, then the correct thing to do upon discovering a non-fusable edge within the set of candidates would be to make two new sets of candidates. My understanding is that the net effect of the code there is to chuck the iname for which the conflict has been discovered out of the set and keep going, effectively (if done often enough) discarding one of the two candidate sets unnecessarily.

For specificity, this is the CEESD version I'm discussing.

[kaushikcfd]

Yes, there's no need for the "is_infusible_with" relation and I got rid of it. See inducer/arraycontext#217 for a correct usage of this transformation.

[majosm]

@kaushikcfd Just to make sure I follow: would you expect this recent change to have an effect on the issue we ran into in inducer/meshmode#453? (Short summary of the issue, as I understand it: if the base and quadrature discretizations have the same number of DOFs, the loop fusion code initially treats indices corresponding to both discretizations as candidates for fusion. Then it encounters an instruction that sums over both of them and arbitrarily decides to eliminate one, because they are nested. It hits the else of the first nested check here.) I tried integrating the changes, and it still seems to trigger that check (except it's an error now instead of a warning).

[kaushikcfd]

Hi Matt!

would you expect this recent change to have an effect on the issue

No I don't expect this change to have an issue on #453. I was just cleaning up the API here.

it's an error now instead of a warning

The idea of that check is that if loops can be potentially nested within each other they should not be fusion candidates. Additionally, in our array context we pick candidates such that they don't violate this criterion.

We are hitting either one of the 2 issues:

1. They cannot be nested within each other and the check in the loop fusion implementation is buggy, or,
2. we are passing incorrect candidates from the FusionArrayContext.

If there's an MWE I'll be happy to take a look.

[majosm]

Gotcha, thanks Kaushik! I think we are hitting issue 2 (so we'll just need to distinguish base and quadrature DOF axes).

[majosm]

FYI @kaushikcfd, while I was browsing through this code the other day trying to understand a warning that was being emitted (which turned into inducer/meshmode#453), I spotted a few opportunities to avoid recomputation and speed things up a fair amount in get_kennedy_unweighted_fusion_candidates. Specifically, the calls I noticed that were being repeated were _get_partial_loop_nest_tree_for_fusion, _get_ldg_nodes_from_loopy_insn, and (I think, need to revisit and confirm) get_insn_access_map. If I can find some time this week I'll finish my changes and push them for you take a look at.

[kaushikcfd]

@majosm: Thanks for the potential bottlenecks. I memoized those routines.