<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<div class="moz-cite-prefix">On 8/1/19 7:55 AM, De Azevedo Piovezan, Felipe via llvm-dev wrote:<br>
</div>
<blockquote type="cite" cite="mid:A18E5F8395391E4490DFB8586DAF6E6C026E70BC@ORSMSX104.amr.corp.intel.com">
<meta name="Generator" content="Microsoft Word 15 (filtered
        medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;
        color:black;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
        {mso-style-name:msonormal;
        mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;
        color:black;}
span.EmailStyle19
        {mso-style-type:personal;
        font-family:"Calibri",sans-serif;
        color:#1F497D;}
span.EmailStyle20
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">(forgot to llvm-dev…)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">Would it make sense to have TTI answer queries about whether two address spaces may alias? This is something I’ve asked myself in the past, but I’m not sure
 if it follows the philosophy of what TTI should do.</span></p>
</div>
</blockquote>
<p><br>
</p>
<p>We do have the ability for targets to add custom AA logic, and the AMDGPU backend uses this to add some address-space-based logic (see AMDGPUAliasAnalysis.cpp). If it were just adding the AS-based aliasing logic, then the ratio of boilerplate to actual logic
 would certainly speak in favor of a TTI hook. The AMDGPU AA also overrides pointsToConstantMemory and that seems more involved. Regardless, for now, we could have an X86AliasAnalysis and insert that into the pipeline.</p>
<p> -Hal<br>
</p>
<p><br>
</p>
<blockquote type="cite" cite="mid:A18E5F8395391E4490DFB8586DAF6E6C026E70BC@ORSMSX104.amr.corp.intel.com">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1
            1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><a name="_____replyseparator" moz-do-not-send="true"></a><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">
 llvm-dev <a class="moz-txt-link-rfc2396E" href="mailto:llvm-dev-bounces@lists.llvm.org">
<llvm-dev-bounces@lists.llvm.org></a> <b>On Behalf Of </b>Philip Reames via llvm-dev<br>
<b>Sent:</b> Wednesday, July 31, 2019 2:35 PM<br>
<b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:paul.robinson@sony.com">
paul.robinson@sony.com</a>; <a class="moz-txt-link-abbreviated" href="mailto:rnk@google.com">
rnk@google.com</a><br>
<b>Cc:</b> <a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">
llvm-dev@lists.llvm.org</a>; <a class="moz-txt-link-abbreviated" href="mailto:john.reagan@vmssoftware.com">
john.reagan@vmssoftware.com</a><br>
<b>Subject:</b> Re: [llvm-dev] [RFC] Changing X86 data layout for address spaces<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p>By default, nothing.  (i.e. everything across AS is mayalias)  But individual AS pairs may define alternate aliasing rules.  I don't know that we have a good way to make that plugable today though. 
<span style="font-size:11.0pt"><o:p></o:p></span></p>
<div>
<p class="MsoNormal">On 7/31/19 10:58 AM, <a href="mailto:paul.robinson@sony.com" moz-do-not-send="true">
paul.robinson@sony.com</a> wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I really hate to dip my toe in here, because it will only reveal my total ignorance, but….</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Do the "usual rules around addrspacecast" say when different address spaces can alias?  I remember somebody using address spaces to represent something like special
 off-to-the-side device memory, which obviously could never alias main memory, whereas other uses like the 32/64-bit thing will certainly have the 32-bit space aliasing (likely disjoint parts of) the 64-bit space, and the exact mapping of 32-to-64 might vary
 across OSes.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">--paulr</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<div style="border:none;border-left:solid blue
            1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF
                1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif"> llvm-dev [<a href="mailto:llvm-dev-bounces@lists.llvm.org" moz-do-not-send="true">mailto:llvm-dev-bounces@lists.llvm.org</a>]
<b>On Behalf Of </b>Reid Kleckner via llvm-dev<br>
<b>Sent:</b> Wednesday, July 31, 2019 1:44 PM<br>
<b>To:</b> Philip Reames<br>
<b>Cc:</b> llvm-dev; John Reagan<br>
<b>Subject:</b> Re: [llvm-dev] [RFC] Changing X86 data layout for address spaces</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">On Wed, Jul 31, 2019 at 10:29 AM Philip Reames via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>> wrote:<o:p></o:p></p>
</div>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC
                  1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<p>Looks like I made my point in an accidentally really confusing way.  Let me try again w/Matt's correction in mind.<o:p></o:p></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.<o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal">Got it. :) Yes, we have no intention of teaching the middle end about these address spaces. The usual rules around addrspacecast should apply.<o:p></o:p></p>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>