<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="">On Oct 26, 2016, at 1:34 AM, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk" class="">peter@pcc.me.uk</a>> wrote:<div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 25, 2016 at 10:48 PM, Chris Lattner <span dir="ltr" class=""><<a href="mailto:clattner@apple.com" target="_blank" class="">clattner@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">Responding to both of your emails in one, sorry for the delay:</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><span class=""><div class="">On Oct 25, 2016, at 11:20 AM, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk" target="_blank" class="">peter@pcc.me.uk</a>> wrote:</div></span><div class=""><div dir="ltr" class=""><div class="gmail_extra"><span class=""><div class="gmail_extra">I think there are a couple of additional considerations we should make here:</div></span><div class="gmail_extra"><ul class=""><li class="">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></ul></div></div></div></div></div></div></blockquote><div class="">I understand where you’re coming from, but I think we’re modeling three different things, and disagreeing about how to clump them together. The three things I see in flight are:</div><div class=""><br class=""></div><div class="">1) typical globals that are laid out in some unknown way in the address space.</div><div class="">2) globals that may be tied to a specific knowable address range due to a limited compilation model (e.g. a deeply embedded core) that fits into an immedaite range (e.g. 0…255, 0…65536, etc).</div><div class="">3) Immediates that are treated as symbolic for CFI’s perspective (so they can’t just be used as a literal immediate) that are resolved at link time, but are known to have limited range.</div><div class=""><br class=""></div><div class="">There is also "4) immediates with an obvious known value”, but those are obviously ConstantInt’s and not interesting to discuss here.</div><div class=""><br class=""></div><div class="">The design I’m arguing for is to clump #2 and #3 into the same group.</div></div></div></blockquote><div class=""><br class=""></div><div class="">I am not sure if this is sound if we want the no-alias assumption (see also below) to hold for #2 but not for #3.</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><div class=""> This can be done one of two different ways, but both ways use the same “declaration side” reference, which has a !range metadata attached to it. The three approaches I see are:</div><div class=""><br class=""></div><div class="">a) Introduce a new GlobalConstant definition, whose value is the concrete address that the linker should resolve.</div><div class="">b) Use an alias as the definition, whose body is a ptrtoint constant of the same value.</div><div class="">c) Use a zero size globalvariable with a range metadata specifying the exact address decided.</div><div class=""><br class=""></div><div class="">I’m not very knowledgable about why approach b won’t work, but if it could, it seems preferable because it fits in with our current model.</div></div></div></blockquote><div class=""><br class=""></div><div class="">b would work in that it would give us the right bits in the object file, but it would be a little odd to use a different type for declarations as for definitions. That said, I don't have a strong objection to it.</div></div></div></div></div></blockquote><div><br class=""></div><div>I can understand what you’re saying here, but this is already the case for aliases. You can never have a “declaration side” for an alias that is an alias (you have to use an external global variable or a function with no body).</div><div><br class=""></div><div>From the discussion over the last day it sounds to me that “b” is the best approach, except for the (significant) annoyance that these things can be possibly aliased. However, I don’t understand how this works in practice today for aliases. By their very name, they are *all about* introducing aliases, so how is AA allowed to assume that two external global variable references are unaliased anyway? One may be resolved as an alias to the other afterall, completely independent of your proposal.</div><div><br class=""></div><div>-Chris</div><div><br class=""></div><div><br class=""></div></div></body></html>