{"action":"created","issue":{"url":"https://api.github.com/repos/llir/llvm/issues/29","repository_url":"https://api.github.com/repos/llir/llvm","labels_url":"https://api.github.com/repos/llir/llvm/issues/29/labels{/name}","comments_url":"https://api.github.com/repos/llir/llvm/issues/29/comments","events_url":"https://api.github.com/repos/llir/llvm/issues/29/events","html_url":"https://github.com/llir/llvm/issues/29","id":303193300,"node_id":"MDU6SXNzdWUzMDMxOTMzMDA=","number":29,"title":"Upcoming release of the llir/llvm project","user":{"login":"mewmew","id":1414531,"node_id":"MDQ6VXNlcjE0MTQ1MzE=","avatar_url":"https://avatars1.githubusercontent.com/u/1414531?v=4","gravatar_id":"","url":"https://api.github.com/users/mewmew","html_url":"https://github.com/mewmew","followers_url":"https://api.github.com/users/mewmew/followers","following_url":"https://api.github.com/users/mewmew/following{/other_user}","gists_url":"https://api.github.com/users/mewmew/gists{/gist_id}","starred_url":"https://api.github.com/users/mewmew/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mewmew/subscriptions","organizations_url":"https://api.github.com/users/mewmew/orgs","repos_url":"https://api.github.com/users/mewmew/repos","events_url":"https://api.github.com/users/mewmew/events{/privacy}","received_events_url":"https://api.github.com/users/mewmew/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":4,"created_at":"2018-03-07T17:38:11Z","updated_at":"2018-07-10T20:28:58Z","closed_at":null,"author_association":"MEMBER","body":"This notice is intended to give a heads up for those using the `llir/llvm` library. The next release will include complete support for all intrinsics of the LLVM IR language. The work is currently in a flux, and to experiment with different API designs and simplify the parser logic and reduce the code duplication in the project, a new repo has been created during the experimental phase.\r\n\r\nhttps://github.com/mewmew/l\r\n\r\nAt the current stage, the grammar is capable of parsing the entirety of the LLVM IR language, including specialized metadata nodes (#26).\r\n\r\nWhile working on this we will also try to take into consideration previous issues that have been identified with the parser (such as the handling of quoted strings #24).\r\n\r\nThe `llir/llvm/ir` package will be extended to support the entire LLVM IR language; thus resolving #23 as linkage information will be present in the in-memory intermediate representation form.\r\n\r\nWith the upcoming release, read support for all of the LLVM IR language concepts will have been implemented; thus resolving #15.\r\n\r\nSimilarly; we will now have a grammar covering the entire LLVM IR language; thus resolving #2.\r\n\r\nWith the addition of support for specialized metadata nodes, the second requirement of `llgo` will also be fully supported (#3); *llgo uses the DIBuilder API for generating debug metadata (DWARF, et al.). This could be built outside of the core (it's just a matter of creating metadata nodes in a particular format), just be aware that it's pretty finicky and easy to break.*.\r\n\r\nFor IR construction, a similar approach will be used as has been done before. Personally, we feel this approach has worked out well and has been quite pleasant to use. If anyone has input on their own experience using the API of the `llir/llvm/ir` package to construct LLVM IR, please let us know as that could help shape the upcoming release. As for `llgo`, the first requirement *in terms of using the LLVM API for generating code, it's mostly write-only via the builder API. Bitcode and IR reading is not important (at the moment?), but writing is; one or the other is required, but preferably both.* is satisfied by this API, and has been for a while. Although, now the `llir/llvm/ir` package will contain the support for the entire LLVM IR language, and now just a subset; thus the requirement should be satisfied in full.\r\n\r\nModule top-level information such as target triple and data layout has been and will continue to be recorded and maintained by the IR API, thus supporting the third requirement of `llgo`; *llgo needs to be able to look up target data (arch word size, alignment, etc.) from triples*.\r\n\r\nGenerating C-shared library bindings compatible with the official C library of the LLVM project is an ambitious goal that is left for a future release (#12). Anyone specifically interested in this topic, feel free to get in touch with us or continue the discussion in the dedicated issue.\r\n\r\nSimilarly, interaction with the Go runtime is targeted for a future release, and those with knowledge in this domain are happily invited to the discussion on what is needed and how to bring this about (#18).\r\n\r\nAs for use-tracking and data analysis support (#19), more thought will be required to get a clean API. This is therefore targeted for a future release.\r\n\r\nSo, to summarize, the upcoming release of the `llir/llvm` project will include read and write support for the entire LLVM IR language. In other words, it will be possible to parse arbitrary LLVM IR assembly files into an in-memory representation, aka the one defined in package `llir/llvm/ir`. And the in-memory IR representation will have support for the entire LLVM IR language, and can be converted back to LLVM IR assembly for interaction with other tools, such as the LLVM optimizer.\r\n\r\nAny feedback is welcome, so we know we're heading in the right direction.\r\n\r\nCheerful regards,\r\n/u & i"},"comment":{"url":"https://api.github.com/repos/llir/llvm/issues/comments/403955240","html_url":"https://github.com/llir/llvm/issues/29#issuecomment-403955240","issue_url":"https://api.github.com/repos/llir/llvm/issues/29","id":403955240,"node_id":"MDEyOklzc3VlQ29tbWVudDQwMzk1NTI0MA==","user":{"login":"pwaller","id":438648,"node_id":"MDQ6VXNlcjQzODY0OA==","avatar_url":"https://avatars0.githubusercontent.com/u/438648?v=4","gravatar_id":"","url":"https://api.github.com/users/pwaller","html_url":"https://github.com/pwaller","followers_url":"https://api.github.com/users/pwaller/followers","following_url":"https://api.github.com/users/pwaller/following{/other_user}","gists_url":"https://api.github.com/users/pwaller/gists{/gist_id}","starred_url":"https://api.github.com/users/pwaller/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pwaller/subscriptions","organizations_url":"https://api.github.com/users/pwaller/orgs","repos_url":"https://api.github.com/users/pwaller/repos","events_url":"https://api.github.com/users/pwaller/events{/privacy}","received_events_url":"https://api.github.com/users/pwaller/received_events","type":"User","site_admin":false},"created_at":"2018-07-10T20:28:58Z","updated_at":"2018-07-10T20:28:58Z","author_association":"NONE","body":"> Definitely. we'll make sure to tag the upcoming release with vgo compatible semantic versions (v0.3.0).\r\n\r\nBy the way, if you're making a big backwards incompatible change, you should bump the major version number. I can elaborate further on why if it's not obvious, or I can recommend Russ Cox's writings on the matter: https://research.swtch.com/vgo-import\r\n\r\nThe upshot is that you can do big breaking changes without breaking existing users (even those just using old-style Go get)."}}
{"actor":{"display_login":"pwaller"}}