<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Apr 30, 2018, at 4:26 PM, David Zarzycki <<a href="mailto:dave@znu.io" class="">dave@znu.io</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="">On Apr 30, 2018, at 15:05, John McCall via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><div class=""><div style="" class=""><blockquote type="cite" style="font-family: Menlo-Regular; font-size: 11px; 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-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">On Apr 30, 2018, at 2:58 PM, Sanjoy Das <<a href="mailto:sanjoy@playingwithpointers.com" class="">sanjoy@playingwithpointers.com</a>> wrote:<br class="">On Mon, Apr 30, 2018 at 11:14 AM, John McCall <<a href="mailto:rjmccall@apple.com" class="">rjmccall@apple.com</a>> wrote:<br class=""><blockquote type="cite" class="">The LLVM address space design has pushed well beyond the sensible boundaries<br class="">of less-is-more and really needs some concerted effort to actually define the expected<br class="">properties of different address spaces instead of a dozen different engineers applying<br class="">a "don't do this optimization if the pointer is in a non-zero address space" rule to the<br class="">optimizer with a shotgun.<br class=""><br class="">In fact, if we'd already done that, we wouldn't need any sort of address-space hack<br class="">to support this request. We'd just need a very simple audit of the places that check<br class="">the "are dereferences of the zero address undefined behavior" bit to make sure that<br class="">they honor it even in address space 0. But instead that audit will be confused by a<br class="">thousand places that just bail out for non-zero address spaces without further<br class="">explanation.<br class=""></blockquote><br class="">I agree. The pattern of bailing out if AddrSpace != 0 is unfortunate.<br class=""><br class="">We also need to cap the amount of extra semantics that can be put on address<br class="">spaces. For instance, we should probably never support trapping semantics on<br class="">loads/stores, even via address spaces.<br class=""></blockquote><br style="caret-color: rgb(0, 0, 0); font-family: Menlo-Regular; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); font-family: Menlo-Regular; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">I would say instead that address spaces are not the right way to support trapping</span><br style="caret-color: rgb(0, 0, 0); font-family: Menlo-Regular; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); font-family: Menlo-Regular; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">semantics on loads/stores.</span></div></div></blockquote><br class=""></div><div class="">Hi John,</div><div class=""><br class=""></div><div class="">I might be misunderstanding the thread here, but are there architectures other than Intel that support alternative address spaces?</div></div></div></blockquote><div><br class=""></div><div>Yes. They're commonplace in GPUs and also used in some distributed system architectures. Also, any x32-like ABI can support a short/long pointer distinction.</div><div><br class=""></div><div>John.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">I’m asking because x86_64 dropped support for having the code, data, stack, and “extra” segments be different from each other; and the only two remaining segment registers, “FS” and “GS”, are only used in practice to alias the current address space. In fact, *user-space* instructions were later added to read/write the FS/GS segment bases, thus embracing the fact that these segment registers are used in practice to alias the current address space.[1]</div><div class=""><br class=""></div><div class="">I don’t think LLVM needs to model FS/GS as anything other than aliases into the existing address space.</div><div class=""><br class=""></div><div class="">Dave</div><div class=""><br class=""></div><div class="">[1] – Note, these new user-space instructions require permission from the kernel to execute, and popular kernels haven’t enabled them. Last I knew, the Linux folks seem receptive to the idea of enabling these instructions, but the conversation keeps stalling on implementation details.</div></div></div></blockquote></div><br class=""></body></html>