<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 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"><div class="">On Oct 25, 2016, at 11:20 AM, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk" class="">peter@pcc.me.uk</a>> wrote:</div><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_extra">I think there are a couple of additional considerations we should make here:</div><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. 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. After that, approach C seems like a nice fallback because it again doesn’t require major extensions to our model. Finally, approach A seems like the most explicit model, but has the disadvantage of introducing a new IR concept that will be rarely used (and thus prone to bugs due to it not being widely tested).</div><div class=""><br class=""></div><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_extra"><ul class=""><li class="">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></div></div></div></div></blockquote>I’d argue the other side of it. The quality of the code is higher if we have invariants (like all globals are pointers) because that simplifies assumptions by eliminating cases where “is a pointer” appears to be true, but isn’t actually true in all cases. I’m not an expert on CFI or how widely it will ultimately impact the compiler hacker consciousness, but I’m pretty sure that the current model for globals and functions will remain more prominent. If you choose to break this invariant, you’ll be continually swimming upstream against assumptions made throughout the compiler, both in code written today but also in code written in the future.<br class=""></div><div class=""><br class=""></div>On Oct 25, 2016, at 6:52 PM, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk" class="">peter@pcc.me.uk</a>> wrote:<br class=""><div><blockquote type="cite" class=""><br class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra">So, to summarise the overall consensus on this thread:</div><div class="gmail_extra">- We should introduce a GlobalConstant class which supports definitions and declarations</div></div></div></blockquote><div><br class=""></div><div>Why would globalconstant need to support declarations? Seems like an external global should be able to handle this case.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra">- It should derive from GlobalValue</div><div class="gmail_extra">- No type changes for GlobalValue (i.e. still required to be pointer type)</div><div class="gmail_extra">- To communicate the range we should use !range metadata and support it on GlobalConstant as well as GlobalVariable</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">Although I am not convinced that this is the right representation I appear to be in the minority here, so if this seems reasonable to folks I will go ahead and implement it.<br class=""></div></div></div></blockquote><br class=""></div><div>I’m not trying to steamroll you over: what is your specific concern?</div><br class=""><div class="">-Chris</div></body></html>