<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<p style="font-family:Arial;font-size:10pt;color:#0000FF;margin:5pt;" align="Left">
[AMD Official Use Only]<br>
</p>
<br>
<div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
This bitcast is intended to be used by transform passes when its been decided that the resultant operation is no-op( Like in GVN case of inserting ptrtoint/inttoptr ).</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
When reinterpretation of bits is not supported by target, the resultant value is poison.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Regards,</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Chaitanya.</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Serge Pavlov <sepavloff@gmail.com><br>
<b>Sent:</b> 25 November 2021 23:40<br>
<b>To:</b> Sankisa, Krishna (Chaitanya) <Krishna.Sankisa@amd.com><br>
<b>Cc:</b> llvm-dev@lists.llvm.org <llvm-dev@lists.llvm.org><br>
<b>Subject:</b> Re: [llvm-dev] [RFC] : LLVM IR should allow bitcast between address spaces with the same size</font>
<div> </div>
</div>
<div>[CAUTION: External Email]
<div>
<div dir="ltr">There are targets, where address spaces are separate, that is the same value addresses different entities in different spaces. Size of the pointers in these spaces can be the same. Cast between such pointers is invalid operation.
<div><br>
</div>
<div>
<div>
<div dir="ltr" class="x_gmail_signature">Thanks,<br>
--Serge<br>
</div>
</div>
<br>
</div>
</div>
<br>
<div class="x_gmail_quote">
<div dir="ltr" class="x_gmail_attr">On Thu, Nov 25, 2021 at 5:50 PM Sankisa, Krishna (Chaitanya) via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
</div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div dir="ltr">
<p align="Left" style="font-family:Arial; font-size:10pt; color:rgb(0,0,255); margin:5pt">
[AMD Official Use Only]<br>
</p>
<br>
<div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
TL;DR
<div>=====</div>
<div><br>
</div>
<div>We propose the following change to LLVM IR:</div>
<div>- Allow bitcast to support no-op pointer cast between pointers from different address spaces.</div>
<div>- This bitcast is valid if the bit widths queried for addressspaces from datalayout match.</div>
<div>- Overload CastIsValid call with datalayout argument to check validity of cast.</div>
<div>- Update CastIsValid to allow bitcast between vector of pointers from different address spaces if total bit widths match.</div>
<div>- GVN pass introduces ptrtoint/inttoptr for load which reinterprets bits from previous store.
</div>
<div>  Instead use a no-op bitcast of ptrs from different address spaces.</div>
<div><br>
</div>
<div><br>
</div>
<div>Motivation</div>
<div>==========</div>
<div><br>
</div>
<div>When addrspacecast was introduced, abilty to do no-op pointer bitcast from different address spaces has been removed.</div>
<div>Pointer sizes are always known from DataLayout which is now made mandatory in LLVM IR.
</div>
<div>So, Bitcast can be analysed to be no-op cast by matching the pointer sizes from DataLayout.</div>
<div><br>
</div>
<div>Since there is no other way to do no-op reinterpret of bits, in some cases GVN pass introduces a ptrtoint/inttoptr pair.</div>
<div>After proper analysis, that a no-op bitcast can be done is concluded, then a bitcast can be introduced.</div>
<div>Usage of no-op pointer bitcast between addrspaces can be restricted to be used only by IR Transform passes but not by frontend.</div>
<div><br>
</div>
<div>For example consider the below IR:</div>
<div>GVN pass has discovered a reinterpretation of bits via a store followed by a load.</div>
<div><br>
</div>
<div>%struct.S.coerce = type { i32 addrspace(1)* }</div>
<div>%s.sroa.0 = alloca i32*, align 8, addrspace(5)</div>
<div>%0 = extractvalue %struct.S.coerce %s.coerce, 0</div>
<div>%1 = bitcast i32* addrspace(5)* %s.sroa.0 to i32 addrspace(1)* addrspace(5)*</div>
<div>%2 = addrspacecast i32 addrspace(1)* addrspace(5)* %1 to i32 addrspace(1)</div>
<div>store i32 addrspace(1)* %0, i32 addrspace(1) %2, align 8</div>
<div><br>
</div>
<div>%3 = load i32*, i32* addrspace(5)* %s.sroa.0, align 8, !tbaa !2</div>
<div><br>
</div>
<div>;GVN pass currently introduces no-op ptrotoint/inttoptr for load.</div>
<div>%3 = ptrtoint i32 addrspace(1)* %0 to i64</div>
<div>%4 = inttoptr i64 %3 to i32*</div>
<div><br>
</div>
<div>;If bitcast of pointers from different address is allowed, load can be replaced with no-op bitcast</div>
<div>%3 = bitcast i32 addrspace(1)* %0 to i32*</div>
<div><br>
</div>
<div><br>
</div>
<div>Implementation</div>
<div>==============</div>
<div><br>
</div>
<div>1. There are certain cases where standalone instructions are created without linking them to basicblock/function or module.
</div>
<div>   In such cases DataLayout is not accessible by querying the module. To check validity of bitcast datalayout is mandatory.</div>
<div>   So CastInst::CastIsValid, CastInst::create etc have been overloaded to take DataLayout as argument.</div>
<div><br>
</div>
<div>   static bool castIsValid(Instruction::CastOps op, Value *S, Type *DstTy,</div>
<div>                           const DataLayout &DL);</div>
<div><br>
</div>
<div>   static CastInst *Create(</div>
<div>      Instruction::CastOps,   ///< The opcode of the cast instruction</div>
<div>      Value *S,               ///< The value to be casted (operand 0)</div>
<div>      Type *Ty,               ///< The type to which cast should be made</div>
<div>      const DataLayout &DL,   ///< DataLayout to check validity of bitcast</div>
<div>      const Twine &Name = "", ///< Name for the instruction</div>
<div>      Instruction *InsertBefore = nullptr ///< Place to insert the instruction</div>
<div>   );</div>
<div><br>
</div>
<div>2. Verifier has been updated to check for validity of bitcast using datalayout.</div>
<div><br>
</div>
<div>3. GVN pass has been updated to use bitcast for a load instead of emitting ptrtoint/<span style="background-color:rgb(255,255,255); display:inline"><span> </span>inttoptr.</span></div>
<div>   llvm/lib/Transforms/Utils/VNCoercion.cpp</div>
<div><br>
</div>
<div>Review link: <a href="https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Freviews.llvm.org%2FD114533&data=04%7C01%7CKrishna.Sankisa%40amd.com%7C91a2205fc5cd40f6e48d08d9b03eea61%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637734607278960617%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=E2akTQbj%2FTDNihgs1kJ5bsNE0R6zWg7uOF6%2FFnJ70Jo%3D&reserved=0" originalsrc="https://reviews.llvm.org/D114533" shash="e87sj9vHwJz8qtPGwEQF1hhY5kP+BgoAqFgJ3Ynw5vOZySycwLD9YsI1WO+ExPAKaEU/+FKfuuYetHgVjg84K9HJMQ3H1JEj7NFJWCkskHxkOKW/2HbXhIJ44RCKifTdrzGjYr0qCSZNOFtQ4tQRe8D8au93irxlv6LSirOrC2U=" id="x_gmail-m_-2075249392132057024LPlnkOWALinkPreview" target="_blank">
https://reviews.llvm.org/D114533</a> </div>
<div>
<div id="x_gmail-m_-2075249392132057024LPBorder_GTaHR0cHM6Ly9yZXZpZXdzLmxsdm0ub3JnL0QxMTQ1MzM." style="width:100%; margin-top:16px; margin-bottom:16px; max-width:800px; min-width:424px">
<table id="x_gmail-m_-2075249392132057024LPContainer988765" role="presentation" style="padding:12px 36px 12px 12px; width:100%; border-width:1px; border-style:solid; border-color:rgb(200,200,200); border-radius:2px">
<tbody>
<tr valign="top" style="border-spacing:0px">
<td style="width:100%">
<div id="x_gmail-m_-2075249392132057024LPTitle988765" style="font-size:21px; font-weight:300; margin-right:8px; font-family:wf_segoe-ui_light,"Segoe UI Light","Segoe WP Light","Segoe UI","Segoe WP",Tahoma,Arial,sans-serif; margin-bottom:12px">
<a id="x_gmail-m_-2075249392132057024LPUrlAnchor988765" href="https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Freviews.llvm.org%2FD114533&data=04%7C01%7CKrishna.Sankisa%40amd.com%7C91a2205fc5cd40f6e48d08d9b03eea61%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637734607278970611%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=DEZgHHVYC2fQTw5VFLB6A9Dx5dz4XmHTHD3lLC%2BPyCQ%3D&reserved=0" originalsrc="https://reviews.llvm.org/D114533" shash="svp22dPJeCIJ4iHv9QVHmN5lcLmWFawTqigHvKHbyOyKiUpEyrPK5eo2KK2UmW2BQx9UQjt0J8XMKj+35T9Ja1we7BJukATvw6g8JRP5UeA8F20W+2/Jl8n/lEa8SPH3xk0pxWnCL7LzDKjnYe7rXsHVVZSLtI3qns1SAgKNMgM=" target="_blank" style="text-decoration:none">⚙
 D114533 LLVM IR should allow bitcast between address spaces with the same size.</a></div>
