<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<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"
cite="mid:CAEb+zvfEDvig+Bc0xE_TmXyGjQBt69m8f-_khHDCoi3n9XcwDQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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>
</body>
</html>