What's the benefit of taking "do" blocks apart? Is there a way to turn that off?

PUBLIC Hi, I'm seeing 'do' blocks getting taking apart into top-level definitions, so e.g. main = do some complicated expression 1 some complicated expression 2 is compiled into sat_sKv = some complicated expression 1 sat_sKw = \_ -> some complicated expression 2 main = bindIO sat_sKv sat_sKw This seems to happen regardless of any common subexpressions, i.e. it is not the case that sat_sKv or sat_sKw are used anywhere else. What is the intended benefit of this floating-out? Is there a particular Core-to-Core pass that causes this? Is it possible to turn it off? Thanks, Gergo 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.

Hi Gergo, Am Dienstag, dem 28.12.2021 um 15:57 +0000 schrieb Erdi, Gergo via ghc- devs:
PUBLIC
phew
I’m seeing ‘do’ blocks getting taking apart into top-level definitions, so e.g. main = do some complicated expression 1 some complicated expression 2 is compiled into sat_sKv = some complicated expression 1 sat_sKw = \_ -> some complicated expression 2 main = bindIO sat_sKv sat_sKw This seems to happen regardless of any common subexpressions, i.e. it is not the case that sat_sKv or sat_sKw are used anywhere else. What is the intended benefit of this floating-out? Is there a particular Core-to-Core pass that causes this? Is it possible to turn it off?
didn’t investigate deeper (maybe if you provide a small example I would), but just from looking at this: * It is generally preferable to turn local lambda expressions into top-level functions. This way, instead of dynamically allocating a FUN heap object, it’s just a static function. * sat_sKv is an IO expression? Then it is actually a function in a way (taking the “State token” as an argument). So the above applies. * I think this is the FloatOut pass. You can turn it out using -fno-full-laziness. Not sure if some others passes might do similar things, though. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
participants (2)
-
Erdi, Gergo
-
Joachim Breitner