<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 2016-Sep-26, at 11:11, Chandler Carruth <<a href="mailto:chandlerc@gmail.com" class="">chandlerc@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: 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"><div dir="ltr" class="">On Sat, Sep 24, 2016 at 4:39 PM Duncan P. N. Exon Smith via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class=""></div><blockquote 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;" class="gmail_quote"><br class="gmail_msg">> On 2016-Sep-24, at 15:16, Mehdi Amini <<a href="mailto:mehdi.amini@apple.com" target="_blank" class="gmail_msg">mehdi.amini@apple.com</a>> wrote:<br class="gmail_msg">><br class="gmail_msg">>><br class="gmail_msg">>> On Sep 24, 2016, at 3:06 PM, Duncan P. N. Exon Smith via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="gmail_msg">llvm-dev@lists.llvm.org</a>> wrote:<br class="gmail_msg">>><br class="gmail_msg">>> r261464 added a type called ConstantData to the Value hierarchy. This<br class="gmail_msg">>> is a parent type for constants with no operands, such as i32 0 and null.<br class="gmail_msg">>><br class="gmail_msg">>> Since then, I've removed most instances of iterating through the<br class="gmail_msg">>> use-lists of an instance of ConstantData. I'd like to make this<br class="gmail_msg">>> illegal. Since the users of ConstantData are spread across an<br class="gmail_msg">>> LLVMContext, most code that looks at the users is wrong. Adding an<br class="gmail_msg">>> assertion should catch a lot of bugs (see r263853 and r263875) and<br class="gmail_msg">>> avoid some expensive walks through uninteresting code.<br class="gmail_msg">>><br class="gmail_msg">>> (The same is not true of Constant, generally. A GlobalValue's use-list<br class="gmail_msg">>> will local to the GlobalValue's Module. Any ConstantVector,<br class="gmail_msg">>> ConstantArray, or ConstantStruct that points at a GlobalValue will also<br class="gmail_msg">>> be local to the same Module. In these cases, we also need RAUW<br class="gmail_msg">>> support.)<br class="gmail_msg">>><br class="gmail_msg">>> Besides catching bugs, removing use-lists from ConstantData will<br class="gmail_msg">>> guarantee that the compiler output *does not* depend on the use-list<br class="gmail_msg">>> order of something like i32 0.<br class="gmail_msg">>><br class="gmail_msg">>> Finally, this should dramatically reduce the overhead of serializing<br class="gmail_msg">>> use-list order in bitcode. We will no longer track the arbitrary<br class="gmail_msg">>> order of references to things like i32 0 and null.<br class="gmail_msg">>><br class="gmail_msg">>> What's left?<br class="gmail_msg">>> ============<br class="gmail_msg">>><br class="gmail_msg">>> I just filed PR30513 to track remaining work.<br class="gmail_msg">>><br class="gmail_msg">>> 1. Avoid the remaining uses of ConstantData use-lists. There are only<br class="gmail_msg">>> a couple of cases left, highlighted in the WIP HACK patches attached<br class="gmail_msg">>> below (0001 and 0002).<br class="gmail_msg">>><br class="gmail_msg">>> 2. Remove the use-lists! Replace them with ref-counts to keep most of<br class="gmail_msg">>> the use-list API functional (and minimize the size of the change).<br class="gmail_msg">>> See the WIP patch below (0003).<br class="gmail_msg">>><br class="gmail_msg">>> 3. (Optional) Remove use-lists from other non-GlobalValue Constants<br class="gmail_msg">>> that do not reference any GlobalValues. This would require some<br class="gmail_msg">>> sort of magic in, e.g., ConstantVector to conditionally have a<br class="gmail_msg">>> use-list.<br class="gmail_msg">><br class="gmail_msg">> I wonder if the constant class hierarchy should not be revisited in light of this?<br class="gmail_msg">> For instance you identified that some are local to a module while others are “context-wide”.<br class="gmail_msg">><br class="gmail_msg">> I haven’t given too much thoughts about this, but I'm curious if you did?<br class="gmail_msg"><br class="gmail_msg">You mean something like PureConstantVector (which cannot transitively reference GlobalValue) vs ConstantVectorWithGlobalRef (which can/must transitively reference GlobalValue), right? (And also for ConstantStruct, ConstantArray, and ConstantExpr, etc.)<br class="gmail_msg"><br class="gmail_msg">I hadn't considered that, and it seems worth thinking about. I'm unsure whether using isa<>() would really be cleaner than using Value::hasUseList; and it would certainly be intrusive. Do you see any concrete benefits?<br class="gmail_msg"><br class="gmail_msg">One possible long-term thing (after #4)... we could add ConstantDataUser (vs. User), which can only reference a Constant-with-no-GlobalValue, and has operands the size of a pointer. Obviously nice to save on operand-size, but I'm not convinced it would save sufficient memory to be worthwhile: IIRC, Instruction accounts for most instances of User.<br class="gmail_msg"></blockquote><div class=""><br class=""></div><div class="">FWIW, I still would find this interesting, at least for conceptual improvements in the IR.</div><div class=""><br class=""></div><div class="">I'd really like it if we could separate the ideas of true constants (that are inherently foldable and don't need use lists) and things that transitively reference globals.</div><div class=""><br class=""></div><div class="">Recently I've been thinking that the split which might make sense would be to have Constants which have no use-lists and must be manifest (no references to globals, and GlobalExprs which have use lists and can reference Globals (as wall as Constants).</div></div></div></div></blockquote><div><br class=""></div><div>Note this naming somewhat implies GlobalVector/GlobalArray/GlobalStruct. Not sure those are bad/wrong names, but they sound a little like a GlobalObject to me.</div><div><br class=""></div><div>Unless.... would we actually need all three of GlobalArray + ConstantArray + ConstantDataArray? Or would we only have GlobalArray and ConstantDataArray, because of constant-folding?</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: 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"><div class="">This might in turn allow us to consider better models for things like expanding constantexprs that don't fit any relocations on the platform.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Personally, I'd probably stop after your #2 unless/until we do something to re-think the class hierarchy here.</div></div></div></div></blockquote><br class=""></div><div>Yup, makes sense to me. Thanks for the input!</div></body></html>