<div id="x_gmail-m_-2075249392132057024LPDescription988765" style="font-size:14px; max-height:100px; color:rgb(102,102,102); font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif; margin-bottom:12px; margin-right:8px; overflow:hidden">
LLVM IR should allow bitcast between address spaces with the same size.</div>
<div id="x_gmail-m_-2075249392132057024LPMetadata988765" style="font-size:14px; font-weight:400; color:rgb(166,166,166); font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif">
<a href="https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Freviews.llvm.org%2F&data=04%7C01%7CKrishna.Sankisa%40amd.com%7C91a2205fc5cd40f6e48d08d9b03eea61%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637734607278970611%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=OY8kK7T4mg%2BpWRqV%2FMfDsx7vfJ3aW5da0pi4Yt0BeWI%3D&reserved=0" originalsrc="http://reviews.llvm.org/" shash="kZL4r6Jy8he9z9EEb3SHhubYoAdc7ZjMfr4klJJCH2pYjzfitbct9hVW1kXltBSLRhrrpreaUdHrhTAQ9nw9afRRtKq1hfCAlaXjNqaQjKdCY6LOwfChDBvvJHmlDENOMsud1oLU4/CCeIFu8nVn4UtH3Mtg6G3qsQUfw6YdSnw=" target="_blank">reviews.llvm.org</a></div>
</td>
</tr>
</tbody>
</table>
</div>
</div>
<div><br>
</div>
<div>Regards,</div>
Chaitanya<br>
</div>
</div>
</div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fllvm-dev&data=04%7C01%7CKrishna.Sankisa%40amd.com%7C91a2205fc5cd40f6e48d08d9b03eea61%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637734607278980606%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=gbTdDj%2FC9%2Bs7FfHV0cPKLl8Knv%2F9y%2FExlP%2Fquw4Bdgg%3D&reserved=0" originalsrc="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" shash="iIYjQxBZu2wY2dwxpYtBiGxWXxXSEpEPT0cUKbHe+WN0qD3W0Jbs1AU0Vp1wkT5mMrcM4qvCMUQA6hZXxXitULxn0BwU9/MiuzMSwKVg9DEMo+DaF/U/qz4TYvSBrt32a38qNDCMHKLPFz3YBJafbNarNxztpuIDfHCipk2tzYE=" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote>
</div>
</div>
</div>
</div>
</body>
</html>