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@haskell.org>
Cc: Montelatici, Raphael Laurent <Raphael.Montelatici@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.