{"action":"created","issue":{"url":"https://api.github.com/repos/pfalcon/ScratchABlock/issues/33","repository_url":"https://api.github.com/repos/pfalcon/ScratchABlock","labels_url":"https://api.github.com/repos/pfalcon/ScratchABlock/issues/33/labels{/name}","comments_url":"https://api.github.com/repos/pfalcon/ScratchABlock/issues/33/comments","events_url":"https://api.github.com/repos/pfalcon/ScratchABlock/issues/33/events","html_url":"https://github.com/pfalcon/ScratchABlock/issues/33","id":381767180,"node_id":"MDU6SXNzdWUzODE3NjcxODA=","number":33,"title":"SSA is upon us...","user":{"login":"pfalcon","id":500451,"node_id":"MDQ6VXNlcjUwMDQ1MQ==","avatar_url":"https://avatars3.githubusercontent.com/u/500451?v=4","gravatar_id":"","url":"https://api.github.com/users/pfalcon","html_url":"https://github.com/pfalcon","followers_url":"https://api.github.com/users/pfalcon/followers","following_url":"https://api.github.com/users/pfalcon/following{/other_user}","gists_url":"https://api.github.com/users/pfalcon/gists{/gist_id}","starred_url":"https://api.github.com/users/pfalcon/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pfalcon/subscriptions","organizations_url":"https://api.github.com/users/pfalcon/orgs","repos_url":"https://api.github.com/users/pfalcon/repos","events_url":"https://api.github.com/users/pfalcon/events{/privacy}","received_events_url":"https://api.github.com/users/pfalcon/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":1,"created_at":"2018-11-16T21:30:23Z","updated_at":"2018-11-17T19:03:25Z","closed_at":null,"author_association":"OWNER","body":"So, I pushed initial support for conversion to SSA, e.g. tests: https://github.com/pfalcon/ScratchABlock/commit/72a047e4c10aea2f6b5a2782a38cb57a2737ef0e . To remind, I wanted to postpone introduction of SSA, to not fall into common trap when people treat as some magic device, without good understanding of the frontier where it really becomes needed, how to deal with it, what drawbacks it has, etc.\r\n\r\nAll this time I (in the background) pumped up my understanding and well, now I hoped I grasped the essence of its construction, that the one true SSA is the maximal SSA, its construction is simple and devoid of any arcane knowledge, and any other form is nothing but implementation-level optimizations, and they're thus strictly optional.\r\n\r\nGoing beyond construction is definitely on next TODOs, but first syntax for phi functions need to be set. How it's done currently (examples above) is in a textbook way, where phi just takes list of values, in the same order as predecessors (and that order is of course stable in ScratchABlock, partly exactly because of anticipation of phi() introduction).\r\n\r\nThat should work pretty well for intermediate output, but of course barely suitable as input, where predecessors aren't so explicit, and their order shouldn't have to be clear/stable either. And the input case is of course important (interoperability with LLVM is definitely on the table).\r\n\r\nSo, there're two facets of it:\r\n\r\n1. External syntax, i.e. how it's rendered in PseudoC source program.\r\nThis can be as simple as normal C fuction syntax, e.g. `phi(label1, $r0_1, label2, $r0_2)`, or something fancier, e.g. `phi(label1: $r0_1, label2: $r0_2)`. Of course, something fancier is definitely not compatible with C syntax, and staying within its bounds is the aim of PseudoC. But then phi() is not an executable function, so having not a C syntax is somehow not completely crazy idea.\r\n2. Internal syntax, i.e. should there be bblock addresses retained as arguments of phi's EXPR, or not? Common sense says it's superfluous, because in internal representation, there's no ambiguity. But perhaps as a debugging measure still may be useful?\r\n\r\nFor reference, LLVM's syntax:\r\n\r\n~~~\r\n%indvar = phi i32 [ 0, %LoopHeader ], [ %nextindvar, %Loop ]\r\n~~~\r\n\r\nThat order of bblock addr vs value I don't like. The most important thing in phi is not value, but the fact that it depends on predecessor block, so it would rather go first.\r\n\r\n~~~\r\n$indvar = phi(LoopHeader, 0, Loop, $nextindvar)\r\n$indvar = phi(LoopHeader: 0, Loop: $nextindvar)\r\n~~~\r\n\r\nWell, to make it more C-like, and still preserve pair-ness, could do:\r\n\r\n~~~\r\n$indvar = phi((LoopHeader, 0), (Loop, $nextindvar))\r\n~~~\r\n\r\nWell, that's still not really a valid C syntax. Then could do:\r\n~~~\r\n$indvar = phi(_(LoopHeader, 0), _(Loop, $nextindvar))\r\n~~~\r\n\r\nBut that's really going down the rabbit hole...\r\n"},"comment":{"url":"https://api.github.com/repos/pfalcon/ScratchABlock/issues/comments/439639887","html_url":"https://github.com/pfalcon/ScratchABlock/issues/33#issuecomment-439639887","issue_url":"https://api.github.com/repos/pfalcon/ScratchABlock/issues/33","id":439639887,"node_id":"MDEyOklzc3VlQ29tbWVudDQzOTYzOTg4Nw==","user":{"login":"maximumspatium","id":6561800,"node_id":"MDQ6VXNlcjY1NjE4MDA=","avatar_url":"https://avatars3.githubusercontent.com/u/6561800?v=4","gravatar_id":"","url":"https://api.github.com/users/maximumspatium","html_url":"https://github.com/maximumspatium","followers_url":"https://api.github.com/users/maximumspatium/followers","following_url":"https://api.github.com/users/maximumspatium/following{/other_user}","gists_url":"https://api.github.com/users/maximumspatium/gists{/gist_id}","starred_url":"https://api.github.com/users/maximumspatium/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/maximumspatium/subscriptions","organizations_url":"https://api.github.com/users/maximumspatium/orgs","repos_url":"https://api.github.com/users/maximumspatium/repos","events_url":"https://api.github.com/users/maximumspatium/events{/privacy}","received_events_url":"https://api.github.com/users/maximumspatium/received_events","type":"User","site_admin":false},"created_at":"2018-11-17T19:03:25Z","updated_at":"2018-11-17T19:03:25Z","author_association":"CONTRIBUTOR","body":">@maximumspatium, Comments are welcome.\r\n\r\nPaul, there is not much I can add to your elaboration. As you said, the LLVM syntax is incompatible with C syntax and rather cumbersome to read. The other suggestions look better, although each of them has its own pros and cons:\r\n\r\n`$indvar = phi(LoopHeader, 0, Loop, $nextindvar)` doesn't show clearly that even and odd parameters belong together\r\n\r\n`$indvar = phi(LoopHeader: 0, Loop: $nextindvar)` is better but that key:val syntax is typical for script languages, not C\r\n\r\n`$indvar = phi((LoopHeader, 0), (Loop, $nextindvar))` that tuple notation looks rather Python-like than C-like\r\n\r\n`$indvar = phi(_(LoopHeader, 0), _(Loop, $nextindvar))` is the best option IMHO, although \"_\" looks like an ugly attempt to make tuples looks like function calls\r\n\r\nWhat's about this:\r\n\r\n`$indvar = phi(LoopHeader[0], Loop[$nextindvar])`\r\n\r\nAnyway, it fully conforms to the C-syntax and doesn't introduce anything superfluous. The notion of `location:variable` is represented as arrays with subscripts. They can be interpreted as dict[val], too."}}
{"actor":{"display_login":"maximumspatium"}}