<div dir="ltr"><div class="gmail_extra">On Tue, Jun 9, 2015 at 2:15 PM, Benyei, Guy <span dir="ltr"><<a href="mailto:guy.benyei@intel.com" target="_blank">guy.benyei@intel.com</a>></span> wrote:<br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Currently it seems to work fine, but as you said, this behavior is not exactly well defined. I would really expect any access to null - no matter in what address space - to be replaced with undef by some optimization pass.<br>
<span class=""><br>
"An integer constant other than zero or a pointer value returned from a function not defined within LLVM may be associated with address ranges allocated through mechanisms other than those provided by LLVM. Such ranges shall not overlap with any ranges of addresses allocated by mechanisms provided by LLVM."<br>
<br>
</span>Doesn't it mean, that the integer constant zero cannot be associated with any kind of memory, including non-default address space memory? Seems that address 0 still has to be handled somehow...<br></blockquote><div><br></div><div>I agree it's confusing, but for what it's worth, we already do things like loading from null in address space 257 and 256 to load from [gs:00] and [fs:00] on x86. It's supposed to work.</div></div></div></div>