This is an archive of the discontinued LLVM Phabricator instance.

[flang] Remove non-constant folding for multiply
AbandonedPublic

Authored by shraiysh on May 30 2022, 6:03 AM.

Details

Summary

This folding is already done by the canonicalizer in mlir and there are
no dedicated tests for non-constant folding in flang. This has also not
been implemented for other binary operations like add, subtract and
divide - all of which are handled by the canonicalizer. Hence, removing
this change.

This does not affect constant folding and the semantic checks associated
with that.

Diff Detail

Event Timeline

shraiysh created this revision.May 30 2022, 6:03 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptMay 30 2022, 6:03 AM
shraiysh requested review of this revision.May 30 2022, 6:03 AM
klausler requested changes to this revision.May 30 2022, 8:55 AM

Why not add other missing simple rewrites rather than remove this one?

This revision now requires changes to proceed.May 30 2022, 8:55 AM
shraiysh added a comment.EditedMay 30 2022, 9:08 AM

Why not add other missing simple rewrites rather than remove this one?

This already being done by the fir-opt canonicalization. It would be code duplication (functionality wise). That's the main reason to remove this. The canonicalization in arith dialect handles many more cases than we already have. Unlike constant folding, this is not required by any of the semantic checks and so, pushing it later in the pipeline and relying on MLIR doesn't hurt.

A minor reason is that there is no proper way to test this for general usage. As we discussed on slack, there is a way to test this only in modules only when it is used in specification based initialization, but there is no general test for this and its hard to figure out how and where to write such a test.

Why not add other missing simple rewrites rather than remove this one?

This already being done by the fir-opt canonicalization. It would be code duplication (functionality wise). That's the main reason to remove this. The canonicalization in arith dialect handles many more cases than we already have. Unlike constant folding, this is not required by any of the semantic checks and so, pushing it later in the pipeline and relying on MLIR doesn't hurt.

A minor reason is that there is no proper way to test this for general usage. As we discussed on slack, there is a way to test this only in modules only when it is used in specification based initialization, but there is no general test for this and its hard to figure out how and where to write such a test.

There's some use cases for rewriting 0 * ... as 0 to avoid spurious diagnostics from semantics in the ... part; unlike C/C++, a Fortran compiler is allowed this rewrite even when there's function calls with potential side effects in the ... part. Also MERGE(t,f,x) when x is known.

shraiysh added a comment.EditedMay 31 2022, 1:36 AM

There's some use cases for rewriting 0 * ... as 0 to avoid spurious diagnostics from semantics in the ... part; unlike C/C++, a Fortran compiler is allowed this rewrite even when there's function calls with potential side effects in the ... part. Also MERGE(t,f,x) when x is known.

In that case, this should be done only for multiplication with zero (*0) in flang, right? Is it okay if we rely on mlir for the remaining simplifications, like +0, -0, /1, *1, etc.?

There's some use cases for rewriting 0 * ... as 0 to avoid spurious diagnostics from semantics in the ... part; unlike C/C++, a Fortran compiler is allowed this rewrite even when there's function calls with potential side effects in the ... part. Also MERGE(t,f,x) when x is known.

In that case, this should be done only for multiplication with zero (*0) in flang, right? Is it okay if we rely on mlir for the remaining simplifications, like +0, -0, /1, *1, etc.?

I suppose so, but I've found it to be a good idea to simplify and optimize programs as early as possible, in general. Do what you like, it's your tree.

klausler resigned from this revision.May 31 2022, 8:37 AM
This revision now requires review to proceed.May 31 2022, 8:37 AM
kiranchandramohan resigned from this revision.Nov 18 2022, 2:30 AM
clementval resigned from this revision.Jul 13 2023, 1:46 PM
shraiysh abandoned this revision.Jul 13 2023, 2:08 PM

Abandoning this.