Add support for representing array constants of any rank with MLIR
dense attribute. This greatly improves compile time and memory
usage of programs with large array constants. We still support only
arrays of a few basic types, such as integer, real and logic.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Thanks for working on this. Did you check with the example given by @jeanPerier in the issue? What kind of build time to you see?
Yes, I ended up commenting more about this in the issue. With @jeanPerier's example, I get the following build time:
$ time flang -c ftest_reduced.f90 real 0m1.059s user 0m0.962s sys 0m0.096s
This is on an ARMv8.2 Ampere Altra Mt. Jade machine.
(In the command above, flang is actually an alias to /home/leandro.lupori/git/flang-i60376/buildr/bin/flang-new)
It might to be good to add a test with the codegen to make sure we have what we expect at the LLVM IR level.
Thank you very much for improving this limitation!
flang/lib/Lower/ConvertConstant.cpp | ||
---|---|---|
560 | I know I initially suggested the TODO, but after discussions, it would be too harsh to artificially limit the size of a program that can be compile. Some people with more RAM and time may just be OK with bigger compile time here to be able to test/use flang without modifying their programs. The ideal would be to add a driver switch to control the size limit and to tell the user to use that switch to increase the limit in the TODO message that would warn this may lead to very long compile time. Since threading a switch here may not be straightforward, I am also OK with just removing the TODO for now so that flang can be tested with no limit and to leave your comment with the addition that it would be nice to add a switch to control an array size after which flang should not continue to compile. Besides, after your patch it should be a lot less common to hit the compilation time/memory issue (most big array constant expressions will use integer and reals out there). |
flang/lib/Lower/ConvertConstant.cpp | ||
---|---|---|
560 | Ok, since big array constants of types other than integer and real shouldn't be common, for now I'll just remove the TODO and leave a comment. |
Remove TODO and suggest the addition of a switch to control the maximum array size supported.
I know I initially suggested the TODO, but after discussions, it would be too harsh to artificially limit the size of a program that can be compile. Some people with more RAM and time may just be OK with bigger compile time here to be able to test/use flang without modifying their programs.
The ideal would be to add a driver switch to control the size limit and to tell the user to use that switch to increase the limit in the TODO message that would warn this may lead to very long compile time.
Since threading a switch here may not be straightforward, I am also OK with just removing the TODO for now so that flang can be tested with no limit and to leave your comment with the addition that it would be nice to add a switch to control an array size after which flang should not continue to compile.
Besides, after your patch it should be a lot less common to hit the compilation time/memory issue (most big array constant expressions will use integer and reals out there).