Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • GHC GHC
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 4,968
    • Issues 4,968
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 460
    • Merge requests 460
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell Compiler
  • GHCGHC
  • Wiki
  • Commentary
  • Compiler
  • Backends
  • Llvm
  • wip

wip · Changes

Page history
Update tntc status authored Jun 18, 2010 by dterei's avatar dterei
Hide whitespace changes
Inline Side-by-side
commentary/compiler/backends/llvm/wip.md
View page @ 5bc132db
......@@ -32,20 +32,7 @@ The current design is overly complicated and could be faster. It uses String + s
### TABLES_NEXT_TO_CODE
Fix the [TNTC](commentary/compiler/backends/llvm/issues#) issue.
There are two possible approaches:
- Add the needed features to LLVM so that it could natively support this feature. This could be quite a difficult and ambitious project as getting the feature into LLVM would mean fixing all the back-ends so that they support the feature. And you would need to convince the LLVM developers that this feature is worth them supporting which might be a hard sell if they think only GHC would use it.
- A new *evil mangler* to process the assembly produced by LLVM and patch it to support the feature. This wouldn't be so bad if the new *evil mangler* was written in Haskell and only did this one fairly simple thing (current *evil mangler* is in perl and does a fair few things in addition to TNTC).
For either approach, looking at how LLVM's new metadata feature may assist would be very useful:
- [ http://llvm.org/docs/LangRef.html\#metadata](http://llvm.org/docs/LangRef.html#metadata)
- [ http://nondot.org/sabre/LLVMNotes/ExtensibleMetadata.txt](http://nondot.org/sabre/LLVMNotes/ExtensibleMetadata.txt)
- [ http://nondot.org/sabre/LLVMNotes/EmbeddedMetadata.txt](http://nondot.org/sabre/LLVMNotes/EmbeddedMetadata.txt)
We now support [TNTC](commentary/compiler/backends/llvm/issues#) using an approach of gnu as subsections. This seems to work fine but we would like still to move to a pure LLVM solution. Ideally we would implement this in LLVM by allowing a global variable to be associated with a function, so that LLVM is aware that the two will be laid out next to each other and can better optimise (e.g using this approach LLVM should be able to perform constant propagation on info-tables).
### Optimise the output of the LLVM Back-end
......
Clone repository Edit sidebar
  • 9.6
  • Adventures in GHC compile times
  • All things layout
  • AndreasK
  • AndreasPK
  • Back End and Run Time System
  • Backpack refactoring
  • Backpack units
  • Brief Guide for Compiling GHC to iOS
  • Building GHC on Windows with Stack protector support (SSP) (using Make)
  • CAFs
  • CafInfo rework
  • Compiling Case Expressions in ghc
  • Compiling Data.Aeson Error
  • Contributing a Patch
View All Pages