<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 Aug 26, 2015, at 8:24 PM, Matt Arsenault via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type" class="">
<div bgcolor="#FFFFFF" text="#000000" class="">
<div class="moz-cite-prefix">On 08/26/2015 07:02 PM, Chandler
Carruth via llvm-dev wrote:<br class="">
</div>
<blockquote cite="mid:CAGCO0KipUBD3WYPJFmE5HOyE6KuGcJU0RMD=cbJyEfk_w-_yjg@mail.gmail.com" type="cite" class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
<div dir="ltr" class="">
<div class="gmail_quote"><br class="">
<div class="">Without a better understanding of both the motivation and
the resulting consequences such as what I've outlined in my
questions above, it is very hard for me to feel comfortable
with this kind of change.</div>
<br class="">
</div>
</div>
</blockquote>
For my use case, some of the assumptions about addrspace(0) don't
make any sense, so having the option of not using it for stack
allocations would avoid some special case problems. For example,
it's assumed that 0 is the address space of code, and stack, but for
us these are unrelated concepts and have different pointer sizes.
The assumption that 0 is not a valid pointer value is also
incorrect, since</div></div></blockquote><div><br class=""></div><div>Just sent an email about this assumption in another thread ("<font face="Helvetica Neue" class="">Globals in non-zero address spaces might be null” on llvm-commits):</font></div><div><font face="Helvetica Neue" class=""><br class=""></font></div><div><font face="Helvetica Neue" class="">"</font>Isn’t something that should be target configurable? Any reason for not having TTI with a default behavior which would be the current one, but that targets could customize?"</div><div class=""><br class=""></div><div class="">But it also seems like we’re patching little hacks here and there to make the address spaces usable, because they were not part of LLVM at the beginning and we don’t have a real plan to make them first class (maybe it was considered and the conclusion was that the effort wasn’t worth it?).</div><div class=""><br class=""></div><div class="">— </div><div class="">Mehdi</div><div class=""><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div bgcolor="#FFFFFF" text="#000000" class=""> we want stack pointers to be a 32-bit offset and 0
is valid. For this use case, all allocas should be created with the
same address space, so it could be part of the datalayout. In the
backend, we have 3 different memory types we would like to place
stack objects, so being able to mark these with different address
space IDs would also be helpful (although we wouldn't care about the
middle end deciding that some allocas should be in a different
address space from a single one specified by the data layout)<br class="">
</div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=v-ruWq0KCv2O3thJZiK6naxuXK8mQHZUmGq5FBtAmZ4&m=hcouPrGSD1d8V3vg5Qr9CLgWQkGQ8kQPDsvXT48FGJU&s=k-ANzx_x7MeKLGQ1U-zGABf1JkLU5Ho_3-XQF-TUrbs&e= <br class=""></div></blockquote></div><br class=""></body></html>