<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 24, 2016 at 10:46 PM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><span class="gmail-m_2530340057393828786m_3881681187698366710m_5541680869149543895m_-3949962315083592956gmail-m_7591719776935233637m_7750588404649377743m_4021482053513704798m_4343788860143678812gmail-"><br><div><blockquote type="cite"><div>On Oct 24, 2016, at 1:07 PM, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk" target="_blank">peter@pcc.me.uk</a>> wrote:</div><br class="gmail-m_2530340057393828786m_3881681187698366710m_5541680869149543895m_-3949962315083592956gmail-m_7591719776935233637m_7750588404649377743m_4021482053513704798m_4343788860143678812gmail-m_2294950690952108678Apple-interchange-newline"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 10, 2016 at 8:12 PM, Peter Collingbourne <span dir="ltr"><<a href="mailto:peter@pcc.me.uk" target="_blank">peter@pcc.me.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>The specific change I have in mind is to allow !range metadata on GlobalObjects. This would<br></div><div><div>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> </div><div>Going back to IR-level representation: here is an alternative representation based on a suggestion from Eli.</div><div><br></div><div>Introduce a new type of GlobalValue called GlobalConstant. GlobalConstant would fit into the GlobalValue hierarchy like this:</div><div><ul><li>GlobalValue<br></li><ul><li>GlobalConstant</li><li>GlobalPointer</li><ul><li>GlobalIndirectSymbol</li><ul><li>GlobalAlias</li><li>GlobalIFunc</li></ul><li>GlobalObject</li><ul><li>Function</li><li>GlobalVariable</li></ul></ul></ul></ul><div>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></div></span><div>Hi Peter,</div><div><br></div><div>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><ul><li>GlobalValue<br></li><ul><li>GlobalConstant</li><span class="gmail-m_2530340057393828786m_3881681187698366710m_5541680869149543895m_-3949962315083592956gmail-m_7591719776935233637m_7750588404649377743m_4021482053513704798m_4343788860143678812gmail-"><li>GlobalIndirectSymbol</li><ul><li>GlobalAlias</li><li>GlobalIFunc</li></ul><li>GlobalObject</li><ul><li>Function</li><li>GlobalVariable</li></ul></span></ul></ul><div>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><span class="gmail-m_2530340057393828786m_3881681187698366710m_5541680869149543895m_-3949962315083592956gmail-m_7591719776935233637m_7750588404649377743m_4021482053513704798m_4343788860143678812gmail-HOEnZb"><font color="#888888"><div><br></div><div>-Chris</div></font></span></div></div></blockquote></div><div class="gmail_extra"><br></div><div class="gmail_extra">Hi Chris,</div><div class="gmail_extra"><br></div><div class="gmail_extra">I think there are a couple of additional considerations we should make here:</div><div class="gmail_extra"><ul><li>What are we trying to model? To me it's clear that GlobalConstant is for modelling integers, not pointers. That alone may not necessarily be enough to motivate a representational change, but...</li><li>If we make our representation fit the model, does that improve the quality of the code? There's clearly been a long standing assumption that GlobalValues are of pointer type. Breaking that assumption has in fact found potential bugs (see e.g. my changes to ValueTracking.cpp in D25930, as well as D25917 which was a requirement for the representational change), and seems like it may help prevent bugs in the future, so I'd say that the answer is most likely yes.</li></ul></div><div class="gmail_extra">On the other hand, using pointers and !range metadata for both GlobalConstant and GlobalVariable seems attractive because this would allow them to be treated "uniformly", but it isn't clear that that would provide a huge benefit. From a correctness perspective we basically only need to care about the range in the backend, and D25878 shows that at least for X86 we only need changes in a handful of places.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks,<br></div></div><div class="gmail_extra">-- <br><div class="gmail-m_2530340057393828786m_3881681187698366710m_5541680869149543895m_-3949962315083592956gmail-m_7591719776935233637m_7750588404649377743m_4021482053513704798m_4343788860143678812gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div>
</div></div>