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 simo...@microsoft.com<mailto:simo...@microsoft.com> will cease to work. Use simon.peytonjo...@gmail.com<mailto:simon.peytonjo...@gmail.com> instead. (For now, it just forwards to simo...@microsoft.com.) From: ghc-devs <ghc-devs-boun...@haskell.org> On Behalf Of Erdi, Gergo via ghc-devs Sent: 11 October 2021 08:54 To: 'GHC' <ghc-devs@haskell.org> Cc: Montelatici, Raphael Laurent <raphael.montelat...@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@haskell.org<mailto:ghc-devs@haskell.org>> Cc: Montelatici, Raphael Laurent <raphael.montelat...@sc.com<mailto:raphael.montelat...@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.
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
