This is an archive of the discontinued LLVM Phabricator instance.

[flang] Propagate lowering options from driver.
ClosedPublic

Authored by vzakhari on Jul 20 2022, 2:23 PM.

Details

Summary

This commit addresses concerns raised in D129497.

Propagate lowering options from driver to expressions lowering
via AbstractConverter instance. A single use case so far is
using optimized TRANSPOSE lowering with O1/O2/O3.

bbc does not support optimization level switches, so it uses
default LoweringOptions (e.g. optimized TRANSPOSE lowering
is enabled by default, but an engineering -opt-transpose=false
option can still override this).

Diff Detail

Event Timeline

vzakhari created this revision.Jul 20 2022, 2:23 PM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptJul 20 2022, 2:23 PM
Herald added a subscriber: mehdi_amini. · View Herald Transcript
vzakhari requested review of this revision.Jul 20 2022, 2:23 PM
vzakhari edited the summary of this revision. (Show Details)Jul 20 2022, 2:24 PM
clementval added inline comments.Jul 21 2022, 12:08 AM
flang/include/flang/Lower/Bridge.h
17

Wouldn't it make more sense to have the lowering options defined in flang/Lower and the frontend makes use of it instead of the Bridge depending on the frontend?

clang has a leaf library Basic. Both options sound strange. Shouldn't the driver invoke the compiler and thus depend on the compiler?

Great to see this, thank you!

I also simplified transpose_opt.f90 checks to focus on important things.

Thanks! Please move that to a separate PR.

flang/include/flang/Frontend/CompilerInvocation.h
73

[nit] loweringOpts for consistency with other members. But based on my other comments, you might be removing this.

flang/include/flang/Lower/Bridge.h
17

That would be my suggestion as well.

@vzakhari, I'm guessing that you've simply followed what we did for other sets of driver options, e.g. CodeGen. Note that none of those are re-used by other parts of the frontend. In contrast, "LoweringOptions.h" contains options that are low level details of the lowering API, i.e. optimizeTranspose is a lowering option that currently is not available in the driver (instead, the driver operates in terms of -O{n}). Does it make sense?

In the case of e.g. semantics we took a different approach, i.e. the driver configures the frontend via setSemanticsOpts. More specifically:

  • relevant options are defined in the semantics API,
  • the driver configures the semantics through the semantics API.

Sounds like that would more suitable here as well.

flang/lib/Frontend/CompilerInvocation.cpp
614

I don't see anything that could fail here, so I would just make this hook return void (like parseTargetArgs).

660–662

That's not the approach that you want to take here, but close :)

Basically, CompilerInvocation::createFromArgs collects command line arguments, parses them and configures the current CompilerInvocation accordingly. In this case, the compiler invocation flag that's relevant here is e.g. -O1 and that's captured in parseCodeGenArgs. This method doesn't parse any new command line arguments.

Instead, I would add something like CompilerInvocation::setSemanticsOpts and call it in e.g. ExecuteAction. CompilerInstance encapsulates the state of the current "compiler instance" (i.e. libraries that implement Flang, including lowering). And setLoweringOptions configures the lowering API, which the driver views as an element of a CompilerInstance.

flang/lib/Lower/ConvertExpr.cpp
100

Unrelated change

clang has a leaf library Basic. Both options sound strange. Shouldn't the driver invoke the compiler and thus depend on the compiler?

I agree that we are getting to a point where something similar would be desirable. We just need a volunteer to design and to implement it ;-)

vzakhari added inline comments.Jul 21 2022, 2:53 PM
flang/include/flang/Lower/Bridge.h
17

Makes sense!

17

I was making this change anticipating that some arguments parsing will be required soon. E.g. either transpose specific option or some more general option like "optimized-lowering" may override the opt-level setting, if present: if no option present optimized transpose will be enabled only with >O0, and otherwise the option will control the optimized lowering. But I also tried to keep the change minimal just to address the follow-ups mentioned in D129497.

With this context, does it make sense to keep it as is?

57

FWIW, I think I may avoid having LoweringOptions stored in the lowering bridge instance (though, it seems natural to me) and pass them to lower method as an argument so that the options are propagated to the instance of FirConverter.

flang/lib/Frontend/CompilerInvocation.cpp
614

Fixed.

flang/lib/Lower/ConvertExpr.cpp
100

Fixed.

vzakhari updated this revision to Diff 446646.Jul 21 2022, 3:04 PM
clementval added inline comments.Jul 22 2022, 12:04 AM
flang/include/flang/Lower/LoweringOptions.h
19
35
flang/lib/Frontend/CompilerInvocation.cpp
609
flang/lib/Lower/Bridge.cpp
3248
flang/tools/bbc/bbc.cpp
221
vzakhari added inline comments.Jul 22 2022, 8:39 AM
flang/include/flang/Lower/LoweringOptions.h
19

Missed that. Thanks! Will fix it here and other places.

vzakhari updated this revision to Diff 446851.Jul 22 2022, 8:39 AM
vzakhari marked 9 inline comments as done and an inline comment as not done.Aug 3 2022, 1:11 PM
vzakhari added inline comments.
flang/include/flang/Lower/Bridge.h
17

Hi @awarzynski, does it make sense to keep the changes as-is given that we may need to add parsing for lowering controlling options in future?

This mostly looks good, but I would still prefer the invocation to setLoweringOptions be moved from CompilerInvocation to CompilerInstance (see my comment in CompilerInvocation.cpp). It just feels like a more suitable place. WDYT?

flang/include/flang/Lower/Bridge.h
17

Future-proofing like this makes sense to me. And even if we discover that this is not the best place for these options, we can always move them at some later time.

vzakhari marked an inline comment as not done.Aug 4 2022, 12:57 PM

This mostly looks good, but I would still prefer the invocation to setLoweringOptions be moved from CompilerInvocation to CompilerInstance (see my comment in CompilerInvocation.cpp). It just feels like a more suitable place. WDYT?

Okay, it makes sense at this stage. I will upload updated files shortly. Thank you for the review!

vzakhari updated this revision to Diff 450110.Aug 4 2022, 12:58 PM
vzakhari edited the summary of this revision. (Show Details)
vzakhari updated this revision to Diff 450164.Aug 4 2022, 4:01 PM

clang-format

awarzynski accepted this revision.Aug 5 2022, 6:03 AM

LGTM, many thanks for implementing this :)

This revision is now accepted and ready to land.Aug 5 2022, 6:03 AM
This revision was automatically updated to reflect the committed changes.