<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 25, 2016 at 9:09 AM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><div class="h5"><div dir="ltr">On Mon, Oct 24, 2016 at 10:48 PM Chris Lattner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="m_-1015218368943426981gmail_msg"><br class="m_-1015218368943426981gmail_msg"><div class="m_-1015218368943426981gmail_msg"><blockquote type="cite" class="m_-1015218368943426981gmail_msg"><div class="m_-1015218368943426981gmail_msg">On Oct 24, 2016, at 1:07 PM, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk" class="m_-1015218368943426981gmail_msg" target="_blank">peter@pcc.me.uk</a>> wrote:</div><br class="m_-1015218368943426981m_4142622730276185891Apple-interchange-newline m_-1015218368943426981gmail_msg"><div class="m_-1015218368943426981gmail_msg"><div dir="ltr" class="m_-1015218368943426981gmail_msg"><div class="gmail_extra m_-1015218368943426981gmail_msg"><div class="gmail_quote m_-1015218368943426981gmail_msg">On Mon, Oct 10, 2016 at 8:12 PM, Peter Collingbourne <span dir="ltr" class="m_-1015218368943426981gmail_msg"><<a href="mailto:peter@pcc.me.uk" class="m_-1015218368943426981gmail_msg" target="_blank">peter@pcc.me.uk</a>></span> wrote:<br class="m_-1015218368943426981gmail_msg"><blockquote class="gmail_quote m_-1015218368943426981gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="m_-1015218368943426981gmail_msg"><div class="m_-1015218368943426981gmail_msg">The specific change I have in mind is to allow !range metadata on GlobalObjects. This would<br class="m_-1015218368943426981gmail_msg"></div><div class="m_-1015218368943426981gmail_msg"><div class="m_-1015218368943426981gmail_msg">be similar to existing !range metadata, but it would apply to the "address" of the attached GlobalObject, rather than any value loaded from it. Its presence on a GlobalObject would also imply that the address of the GlobalObject is "fixed" at link time.</div></div></div></blockquote><div class="m_-1015218368943426981gmail_msg"> </div><div class="m_-1015218368943426981gmail_msg">Going back to IR-level representation: here is an alternative representation based on a suggestion from Eli.</div><div class="m_-1015218368943426981gmail_msg"><br class="m_-1015218368943426981gmail_msg"></div><div class="m_-1015218368943426981gmail_msg">Introduce a new type of GlobalValue called GlobalConstant. GlobalConstant would fit into the GlobalValue hierarchy like this:</div><div class="m_-1015218368943426981gmail_msg"><ul class="m_-1015218368943426981gmail_msg"><li class="m_-1015218368943426981gmail_msg">GlobalValue<br class="m_-1015218368943426981gmail_msg"></li><ul class="m_-1015218368943426981gmail_msg"><li class="m_-1015218368943426981gmail_msg">GlobalConstant</li><li class="m_-1015218368943426981gmail_msg">GlobalPointer</li><ul class="m_-1015218368943426981gmail_msg"><li class="m_-1015218368943426981gmail_msg">GlobalIndirectSymbol</li><ul class="m_-1015218368943426981gmail_msg"><li class="m_-1015218368943426981gmail_msg">GlobalAlias</li><li class="m_-1015218368943426981gmail_msg">GlobalIFunc</li></ul><li class="m_-1015218368943426981gmail_msg">GlobalObject</li><ul class="m_-1015218368943426981gmail_msg"><li class="m_-1015218368943426981gmail_msg">Function</li><li class="m_-1015218368943426981gmail_msg">GlobalVariable</li></ul></ul></ul></ul><div class="m_-1015218368943426981gmail_msg">GlobalValue would no longer be assumed to be of pointer type. The getType() overload that takes a PointerType, as well as getValueType() would be moved down to GlobalPointer. (A nice side benefit of this is that it would help flush out cases where we are unnecessarily depending on global pointee types.)</div></div></div></div></div></div></blockquote><br class="m_-1015218368943426981gmail_msg"></div></div><div style="word-wrap:break-word" class="m_-1015218368943426981gmail_msg"><div class="m_-1015218368943426981gmail_msg">Hi Peter,</div><div class="m_-1015218368943426981gmail_msg"><br class="m_-1015218368943426981gmail_msg"></div><div class="m_-1015218368943426981gmail_msg">I agree that it makes sense to introduce a new GlobalConstant IR node for this sort of thing.  That said, have you considered a design where GlobalConstant is still required to be a pointer type?  If you did this, you would end up with a simpler and less invasive design of:</div><div class="m_-1015218368943426981gmail_msg"><ul class="m_-1015218368943426981gmail_msg"><li class="m_-1015218368943426981gmail_msg">GlobalValue<br class="m_-1015218368943426981gmail_msg"></li><ul class="m_-1015218368943426981gmail_msg"><li class="m_-1015218368943426981gmail_msg">GlobalConstant</li></ul></ul></div></div><div style="word-wrap:break-word" class="m_-1015218368943426981gmail_msg"><div class="m_-1015218368943426981gmail_msg"><ul class="m_-1015218368943426981gmail_msg"><ul class="m_-1015218368943426981gmail_msg"><li class="m_-1015218368943426981gmail_msg">GlobalIndirectSymbol</li><ul class="m_-1015218368943426981gmail_msg"><li class="m_-1015218368943426981gmail_msg">GlobalAlias</li><li class="m_-1015218368943426981gmail_msg">GlobalIFunc</li></ul><li class="m_-1015218368943426981gmail_msg">GlobalObject</li><ul class="m_-1015218368943426981gmail_msg"><li class="m_-1015218368943426981gmail_msg">Function</li><li class="m_-1015218368943426981gmail_msg">GlobalVariable</li></ul></ul></ul></div></div><div style="word-wrap:break-word" class="m_-1015218368943426981gmail_msg"><div class="m_-1015218368943426981gmail_msg"><ul class="m_-1015218368943426981gmail_msg"><ul class="m_-1015218368943426981gmail_msg"></ul></ul><div class="m_-1015218368943426981gmail_msg">I think that this would be better for (e.g.) the X86 backend anyway, since global objects can be assigned to specific addresses with linker maps, and thus have small addresses (and this is expressible with the range metadata).  This means that GlobalConstant and other GlobalValues should all be usable in the same places in principle.</div></div></div></blockquote><div><br></div></div></div><div>If this works, it does seem better. But I can imagine it being hard to take the "load" of the global constant and turn it into a direct reference to a symbolic immediate operand to an instruction.</div></div></div></blockquote><div><br></div><div>I think Chris's idea is that you would not use a load but rather a ptrtoint to access the underlying value.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>And it isn't clear that you can assign the "foo" in Peter's example an address even with a linker map -- it isn't a global object at all, it is a symbolic name for an immediate IIUC? (It's entirely possible I've misunderstood either what Peter needs or what you're suggesting, but I'd at least like to understand it! =D)</div></div></div></blockquote><div><br></div><div>I would imagine that the symbolic name could be resolved by the linker with an absolute symbol (from a linker map or otherwise).</div><div><br></div><div>Thanks,</div></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div>
</div></div>