[Git][ghc/ghc][wip/global-package-db] 4 commits: add -fprof-late-overloaded and -fprof-late-overloaded-calls

Matthew Pickering (@mpickering) gitlab at gitlab.haskell.org
Tue Mar 5 10:59:58 UTC 2024



Matthew Pickering pushed to branch wip/global-package-db at Glasgow Haskell Compiler / GHC


Commits:
61bb5ff6 by Finley McIlwaine at 2024-03-04T09:01:40-08:00
add -fprof-late-overloaded and -fprof-late-overloaded-calls

* Refactor late cost centre insertion for extensibility
* Add two more late cost centre insertion methods that add SCCs to overloaded
  top level bindings and call sites with dictionary arguments.
* Some tests for the basic functionality of the new insertion methods

Resolves: #24500

- - - - -
82ccb801 by Andreas Klebinger at 2024-03-04T19:59:14-05:00
x86-ncg: Fix fma codegen when arguments are globals

Fix a bug in the x86 ncg where results would be wrong when the desired output
register and one of the input registers were the same global.

Also adds a tiny optimization to make use of the memory addressing
support when convenient.

Fixes #24496

- - - - -
5d441f0a by Matthew Pickering at 2024-03-05T10:57:55+00:00
Read global package database from settings file

Before this patch, the global package database was always assumed to be
in libdir </> package.conf.d.

This causes issues in GHC's build system because there are sometimes
situations where the package database you need to use is not located in
the same place as the settings file.

* The stage1 compiler needs to use stage1 libraries, so we should set
  "Global Package DB" for the stage1 compiler to the stage1 package
  database.
* Stage 2 cross compilers need to use stage2 libraries, so likewise, we
  should set the package database path to `_build/stage2/lib/`

* The normal situation is where the stage2 compiler uses stage1
  libraries. Then everything lines up.

* When installing we have rearranged everything so that the settings
  file and package database line up properly, so then everything should
  continue to work as before. In this case we set the relative package
  db path to `package.conf.d`, so it resolves the same as before.

* ghc-pkg needs to be modified as well to look in the settings file fo
  the package database rather than assuming the global package database
  location relative to the lib folder.

* Cabal/cabal-install will work correctly because they query the global
  package database using `--print-global-package-db`.

A reasonable question is why not generate the "right" settings files in
the right places in GHC's build system. In order to do this you would
need to engineer wrappers for all executables to point to a specific
libdir. There are also situations where the same package db is used by
two different compilers with two different settings files (think stage2
cross compiler and stage3 compiler).

In short, this 10 line patch allows for some reasonable simplifications
in Hadrian at very little cost to anything else.

Fixes #24502

- - - - -
8e3cb48c by Matthew Pickering at 2024-03-05T10:58:29+00:00
hadrian: Remove stage1 testsuite wrappers logic

Now instead of producing wrappers which pass the global package database
argument to ghc and ghc-pkg, we write the location of the correct
package database into the settings file so you can just use the intree
compiler directly.

- - - - -


30 changed files:

- compiler/GHC/CmmToAsm/X86/CodeGen.hs
- compiler/GHC/Core/LateCC.hs
- + compiler/GHC/Core/LateCC/OverloadedCalls.hs
- + compiler/GHC/Core/LateCC/TopLevelBinds.hs
- + compiler/GHC/Core/LateCC/Types.hs
- + compiler/GHC/Core/LateCC/Utils.hs
- compiler/GHC/Core/Opt/Pipeline.hs
- compiler/GHC/Driver/Flags.hs
- compiler/GHC/Driver/Main.hs
- compiler/GHC/Driver/Session.hs
- compiler/GHC/Settings/IO.hs
- compiler/GHC/Tc/Utils/TcType.hs
- compiler/ghc.cabal.in
- docs/users_guide/9.10.1-notes.rst
- docs/users_guide/profiling.rst
- hadrian/bindist/Makefile
- hadrian/src/Oracles/TestSettings.hs
- hadrian/src/Rules/Generate.hs
- hadrian/src/Rules/Test.hs
- libraries/ghc-boot/GHC/Settings/Utils.hs
- + testsuite/tests/primops/should_run/T24496.hs
- + testsuite/tests/primops/should_run/T24496.stdout
- testsuite/tests/primops/should_run/all.T
- testsuite/tests/profiling/should_run/all.T
- + testsuite/tests/profiling/should_run/scc-prof-overloaded-calls001.hs
- + testsuite/tests/profiling/should_run/scc-prof-overloaded-calls001.prof.sample
- + testsuite/tests/profiling/should_run/scc-prof-overloaded-calls001.stdout
- + testsuite/tests/profiling/should_run/scc-prof-overloaded-calls002.hs
- + testsuite/tests/profiling/should_run/scc-prof-overloaded-calls002.prof.sample
- + testsuite/tests/profiling/should_run/scc-prof-overloaded-calls002.stdout


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/6a9a06debfc3acf933734c0b0e681e92e928e899...8e3cb48ce42cfd6ea83528ae70df486e011bb017

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/6a9a06debfc3acf933734c0b0e681e92e928e899...8e3cb48ce42cfd6ea83528ae70df486e011bb017
You're receiving this email because of your account on gitlab.haskell.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20240305/bce7f13f/attachment.html>


More information about the ghc-commits mailing list