-O* does more than what's in optLevelFlags?

[Simon Peyton Jones]

Is this a documentation bug, an implementation bug (as in, if any of the relevant opts are set, then the CoreToDos should always include the optimization steps selected), or a design bug (there is no way to support this meaningfully)?

Maybe a documentation bug?  You should update the `optLevel` field of `DynFlags` only via calling `setOptLevel`, not by setting it directly.

What other design would make sense?  We want to support ghc -O -fno-strictness, where the -O switches on a bunch of flags, and -fno-strictness turns off strictness.  The order matters.

One difficulty is that I'm not even sure where one would look for that documentation.  We don't really have a comprehensive GHC User Manual description of the GHC API: Section 7.2 "Using GHC as a library" is vestigial.  I would be Absolutely Fantastic, if someone (Gergo, even) felt able to flesh it out.

Simon

PS: I am leaving Microsoft at the end of November 2021, at which point simonpj at microsoft.com<mailto:simonpj at microsoft.com> will cease to work.  Use simon.peytonjones at gmail.com<mailto:simon.peytonjones at gmail.com> instead.  (For now, it just forwards to simonpj at microsoft.com.)

From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Erdi, Gergo via ghc-devs
Sent: 11 October 2021 08:54
To: 'GHC' <ghc-devs at haskell.org>
Cc: Montelatici, Raphael Laurent <Raphael.Montelatici at sc.com>
Subject: RE: -O* does more than what's in optLevelFlags?


PUBLIC

I've done some digging into this, and it turns out the DynFlag's `optLevel` itself is used at some places, most notably when creating the main [CoreToDo]. So turning on all these flags on their own doesn't equal setting -On for the right "n"; in fact, currently setting most of these flags does NOTHING on its own unless -On with n>=1 is *also* passed on the command line, and there is no command line flag to *only* turn on Core optimizations in the abstract, without actually turning any specific ones on.

Is this a documentation bug, an implementation bug (as in, if any of the relevant opts are set, then the CoreToDos should always include the optimization steps selected), or a design bug (there is no way to support this meaningfully)?

From: Erdi, Gergo
Sent: Monday, October 11, 2021 12:09 PM
To: 'GHC' <ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>>
Cc: Montelatici, Raphael Laurent <Raphael.Montelatici at sc.com<mailto:Raphael.Montelatici at sc.com>>
Subject: -O* does more than what's in optLevelFlags?


PUBLIC

What is set by -O* that is not included in optLevelFlags?

I would have thought that setting all the flags implied by, e.g., -O1, would be the same as setting -O1 itself. But this is not the case! Here are all the flags for O1 from optLevelFlags:

Opt_DoLambdaEtaExpansion
Opt_DoEtaReduction
Opt_LlvmTBAA
Opt_CallArity
Opt_Exitification
Opt_CaseMerge
Opt_CaseFolding
Opt_CmmElimCommonBlocks
Opt_CmmSink
Opt_CmmStaticPred
Opt_CSE
Opt_StgCSE
Opt_EnableRewriteRules
Opt_FloatIn
Opt_FullLaziness
Opt_IgnoreAsserts
Opt_Loopification
Opt_CfgBlocklayout
Opt_Specialise
Opt_CrossModuleSpecialise
Opt_InlineGenerics
Opt_Strictness
Opt_UnboxSmallStrictFields
Opt_CprAnal
Opt_WorkerWrapper
Opt_SolveConstantDicts
Opt_NumConstantFolding

And here are the ones that are set by O0 (the default) but not by O1:

Opt_IgnoreInterfacePragmas
Opt_OmitInterfacePragmas

So I expected that the following two invocations of GHC would be equivalent:


  1.  ghc -O1
  2.  ghc -fdo-lambda-eta-expansion -fdo-eta-reduction -fllvm-tbaa -fcall-arity -fexitification -fcase-merge -fcase-folding -fcmm-elim-common-blocks -fcmm-sink -fcmm-static-pred -fcse -fstg-cse -fenable-rewrite-rules -ffloat-in -ffull-laziness -fignore-asserts -floopification -fblock-layout-cfg -fspecialise -fcross-module-specialise -finline-generics -fstrictness -funbox-small-strict-fields -fcpr-anal -fworker-wrapper -fsolve-constant-dicts -fnum-constant-folding -fno-ignore-interface-pragmas -fno-omit-interface-pragmas

However, just by observing the output of -dshow-passes, I can see that while -O1 applies all these optimizations, the second version does NOT, even though I have turned on each and every one of them one by one.

Looking at compiler/GHC/Driver/Session.hs, it is not at all clear that -O* should do more than just setting the flags from optLevelFlags. What other flags are implied by -O*?

This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations

Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm

Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer.

Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions.

Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same.

Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20211011/146b7cf7/attachment.html>