<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Dec 4, 2015, at 10:58 AM, Erik Eckstein <<a href="mailto:eeckstein@apple.com" class="">eeckstein@apple.com</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">ad alloc_box:</div><div class=""><br class=""></div><div class="">We have the project_box instruction (which is needed for Joe's upcoming change).</div><div class="">So it's actually a redundancy in SIL that we can obtain the same "value" in 2 completely different ways:</div><div class=""><br class=""></div><div class="">%1 = alloc_box</div><div class="">%2 = project_box %1#0</div><div class="">// %2 == %1#1</div><div class=""><br class=""></div><div class="">ad alloc_stack:</div><div class=""><br class=""></div><div class="">We need the 2 result values only because of dealloc_stack.</div><div class="">AFAIK we don't use dealloc_stack currently anywhere in SIL and also not in IRGen.</div></div></div></blockquote><div><br class=""></div><div>dealloc_stack actually expands to code when the variable is dynamically-sized, and it will also be used for lifetime markers when somebody gets around to it. Lifetime markers are a surprisingly important optimization.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">We verify that the dealloc_stacks are on the right place, i.e. are properly nested, so we could also dynamically compute this information.</div></div></div></blockquote><div><br class=""></div><div>Er, no, if we removed all the dealloc_stacks, there wouldn’t be anything that allowed us to recreate that short of dominance frontiers.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">So let me ask this question: do we really need dealloc_stack?</div><div class="">If no, we also don't need a project_stack for alloc_stack.</div></div></div></blockquote><div><br class=""></div>It is certainly true that we could implement a project_stack operation.</div><div><br class=""></div><div>Please take the idea about giving each result an independent use list seriously, though. How many of these problems would that address?</div><div><br class=""></div><div>John.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 4, 2015, at 10:26 AM, John McCall <<a href="mailto:rjmccall@apple.com" class="">rjmccall@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">On Dec 4, 2015, at 9:51 AM, Erik Eckstein <<a href="mailto:eeckstein@apple.com" class="">eeckstein@apple.com</a>> wrote:<br class=""><blockquote type="cite" class="">On Dec 4, 2015, at 9:34 AM, John McCall <<a href="mailto:rjmccall@apple.com" class="">rjmccall@apple.com</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">On Dec 4, 2015, at 9:06 AM, Erik Eckstein <<a href="mailto:eeckstein@apple.com" class="">eeckstein@apple.com</a>> wrote:<br class="">Hi,<br class=""><br class="">currently some instructions, like alloc_stack and alloc_box (I think they are the only ones) return 2 values. For this we have the "result number" in SILValue, e.g. %3#0, %3#1<br class=""><br class="">We could represent the same by using a projection instruction, e.g.<br class=""><br class="">%3 = alloc_stack $Type // == the old %3#0<br class="">%4 = project_stack %1 // == the old %3#1<br class=""><br class="">And actually we already have the project_box instruction.<br class=""><br class="">This would simplify SILValues and many places in optimization passes/analysis. Yesterday I spent several hours to debug a problem where in some pass the wrong result number was used.<br class=""><br class="">What do you think?<br class=""></blockquote><br class="">This would mean generating a lot of extra instructions for a lot of very common cases, like alloc_stack.<br class=""></blockquote><br class="">A quick grep on the optimized stdlib sil shows that we would need only about 5% more instructions.<br class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">I have no idea what that’s supposed to tell us, though, because that’s purely the end result of an optimization pipeline that’s heavily focused on removing alloc_stack, alloc_box, etc.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></div></blockquote><div class=""><br class=""></div>The optimized SIL is much larger than the SILGen'd SIL, so it's more relevant for memory consumption. But yes, it does not tell us what's the status in between.</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="" class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">About compile time, I'm not sure. On the one hand we will have more instructions, on the other hand we would not have to mask out the ValueDef/ResultNumbers from SILValue every time we use it.<br class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">If that’s important (and masking is really cheap, but maybe it’s important), there are other representational differences we could make that would optimize that. For example, we could split the use lists, so that each result stores its type and use list (meaning that instructions without results don’t need use lists at all).</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">IMO this is a reasonable tradeoff for making the SIL simpler.<br class=""><br class=""><blockquote type="cite" class=""><br class="">Was your bug related to the implicit conversion of a SILInstruction* -> SILValue that silently uses result 0? I’ve been thinking for a while that we should make that conditional on the SILInstruction having exactly one result.<br class=""></blockquote><br class="">Some sort of: it was a value.getDef() which should just be the value.<br class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Okay, but that’s what I mean: we should go through and make sure that its generally not possible to accidentally use a SILInstruction with multiple (or zero) results in any position where you really need a specific SILValue.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">John.</span></div></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></body></html>