<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 10, 2015, at 11:02 AM, David Blaikie <<a href="mailto:dblaikie@gmail.com" class="">dblaikie@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br class="Apple-interchange-newline"><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: 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 class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: 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;">On Mon, Feb 9, 2015 at 9:47 AM, Pete Cooper<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:peter_cooper@apple.com" target="_blank" class="">peter_cooper@apple.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Feb 6, 2015, at 6:40 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com" target="_blank" class="">chandlerc@google.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Fri, Feb 6, 2015 at 6:09 PM, Reid Kleckner<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:rnk@google.com" target="_blank" class="">rnk@google.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="ltr" class="">I think we should keep GEP essentially the same, but disassociate the type being GEPd over from the type of the operands. So, assuming the new ptr type is spelled "ptr", we could use this syntax:<div class="">%inner.ptr = getelementptr ptr, ptr %x, i32 1</div><div class=""><br class=""></div><div class="">Or if I was adding 1 to a "struct A*" value in C:</div><div class="">%next_elt = getelementptr %struct.A, ptr %x, i32 1</div><div class=""><br class=""></div><div class="">Ditto for all other instructions that care about pointee types, like load and store:</div><div class="">%v = load i32, ptr %p ; loads already know (and store!) their loaded type internally</div><div class="">store i32 %v, ptr %p ; no need to duplicate that %p points to, we have the type on %v</div></div></blockquote><div class=""><br class=""></div><div class="">Emphatically agree. No instruction should really change semantics here. GEPs should keep working the exact same way, the type involved should just be separate from the pointer's type.</div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="ltr" class=""><div class=""><br class=""></div><div class="">I don't think this can be incremental, I think it all goes at once.</div></div></blockquote><div class=""><br class=""></div><div class="">I have some ideas of how to make it incremental:</div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="ltr" class=""><div class="">I think you might need to add a new GEP bitcode opcode, since that instruction grows a new type operand that doesn't come from an operand type or result type.</div></div></blockquote><div class=""><br class=""></div><div class="">Yep. And you can add this first, defining the semantics to be as-if the pointer operand was bit casted to a pointer to the new type. Then we could (in theory, not in practice!) even use and test it with the current IR, passing an i8* or any other pointer type operand.</div></div></div></div></div></blockquote></span>I’m not sure we need the new instructions at all.</div><div class=""><br class=""></div><div class="">Really what we want is for Load and GEP to carry around a Type* alongside all their operands. This can be added now to the existing Load and GEP insts, and to their constructors/create methods.</div></div></blockquote><div class=""><br class="">I'm good with either option (what Chandler described or what Pete's described here). I am actually leaning towards what you've got here, Pete, unless people have objections.<br class=""><br class="">At a first pass we wouldn't even need to break LLVM IRBuilder API compatibility - we can take the type from the operand and use that to create the GEP/Load. Add the alternative builder calls that accept the type explicitly and start migrating callers to pass it in explicitly before removing the old version.<br class=""><br class="">Frontend test cases would need to be cleaned up up-front, because we'd start generating the new GEP/Load syntax as soon as it was introduced in this way.<br class=""><br class="">Then, once GEP/Load (anything else that consumes a pointer & cares about its type?) are done I could introduce the new ptr type, start making instructions be of that type instead - probably at this point I'd spend time cleaning up clang so it doesn't depend on the type of a pointer type at all (I imagine there will be things I can't catch in the first pass even if I do my best to push the types through the stack and not depend on the ones in the pointer operand).<br class=""><br class="">Sound plausible?<br class=""></div></div></div></blockquote>Yeah, sounds great.</div><div><br class=""></div><div>Thanks,</div><div>Pete<br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: 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;"><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class=""><br class=""></div><div class="">Going through all of the codebase to ensure we pass in the Type* in all the right places was going to have to be done anyway for a new instruction, but now can be done on the existing instructions. You can also assert (temporarily) to ensure that the type passed in matches the pointer operand type.</div><div class=""><br class=""></div><div class="">I do agree the actual final switch could be tricky, but I think we should do what I’ve suggested here first, then see what happens if we just make the switch (which if we get everything in place really just means turning off a bunch of asserts and parser error checks).</div><div class=""><br class=""></div><div class="">Personally I think this is far less work and less disruptive to out of tree targets, which are otherwise going to have to find all their own uses of the old style GEP instruction and add another GEP instruction to switches, etc.</div><div class=""><br class=""></div><div class="">...</div><div class=""><span class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">Same goes for the load instruction. We could support the new syntax first.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Next, I think you might be able to introduce a generic pointer type, spelled as 'ptr' which would verifier fail if used with the old load or gep instructions. You might have to synthesize an unnamable pointee type to use for the in-memory representation, but that seems not beyond reason. Then you can wire up all the asm parsing and printing and bitcode stuff incrementally without any disruption.</div><div class=""><br class=""></div><div class="">The remaining parts are more interesting and maybe harder to do incrementally, but still seem at least somewhat decomposable:</div><div class=""><br class=""></div><div class="">- switching all of the LLVM optimizer and all of Clang to produce the new forms of GEP and load rather than the old forms</div><div class="">- switching all of the optimizer and clang to use the new boring pointer type now that they never form old gep and load instructions</div><div class="">- switching all the auto-upgrade functionality on</div><div class="">- removing the in-memory support for the old forms</div><div class="">- simplifying a ton of the in-memory support and the optimizer now that the old forms can't show up</div><div class=""> <br class=""></div><div class=""><br class=""></div><div class="">Also:</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="ltr" class=""><div class="">It also wouldn't be too hard to accept the old .ll syntax, since the upgrade path mostly discards information.</div></div></blockquote></div><div class="gmail_extra"><br class=""></div></div><div class="gmail_extra">I agree here. If only because of th eregression test suite, and the *incredible* tediousness of updating the pointers. The auto-upgrade for this kind of thing is essentially perfect.</div></div></div></blockquote></span>I agree in principle, but I think the precedent here is dangerous.</div><div class=""><br class=""></div><div class=""><div class="">Thanks,</div><div class="">Pete</div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><br class=""></div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">-Chandler</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra"><br class=""></div></div><span class="">_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank" class="">LLVMdev@cs.uiuc.edu</a><span class="Apple-converted-space"> </span> <a href="http://llvm.cs.uiuc.edu/" target="_blank" class="">http://llvm.cs.uiuc.edu</a><br class=""><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br class=""></span></div></blockquote></div><br class=""></div><br class="">_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:LLVMdev@cs.uiuc.edu" class="">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu/" target="_blank" class="">http://llvm.cs.uiuc.edu</a><br class=""><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a></blockquote></div></div></blockquote></div><br class=""></body></html>