{"action":"created","issue":{"url":"https://api.github.com/repos/ghc-proposals/ghc-proposals/issues/25","repository_url":"https://api.github.com/repos/ghc-proposals/ghc-proposals","labels_url":"https://api.github.com/repos/ghc-proposals/ghc-proposals/issues/25/labels{/name}","comments_url":"https://api.github.com/repos/ghc-proposals/ghc-proposals/issues/25/comments","events_url":"https://api.github.com/repos/ghc-proposals/ghc-proposals/issues/25/events","html_url":"https://github.com/ghc-proposals/ghc-proposals/pull/25","id":184184248,"number":25,"title":"LLVM Bitcode Backend","user":{"login":"angerman","id":40449,"avatar_url":"https://avatars.githubusercontent.com/u/40449?v=3","gravatar_id":"","url":"https://api.github.com/users/angerman","html_url":"https://github.com/angerman","followers_url":"https://api.github.com/users/angerman/followers","following_url":"https://api.github.com/users/angerman/following{/other_user}","gists_url":"https://api.github.com/users/angerman/gists{/gist_id}","starred_url":"https://api.github.com/users/angerman/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/angerman/subscriptions","organizations_url":"https://api.github.com/users/angerman/orgs","repos_url":"https://api.github.com/users/angerman/repos","events_url":"https://api.github.com/users/angerman/events{/privacy}","received_events_url":"https://api.github.com/users/angerman/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":18,"created_at":"2016-10-20T09:53:24Z","updated_at":"2016-11-19T06:38:12Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/ghc-proposals/ghc-proposals/pulls/25","html_url":"https://github.com/ghc-proposals/ghc-proposals/pull/25","diff_url":"https://github.com/ghc-proposals/ghc-proposals/pull/25.diff","patch_url":"https://github.com/ghc-proposals/ghc-proposals/pull/25.patch"},"body":"This proposal intends to change the current textual ir to a bitcode ir\nfor the llvm backend, which should reduce maintenance burden and allow\na wider range of llvm versions to be used with the produced output.\n\n[Rendered](https://github.com/angerman/ghc-proposals/blob/prop/llvm-bitcode/proposals/0000-llvm-bitcode.rst)\n"},"comment":{"url":"https://api.github.com/repos/ghc-proposals/ghc-proposals/issues/comments/261697189","html_url":"https://github.com/ghc-proposals/ghc-proposals/pull/25#issuecomment-261697189","issue_url":"https://api.github.com/repos/ghc-proposals/ghc-proposals/issues/25","id":261697189,"user":{"login":"thoughtpolice","id":3416,"avatar_url":"https://avatars.githubusercontent.com/u/3416?v=3","gravatar_id":"","url":"https://api.github.com/users/thoughtpolice","html_url":"https://github.com/thoughtpolice","followers_url":"https://api.github.com/users/thoughtpolice/followers","following_url":"https://api.github.com/users/thoughtpolice/following{/other_user}","gists_url":"https://api.github.com/users/thoughtpolice/gists{/gist_id}","starred_url":"https://api.github.com/users/thoughtpolice/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/thoughtpolice/subscriptions","organizations_url":"https://api.github.com/users/thoughtpolice/orgs","repos_url":"https://api.github.com/users/thoughtpolice/repos","events_url":"https://api.github.com/users/thoughtpolice/events{/privacy}","received_events_url":"https://api.github.com/users/thoughtpolice/received_events","type":"User","site_admin":false},"created_at":"2016-11-19T06:38:12Z","updated_at":"2016-11-19T06:38:12Z","body":"> That is basically a solution to how to fix the textual ir problem using additional tooling; while this proposal basically proposes to rewrite the whole backend with a different approach (namely bitcode instead of textual ir) to sidestep the required tooling; so yes this proposal is proposing something fundamentally different from the ImprovedLLVMBackend idea.\r\n\r\nI may be misinterpreting you, but this proposal does NOT sidestep most of the concerns in the actual ImprovedLLVMBackend proposal. The only thing this addresses is actual textual IR representation being flaky; but that's mostly a red herring, not relevant to the real point(s) of the original proposal. It does NOT fix problems like users encountering vastly different behavior of the backend in the wild due to version changes, or things like distro inconsistency due to maintainers applying patches (this was a complete nightmare for the longest time on ARM, and could only be solved by manually compiling LLVM yourself). It does not make it any more possible to do things like augment our LLVM installation with plugins for GHC (such as Max's old plugin), or properly tune it for compile-time performance with controlled variables, etc. It's also unclear to me if this addresses any kind of problems with the actual evolution of IR semantics over time (e.g. just because the bitcode format is stable doesn't always mean it's going to behave correctly, from version to version, we may very well need to change the generator anyway to get LLVM to behave how we like).\r\n\r\nIf I'm misinterpreting this I apologize; I might be reading into \"a solution to how to fix the textual ir problem\" too much, but the original proposal is *very much* not about textual IR by itself.\r\n\r\nThese are all effectively QA assurances, and they are all substantially more important to reliability and maintainability than just fixing some textual IR generation stuff (which again, would be for a fixed LLVM version. It's slightly more cumbersome to generate text I guess, but when you completely control the toolchain, it's really not a huge burden.)\r\n\r\n---\r\n\r\nThat said, this is all independent of the actual merits of *this proposal by itself*. It might very well be a good change despite only fixing some code quality issues. I'm basically fine with it, myself, to be honest (the LLVM backend sees little work outside maintainability due to it being a pain, and it's not clear to me if a bitcode will do much more than churn some code, but the reusability aspect is a bonus and I can approve of that. Some LOC numbers would be interesting.)\r\n\r\nProbably the main complaint I do have is that you're going to have to add 4 more submodules to GHC (3 + `base16-bytestring`, one of your dependencies), and that will always be a pain. It also will have other impacts and increase the build time a bit, with some constant overhead from the packaging structure alone (e.g. `ghc-cabal` needs to now iterate over 4 more packages, configure them, get their dependencies, etc). That's not a dealbreaker, but I do want to bring it up. Why not just make a monolithic package? I kinda get why people don't like monolithic packages for certain libraries like `lens`, but these 4 libraries effectively are just in the category of \"data structure manipulation, with an EDSL\" and has effectively no dependencies outside what's available by default. Is there really a need to 'micropackage' something that's only less than 10 modules anyway?"}}
{"actor":{"display_login":"thoughtpolice"}}