<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 30 April 2018 at 13:26, David Zarzycki via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><span class=""><br><div><br><blockquote type="cite"><div>On Apr 30, 2018, at 15:05, John McCall via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="m_5897983509838283408Apple-interchange-newline"><div><div><blockquote type="cite" style="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;text-decoration:none">On Apr 30, 2018, at 2:58 PM, Sanjoy Das <<a href="mailto:sanjoy@playingwithpointers.com" target="_blank">sanjoy@playingwithpointers.<wbr>com</a>> wrote:<br>On Mon, Apr 30, 2018 at 11:14 AM, John McCall <<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>> wrote:<br><blockquote type="cite">The LLVM address space design has pushed well beyond the sensible boundaries<br>of less-is-more and really needs some concerted effort to actually define the expected<br>properties of different address spaces instead of a dozen different engineers applying<br>a "don't do this optimization if the pointer is in a non-zero address space" rule to the<br>optimizer with a shotgun.<br><br>In fact, if we'd already done that, we wouldn't need any sort of address-space hack<br>to support this request.  We'd just need a very simple audit of the places that check<br>the "are dereferences of the zero address undefined behavior" bit to make sure that<br>they honor it even in address space 0.  But instead that audit will be confused by a<br>thousand places that just bail out for non-zero address spaces without further<br>explanation.<br></blockquote><br>I agree.  The pattern of bailing out if AddrSpace != 0 is unfortunate.<br><br>We also need to cap the amount of extra semantics that can be put on address<br>spaces.  For instance, we should probably never support trapping semantics on<br>loads/stores, even via address spaces.<br></blockquote><br style="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;text-decoration:none"><span style="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;text-decoration:none;float:none;display:inline!important">I would say instead that address spaces are not the right way to support trapping</span><br style="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;text-decoration:none"><span style="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;text-decoration:none;float:none;display:inline!important">semantics on loads/stores.</span></div></div></blockquote><br></div></span><div>Hi John,</div><div><br></div><div>I might be misunderstanding the thread here, but are there architectures other than Intel that support alternative address spaces?</div></div></blockquote><div><br></div><div>Yes, they're also used by GPU targets IIUC.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div>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><br></div><div>I don’t think LLVM needs to model FS/GS as anything other than aliases into the existing address space.</div><div><br></div><div>Dave</div><div><br></div><div>[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><br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div></div>