<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Looks like I made my point in an accidentally really confusing
way. Let me try again w/Matt's correction in mind.</p>
<p>I want to make sure that the middle end optimizer code is *driven
by the data layout*. I am not trying to express an opinion on how
that data layout is populated (frontend, backedge, black magic,
what have you). I just want to make sure that we don't end with
the middle end having to know that address space "56" has special
meaning beyond what is encoded in the data layout. To say it
differently, I want to make sure that a different frontend
targeting a different backend is not effected by the proposed
changes.<br>
</p>
<p>Philip<br>
</p>
<div class="moz-cite-prefix">On 7/31/19 9:26 AM, Arsenault, Matthew
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:BYAPR12MB2728B21FF16393A68EC392A7E2DF0@BYAPR12MB2728.namprd12.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<style id="ms-outlook-ios-style" type="text/css">html {
background-color: transparent !important;
}
body {
background-color: transparent !important;
color: #333;
line-height: 150%;
font-family: "-apple-system", "HelveticaNeue";
margin: 0;
}
.ms-outlook-ios-reference-expand {
display: block;
color: #999;
padding: 20px 0px;
text-decoration: none;
}
.ms-outlook-ios-availability-container {
max-width: 500px;
margin: auto;
padding: 12px 15px 15px 15px;
border: 1px solid #C7E0F4;
border-radius: 4px;
}
.ms-outlook-ios-availability-container > .ms-outlook-ios-availability-delete-button {
width: 25px;
height: 25px;
right: -12px;
top: -12px;
background-image: url("data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEsAAABLCAYAAAA4TnrqAAAAAXNSR0IArs4c6QAACxpJREFUeAHlnFuMXlUVx/fcOzNtp0ynF0U7hWKrEmKLosZEjUZ9MgZIQBNC0uAtJr745oOJIT74xgskJkQbAlQNJmBMfNDEG0YjEC7GIBQZ6IAI005L79O5+/+dfut0f5dzzt7nu8w37UrWt893zt5rr/U/e6+zL+ucHrcGtLq62q9qd4gnxTeKb6kcc267eEI8Kz4mnhFPi58Rv1g5nunp6VnS8ZVHAqdHPCk+KP6zuBWEHORNinvWNWoYIN4q/o74mLidhHzqob71AxzKij8g/p14LYh6qb97QUM58T7x38TdQOiBPt0FmhQaEf9M3I2EXiNr7tOkBK3pVvGCuJsJ/dCzqVbWWxZxVTygso+InxBz3M2Efuj5SEXvUrqWQloV7lRtT4vfX6rWtS30pqr/uMZp78SqEQ2WgPqQKvmnuKWtaWnFuaWVVbciXl51rk+a9fb2uP6EY80qzL+oHB8RYC8V5vQyRIEloD6tsk965UsdAsyZ+WV35uKyOz+/4uZ0YgmEMqhfyA3397rRoV63eUOf2zzUJxAzMsed/owA+2tokWCwmgVKDcadvLDsZs8vutMXV5zkhepYl08GurENvW5idMCNj/Q5Nb5mKBiwoGoqXe/fZTQCkmNnl9x/Ty+4xZzW0yeLB9WC6Hp0QbLSJRd0sAzSGTSgzO8bG3TbN/W7IGMay/lwSJcslC+gcOZviKN9FC3pjVML7uKi+l0NDakf0Sq2DPe5kYFeh9FZBMgXJOPU3HLSOufpxzW0QTJ2bRlMZNZcCvmLD9slwHKdfraGKi2gAGhKHPXUm1tcdVMn5t05+SWfMGjbaL+7RiABUFkCuHd1I46fX6q7ERvlz/ZsHXLDA7mmNaqap+QeAQZwDSlTooDiGuOouxqWzDjJ3X91dj55slkWWs216io7musqJi5N6Zwz6uJv1XRxnqA3TAwlrTbNHHZwWNnuFmAN+30eWLeqIAO5YHr7zKK63WLqvPFDOzcNuPeODSR+KFhQZEb82/9OL7p3zi6m/k0Gq1sOuPdsjvYet6nsrxup0BAstSrmUqfEQTVxG147seCOn7vcguly+7ZtKNMdGukZdI7uf+T4xaquuW3jgLt+62CM88eILQLsQm2ldY6j0v3uV8YgoBBYC9SYxkI37RzuKFDogZ+iXuo34gaiXwRh9/0VHKqK1bUsZdqnHC9X5cr5Q9ebfveyMnS73eODOSU6c+noyYWkW1ptk9cMxnbJD6p1HbHypFUtq4LmIT9D3jHOHB9l1C1AoQ83DH2M0BN9I+hQbeuqAkuCbhB/KkQg/oGnngQm2Wn63dCifN3Rx7okeqIvegcSOIBHSilYFRQfSK8UHDCOYuIL4cz3ypl3I6EX+kHoi94R9IDfulKwJGBc/KUQQYzMbcDJ8ICnXp8vKURIh/Kg1yX9Lrln9Eb/QAIPcEnIN/FOO5mX0paYwhjhF0qMlq14R1L0q/ZfCy64MzqX4pKAVWlq94ZozqTY5nqMzBlwrgdCT5t/oj92BNK91hWtZe1SwW1FhXFRrB4YMYXJmf9atiRl7vvz52fd4/86GXNXq2TYH1oFch59blZ+yM7mp+iJvkbYkbOYYdlIwQV8HNvo0OcuJfm/9HVbZsFpMtcLpV++MOvuPvyfJPs9n9jufnrnnphRdVoNQH3jsSl36Cl29l0i466b2e0vJvRlSkTLwg7smRi9PIDNkQA+D1nL+nZOxvQSC3dGrB7oZgXTcOWJRAEMxeAIv5HUUwsUJ325SaacH/RFbyPfHjuXkR7kfK/6I03sk/zJI5o7K5xGLLPE0O03jTtalFEsYI2AQt5tkhtDvt7YE9iNPyuckpXsj4VUxnq5CiRZWbiLXY/irtL1ygCWBVSZroze6A9hD3YF0g5KMRcsJDYYjFjhLENlAGslUKazr79vl13PSCeDwWIXxoil4LIUA1g7gEJvX3/frgKbbgSsvQWZkstsVxnFdkErZ2kIYO0CCh18/X27TL+M9BbA2ppxMT0NTravx/TGBndphhIHeYCx8ukPDxDfzHCjVj30xw4Iu7x2UJvV/z/Jc3STf6bRsU2YucZ2VavIAEOejZtIn5w6qxWCubSaVgJlQrFjrjIqxT7W7QsocfCFYPn7dnZHCgQHXzbA/Kdku4FCOd8O374cxXfSDYdzMiSX/GlB8Q0oklZ/HcAevGOPdmSqVeE/5wvveb3IwjO+Hb59OQXHAatuYb62QAnBtSJy/+PMv/WrqaquRwFaGOe53mrCLxoFepZZwDpnhbLSEk02S1TdeXSudeZ+C4sd6ddVkHGC0AAjQgYC6BhgnS3K6Ds/Yg9aRY2Awne9/P39pUb6MXr5dvj25ciYAawTORmSS8wOCPuBcIa28pCcKPmTBRRTGKoqOzUKUQf9zaljV2X2U1R0GrBeKcrFdeKjjIg1aIbygLIOQdouwHz9fbsKbHoGBKr2xrIKEEhmFLmlZMWSNAQoK9AuwHz9fbus3oz0xWCwiLYziljwtyJJGgOUFWwHYL7+RBIGUtINnw3JjFCCLSDio/ymHFK+DFAmt5WAobfFd2GP3wisvox0plcFpnXxtYwM6WlcFqGJRsRHxdATWjO3KQ3lYqcwWYAhN4Z8vbHHc8V5Yv4inJbM+j/l5bRrxHAaEUhGawmlOe+hEAuU1dEIMF+u5ctK0Re9jXx77FxG+hDnqZ8Vw68p+QXHecQ47vm3LqRDh93jQ9qPu7ymnVeWmT2bFqyZs8ScVJxXIOcaRtOiAOqr+ydCW4c2K5bc0ZOXdqRZeThw7Uho8O5ueqCBtVH1E085mqNjcolIu9e9CverwsoQrKjoml5nLP2Cd6Ov040O3J06LsV3CKzVpBvqgClPUJQfUcEWO8Dgjoi79UDoaYNp9MeOQPohQJHXfBbHD/NTRDRFooKN2IeLiEyxYh1N0e9t6WmE/hFu4DEr54P1B50MGs2z4E9UMMS0gdDE5eYG9YmsdvygF/rZxBm9/Q2Lgjp/r+vp4zYFS00Nc39cUDi9TPi0TUDZ4X1FCnUjoZfFZqAvekfQd60LUiYFqyLgUaXTlePchMgUwqclLMl3WvtvhCZ2E6EPekHoib4RET9/V7FXk8KVnyqwJJBByI/8DHnHbCkRPm2E/+oWwGpjStHT3wIznXPSe/xWRb4qsCoFDyl9qnJcmBBnTvi0EYC9NLN2PgwfRf3oYYR+kfHwYFDnvxs+FDRIPaDMfHQiaJbJc7U2vJvH85UWB98QLNnOqP4+Jd/jOJTW+g0Lhgf21MNHdeQNC8ARWAymcHIf5X8osVZ01b27AzgC7Holz4nH+B9KDAKvqrfCDBgB9hUdPy4O8l9WjpRFtqvmfUMzXIB9U8cP2v+YFOcf8yYr227sTLHCwexgXb3JasAIsB/oOHgMZuUsxXha2hX/jrQZ3CxgJoe1LSLuCCSLfvteczuWuANXOK3KrDT4ZXIEZA4dsqRXuuRPdD3ah2XJ5DwAEs1C16MV0hXpksznWgSMXz0j1vZ+18FqE2A4/YfFUU9JK7/G6Zuqv9QXQxpNdwpt0YDvN8p0szhoZ6hQYOcyHFZVvDSe+5Z9W9RRCxsU3ydeEnczteQrRy0BUSgdEP+jS9Hqju9n+UgLKL6l9XXx0S4BrTu/zFYDWr/AOig+skagdf83/3zAOBZQvOryRTEf+Donbid15GuS0eOsWlBC/gsl9iW/LP6C+PPi68TN0usS8EcxH6z4be2qZrPCG5XvCFi1FQu8SZ1j6YdXYeC9YuLxiZyGicQltpuoRPiEmJVLwqPgZwXOtNKO0v8BzRAPSFNM7HEAAAAASUVORK5CYII=");
background-size: 25px 25px;
background-position: center;
}
#ms-outlook-ios-main-container {
margin: 0 0 0 0;
margin-top: 120;
padding: 8;
}
#ms-outlook-ios-content-container {
padding: 0;
padding-top: 12;
padding-bottom: 20;
}
.ms-outlook-ios-mention {
color: #333;
background-color: #f1f1f1;
border-radius: 4px;
padding: 0 2px 0 2px;
pointer-events: none;
text-decoration: none;
}
.ms-outlook-ios-mention-external {
color: #ba8f0d;
background-color: #fdf7e7;
}
.ms-outlook-ios-mention-external-clear-design {
color: #ba8f0d;
background-color: #f1f1f1;
}</style>
<style id="ms-outlook-ios-dark-mode-style" type="text/css">.ms-outlook-ios-dark-mode {
color: #E1E1E1 !important;
}
.ms-outlook-ios-dark-mode .ms-outlook-ios-reference-expand {
color: #777777 !important;
}
.ms-outlook-ios-dark-mode a:not([class]) {
color: #0086F0;
}
.ms-outlook-ios-dark-mode font[color="#000000"] {
color: #E1E1E1 !important;
}
.ms-outlook-ios-dark-mode .ms-outlook-ios-availability-container {
border-color: #0086F0 !important;
}
.ms-outlook-ios-dark-mode .ms-outlook-ios-availability-container .ms-outlook-ios-availability-timeslot-container {
background-color: rgba(0, 120, 215, 0.2) !important;
}
.ms-outlook-ios-dark-mode .ms-outlook-ios-availability-container .ms-outlook-ios-availability-border {
border-top: 1px solid #0086F0 !important;
}
.ms-outlook-ios-dark-mode .ms-outlook-ios-availability-container > .ms-outlook-ios-availability-delete-button {
filter: invert(100%) grayscale(100%) brightness(90%) sepia(100%) hue-rotate(-180deg) saturate(700%) contrast(0.8);
}
.ms-outlook-ios-dark-mode .ms-outlook-ios-mention {
color: #A8A8AC !important;
background-color: #292929 !important;
}</style>
<meta name="viewport" content="width=device-width,
user-scalable=no, initial-scale=1.0, minimum-scale=1.0,
maximum-scale=1.0">
<div style="direction: ltr;">
<div>The datalayout itself is currently not considered a point
of configurability. It’s a static, backend/codegen defined
property. The target machine machine returns the datalayout
for the given triple and is the source of truth. The front end
is responsible for creating a module with an exactly matching
datalayout and is not free to customize the datalayout this
way. I’m not sure what there is to gain by avoiding putting
this information in the backend.</div>
<div><br>
</div>
<div style="direction: ltr;">-Matt</div>
<div><br>
</div>
</div>
<div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="dir="ltr""><font
style="font-size:11pt" face="Calibri, sans-serif"
color="#000000"><b>From:</b> llvm-dev
<a class="moz-txt-link-rfc2396E" href="mailto:llvm-dev-bounces@lists.llvm.org"><llvm-dev-bounces@lists.llvm.org></a> on behalf of Philip
Reames via llvm-dev <a class="moz-txt-link-rfc2396E" href="mailto:llvm-dev@lists.llvm.org"><llvm-dev@lists.llvm.org></a><br>
<b>Sent:</b> Wednesday, July 31, 2019 12:15<br>
<b>To:</b> Amy Huang; John Reagan<br>
<b>Cc:</b> llvm-dev<br>
<b>Subject:</b> Re: [llvm-dev] [RFC] Changing X86 data
layout for address spaces
<div> </div>
</font></div>
<div>
<p>Please review the properties of an address space which are
configurable via the data layout. For example, bitwidth is
one of those parameters. If that parameter space covers
your needs, then you do not need LLVM side support. <br>
</p>
<p>Philip<br>
</p>
<div class="moz-cite-prefix">On 7/30/19 2:59 PM, Amy Huang
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>Thanks for the info--</div>
<div>It seems like the way to do this is for clang to use
address spaces to represent different sized pointers in
the IR. If that's the case, then LLVM still has to know
about those specific address spaces. I don't see a clear
way to avoid adding knowledge of the address spaces to
LLVM.<br>
</div>
<div>I think that's the approach we'll go with, unless
there are more objections.</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sun, Jul 28, 2019 at
8:23 AM John Reagan <<a
href="mailto:john.reagan@vmssoftware.com"
target="_blank" moz-do-not-send="true">john.reagan@vmssoftware.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex; border-left:1px solid rgb(204,204,204);
padding-left:1ex">
That is basically what we do today to provide mixed
sized pointers with<br>
our legacy frontends. They generate IR to our old code
generator which<br>
has ADDR32 and ADDR64 datatypes. We use a 64-bit
address data layout<br>
and then typecast the 32-bit forms to/from the
underlying 64-bit<br>
addresses. I have been warned that such rampant
typecasting might<br>
interfere with certain optimizations or TBAA data. We
haven't<br>
investigated that yet. Since clang doesn't go through
our IR-to-IR<br>
converter, we'll have to teach clang to do the same.<br>
<br>
On 7/26/2019 6:35 PM, Amy Huang wrote:<br>
> *Clang* can assign whatever meaning to an AS
it wishes, and their<br>
> properties are configurable via data layout
configuration. <br>
> <br>
> <br>
> I think Clang checks that its data layout matches
the LLVM target data<br>
> layout, so I'm not sure how to go about
implementing the address spaces<br>
> as a change in Clang.<br>
> Thoughts?<br>
> <br>
> The other issue I was running into is how to do the
address space casts<br>
> in clang - my current thought was to lower the
address space casts in<br>
> LLVM to the sign extension / zero extension /
truncation.<br>
> <br>
> Thanks,<br>
> Amy<br>
> <br>
> On Mon, Jul 22, 2019 at 5:06 PM Philip Reames via
llvm-dev<br>
> <<a href="mailto:llvm-dev@lists.llvm.org"
target="_blank" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>
<mailto:<a href="mailto:llvm-dev@lists.llvm.org"
target="_blank" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>>>
wrote:<br>
> <br>
> Please don't bake in knowledge *in LLVM* of a
address space unless<br>
> there's a strong need. *Clang* can assign
whatever meaning to an AS<br>
> it wishes, and their properties are
configurable via data layout<br>
> configuration. <br>
> <br>
> The standards of review are much lower for a
Clang only change as it<br>
> can be revised arbitrarily without breaking
other uses of LLVM. <br>
> Building in first class knowledge to LLVM
itself is a breaking<br>
> change (potentially) for other frontends.<br>
> <br>
> Philip<br>
> <br>
> On 7/22/19 1:19 PM, Reid Kleckner via llvm-dev
wrote:<br>
>> Yes, the address spaces are intended to be
generally useful for<br>
>> other applications. Glad to hear that you
would find it useful. :)<br>
>><br>
>> For now we were only going to add them for
x86, but it should be<br>
>> easy to add such address spaces to other
targets.<br>
>><br>
>> On Mon, Jul 22, 2019 at 1:13 PM John Reagan
via llvm-dev<br>
>> <<a
href="mailto:llvm-dev@lists.llvm.org" target="_blank"
moz-do-not-send="true">llvm-dev@lists.llvm.org</a>
<mailto:<a href="mailto:llvm-dev@lists.llvm.org"
target="_blank" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>>>
wrote:<br>
>><br>
>> Amy, when you say "implement MSVC's
extensions", is that<br>
>> MSVC/LLVM or<br>
>> are you going to add these to clang?
OpenVMS has dual-sized<br>
>> pointers as<br>
>> well and want to see them in clang.
One of my engineers<br>
>> noticed that<br>
>> address space 4 was a 32-bit pointer
address space (or at<br>
>> least it used<br>
>> to be). I haven't seen any formal
discussion of that over in<br>
>> the cfe<br>
>> dev list. I'm happy to help out where
we can.<br>
>><br>
>> John<br>
>><br>
>>
_______________________________________________<br>
>> LLVM Developers mailing list<br>
>> <a
href="mailto:llvm-dev@lists.llvm.org" target="_blank"
moz-do-not-send="true">llvm-dev@lists.llvm.org</a>
<mailto:<a href="mailto:llvm-dev@lists.llvm.org"
target="_blank" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>><br>
>> <a
href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
>><br>
>><br>
>>
_______________________________________________<br>
>> LLVM Developers mailing list<br>
>> <a href="mailto:llvm-dev@lists.llvm.org"
target="_blank" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>
<mailto:<a href="mailto:llvm-dev@lists.llvm.org"
target="_blank" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>><br>
>> <a
href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org"
target="_blank" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>
<mailto:<a href="mailto:llvm-dev@lists.llvm.org"
target="_blank" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>><br>
> <a
href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
> <br>
<br>
</blockquote>
</div>
</blockquote>
</div>
</div>
</blockquote>
</body>
</html>