This is an archive of the discontinued LLVM Phabricator instance.

[Flang] Add flag dependent code to execute the loop-body atleast once
ClosedPublic

Authored by kiranchandramohan on Jun 6 2022, 10:05 AM.

Details

Summary

Given the flag --always-execute-loop-body the compiler emits code
to execute the body of the loop atleast once.

Note: This is part of upstreaming from the fir-dev branch of
https://github.com/flang-compiler/f18-llvm-project.

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: Valentin Clement <clementval@gmail.com>
Co-authored-by: Sameeran Joshi <sameeranjayant.joshi@amd.com>

Diff Detail

Event Timeline

Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptJun 6 2022, 10:05 AM
Herald added a subscriber: mehdi_amini. · View Herald Transcript
kiranchandramohan requested review of this revision.Jun 6 2022, 10:05 AM
kiranchandramohan edited the summary of this revision. (Show Details)Jun 6 2022, 10:06 AM
awarzynski added inline comments.Jun 6 2022, 10:48 AM
flang/test/Lower/always-execute-loop-body.f90
1

Would you mind testing with flang-new as well?

LGTM. (The bots are complaining.)

Run clang-format.

flang/test/Lower/always-execute-loop-body.f90
1

This is one of the cl::opt options that is present in files in Lower directory. Do we support such flags currently in the Driver?
What is the right way to share the flag with the Driver?

../flang/lib/Lower/Bridge.cpp:static llvm::cl::opt<bool> dumpBeforeFir(
../flang/lib/Lower/Bridge.cpp:static llvm::cl::opt<bool> forceLoopToExecuteOnce(
../flang/lib/Lower/PFTBuilder.cpp:static llvm::cl::opt<bool> clDisableStructuredFir(
../flang/lib/Lower/PFTBuilder.cpp:static llvm::cl::opt<bool> nonRecursiveProcedures(
../flang/lib/Lower/Allocatable.cpp:static llvm::cl::opt<bool> useAllocateRuntime(
../flang/lib/Lower/Allocatable.cpp:static llvm::cl::opt<bool> useDescForMutableBox(
../flang/lib/Lower/Bridge.cpp.orig:static llvm::cl::opt<bool> dumpBeforeFir(
../flang/lib/Lower/IntrinsicCall.cpp:static llvm::cl::opt<bool> outlineAllIntrinsics(
../flang/lib/Lower/IntrinsicCall.cpp:llvm::cl::opt<MathRuntimeVersion> mathRuntimeVersion(
../flang/lib/Lower/ConvertExpr.cpp:static llvm::cl::opt<bool> generateArrayCoordinate(
../flang/lib/Lower/ConvertExpr.cpp:static llvm::cl::opt<unsigned> clInitialBufferSize(
awarzynski added inline comments.Jun 7 2022, 2:14 AM
flang/test/Lower/always-execute-loop-body.f90
1

flang-new -fc1 supports -mmlir:

bin/flang-new -fc1 -mmlir --help | grep -E "always-execute-loop-body"
  --always-execute-loop-body                         - force the body of a loop to execute at least once

So, flang-new -fc1 -mmlir --always-execute-loop-body --emit-fir %s -o - should work ™ .

Test with the flang driver as well using suggesting by @awarzynski.

flang/test/Lower/always-execute-loop-body.f90
1

Thanks @awarzynski. That worked.

I was kind of thinking that -mmlir is only for the MLIR passes/transformations. Technically this is still in the frontend (lowering from parse-tree to MLIR).

awarzynski accepted this revision.Jun 7 2022, 2:43 AM

LGTM, thanks!

flang/test/Lower/always-execute-loop-body.f90
1

I was kind of thinking that -mmlir is only for the MLIR passes/transformations. Technically this is still in the frontend (lowering from parse-tree to MLIR).

That would be my intuition/expectations as well, but we haven't really defined where these options belong.

One of the main problems with llvm::cl is that it relies on there being global variables corresponding to various options. And since "global", these options are visible no matter what, i.e. it is tricky to separate LLVM options from MLIR and Flang from MLIR. In MLIR, they use registerMLIRContextCLOptions. We could look into something similar in Flang (in fact, we probably should). But for the time being, Flang options are bundled with MLIR options :)

As for flang-new, everything that's hidden behind -mllvm and -mmlir are internal compiler features/flags that are not intended for end users. So at least we are not exposing our users to this confusion.

This revision is now accepted and ready to land.Jun 7 2022, 2:43 AM