This is an archive of the discontinued LLVM Phabricator instance.

[fir] Add affine promotion pass
ClosedPublic

Authored by clementval on Oct 5 2021, 7:35 AM.

Details

Summary

Convert fir operations which satisfy affine constraints to the affine
dialect.

This patch is part of the upstreaming effort from fir-dev branch.

Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Rajan Walia <walrajan@gmail.com>
Co-authored-by: Sourabh Singh Tomar <SourabhSingh.Tomar@amd.com>

Diff Detail

Event Timeline

clementval created this revision.Oct 5 2021, 7:35 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 5 2021, 7:35 AM
clementval requested review of this revision.Oct 5 2021, 7:35 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 5 2021, 7:35 AM

Could you add a test for affine.if? How about some negative tests - not mission critical, just nice-to-have.

Could you add a test for affine.if? How about some negative tests - not mission critical, just nice-to-have.

I'm not sure what you have in mind for negative test in a transformation?

Could you add a test for affine.if? How about some negative tests - not mission critical, just nice-to-have.

I'm not sure what you have in mind for negative test in a transformation?

E.g. a test with a fir.do_loop that should not be transformed and indeed isn't.

Could you add a test for affine.if? How about some negative tests - not mission critical, just nice-to-have.

I'm not sure what you have in mind for negative test in a transformation?

E.g. a test with a fir.do_loop that should not be transformed and indeed isn't.

Ok. Yeah I can add some.

awarzynski added inline comments.Oct 7 2021, 7:36 AM
flang/test/Fir/affine-promotion.fir
2

This comment suggests that tests for fir.if and fir.load should go to a dedicated file.

94

Would a test with fir.if _outside of_ fir.do_loop be possible? I think that it would nicely highlight _what_ is being tested. Currently both versions of @calc look like tests for fir.do_loop specifically (that's the first thing that you notice). fir.if/affine.if` or fir.load/affine.store are not obvious to spot.

clementval added inline comments.Oct 7 2021, 8:49 AM
flang/test/Fir/affine-promotion.fir
2

I'll update the comment so both tests can be in the same file.

94

a fir.if outside of loop would never produce affine operations. affine.if has meaning in a loop only.

schweitz accepted this revision.Oct 7 2021, 1:04 PM
This revision is now accepted and ready to land.Oct 7 2021, 1:04 PM
awarzynski accepted this revision.Oct 8 2021, 12:06 AM

LGTM. Thanks for adding the tests!

flang/test/Fir/affine-promotion.fir
9

[nit] Could you rename calc as loop_with_load_and_store or something similar? So that it is clear which case is being tested?

82

[nit] Could you rename calc as loop_with_if or something similar? So that it is clear which case is being tested?

94

Ah, indeed:

The affine.if operation restricts execution to a subset of the loop iteration space defined by an integer set (a conjunction of affine constraints).

From : https://mlir.llvm.org/docs/Dialects/Affine/#affineif-mliraffineifop. I missed that, thanks!

clementval updated this revision to Diff 378130.Oct 8 2021, 1:57 AM
clementval marked 5 inline comments as done.

Address nit comment

This revision was automatically updated to reflect the committed changes.
jdoerfert reopened this revision.Oct 9 2021, 11:33 AM

Again, glancing at these transformations makes me doubt how well they are tested. The documentation doesn't seem to indicate this is a WIP or not ready yet.
I only read over parts and found 3 things that I suspect are "broken", for some definition of the word. (The multi symbol stuff is technically not a correctness issue.)

I'm also guessing we ignore overflows and such completely when we do these things, right?

flang/lib/Optimizer/Transforms/AffinePromotion.cpp
204

This way of translating to "affine" should break as soon as lhs or rhs is an induction variable and the other one is not a constant.
Same for other binary operations. I didn't see a test for this but I would hope something in affine will complain.

215

This assumes perfectly nested loops, right? Is this checked?
I doubt the symCount stuff works if a symbol is used multiple times.

This revision is now accepted and ready to land.Oct 9 2021, 11:33 AM

Again, glancing at these transformations makes me doubt how well they are tested. The documentation doesn't seem to indicate this is a WIP or not ready yet.
I only read over parts and found 3 things that I suspect are "broken", for some definition of the word. (The multi symbol stuff is technically not a correctness issue.)

I'm also guessing we ignore overflows and such completely when we do these things, right?

As for the patch related to affine promotion/demotion these are prototype. I would be happy to add a mention in the comment about that. Alternatively, we can also not upstream these transformations.

Comment added with patch D111629

clementval closed this revision.Oct 12 2021, 4:00 AM