<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (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:11.0pt;
font-family:"Calibri","sans-serif";}
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.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
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:#1F497D;}
.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;}
/* List Definitions */
@list l0
{mso-list-id:1664046365;
mso-list-type:hybrid;
mso-list-template-ids:-180951912 -1055078562 134807555 134807557 134807553 134807555 134807557 134807553 134807555 134807557;}
@list l0:level1
{mso-level-start-at:5;
mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;
mso-fareast-font-family:Calibri;
mso-bidi-font-family:"Times New Roman";}
@list l0:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></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"'> James Molloy [mailto:james.molloy@arm.com] <br><b>Sent:</b> Tuesday, October 04, 2011 12:06 AM<br><b>To:</b> Villmow, Micah; llvmdev@cs.uiuc.edu<br><b>Subject:</b> RE: [RFC] Proposal to make LLVM-IR endian agnostic<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'>Hi Micah,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'>I’m no core developer, but FWIW here are my thoughts:<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'>I’m general I think the patch is too OpenCL oriented</span><span lang=EN-GB style='color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><b><i><span lang=EN-GB style='color:#1F497D'>[Villmow, Micah] I agree, but this is mainly to solve a problem that is unique to OpenCL or related technologies(CUDA, DirectCompute, etc...).<o:p></o:p></span></i></b></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'>, and I have some niggling qualms about other parts. Specifically (comments inline):<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'><o:p> </o:p></span></p><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"'> llvmdev-bounces@cs.uiuc.edu [mailto:llvmdev-bounces@cs.uiuc.edu] <b>On Behalf Of </b>Villmow, Micah<br><b>Sent:</b> 03 October 2011 19:37<br><b>To:</b> llvmdev@cs.uiuc.edu<br><b>Subject:</b> [LLVMdev] [RFC] Proposal to make LLVM-IR endian agnostic<o:p></o:p></span></p></div></div><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal>One of the projects I am working on with others is to make LLVM-IR endian agnostic. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>So, I am sending out this proposal for feedback to the LLVM community. I’ve attached<o:p></o:p></p><p class=MsoNormal>pretty version of the proposal in PDF format and pasted a 80-column safe text version<o:p></o:p></p><p class=MsoNormal>below. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I’m looking forward to comments and feedback.<o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal>-------------------------------------------------------------------------------<o:p></o:p></p><p class=MsoNormal>PROBLEM QUESTION:<o:p></o:p></p><p class=MsoNormal>-------------------------------------------------------------------------------<o:p></o:p></p><p class=MsoNormal>How does a vendor simplify the compiler stack across multiple target devices<o:p></o:p></p><p class=MsoNormal>by removing endianess from the IR representation?<o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>This is not the question that your RFC answers. Your RFC answers a superset of just “represent endianness”.<o:p></o:p></span></p><p class=MsoNormal><b><i><span style='color:#1F497D'>[Villmow, Micah] Maybe I didn’t go into enough detail on how this proposal helps solve this problem. Currently<o:p></o:p></span></i></b></p><p class=MsoNormal><b><i><span style='color:#1F497D'>our compiler stack has to handle issues with big endian vs little endian devices along with 32bit vs 64bit devices(which is outside of this scope). If we want to have a common binary that we can use to compile for all devices, then we must store both versions of the LLVM-IR, increasing binary size and compile time. By abstracting away endianness representation, two of the 4 variations are unified, allowing the fat binary to store 1 LLVM-IR representation for each bitness instead of 2. So by abstracting endian assumptions out of the LLVM-IR, we are simplifying the compiler stack.</span></i></b><span style='color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal>-------------------------------------------------------------------------------<o:p></o:p></p><p class=MsoNormal>DEFINITIONS:<o:p></o:p></p><p class=MsoNormal>-------------------------------------------------------------------------------<o:p></o:p></p><p class=MsoNormal>Global Memory - Memory that is visible to all threads in a process/program, <o:p></o:p></p><p class=MsoNormal>e.g. video ram. This includes all read-only, write-only and read-write memories<o:p></o:p></p><p class=MsoNormal>on the system that are visible to all threads.<o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>What has this got to do with endianness?<o:p></o:p></span></p><p class=MsoNormal><b><i><span style='color:#1F497D'>[Villmow, Micah] This just defines the type of memory we are interested in. Other types of memory are not covered by this proposal, as they should not have this problem. For example, endianness agnostic load/stores to private memory are meaningless as it is only visible within a thread.</span></i></b><span style='color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal>-------------------------------------------------------------------------------<o:p></o:p></p><p class=MsoNormal>INTRINSICS:<o:p></o:p></p><p class=MsoNormal>-------------------------------------------------------------------------------<o:p></o:p></p><p class=MsoNormal>This proposal introduces new sets of intrinsics, two load intrinsics and two <o:p></o:p></p><p class=MsoNormal>store intrinsics. The sets are as follows:<o:p></o:p></p><p class=MsoNormal>declare <type> @llvm.portable.load.e.<type>(<type>* ptr, , i32 alignment, <o:p></o:p></p><p class=MsoNormal>i1 host, i1 atomic, i1 volatile, i1 nontemporal, i1 singlethread) <o:p></o:p></p><p class=MsoNormal>// little endian load<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>declare <type> @llvm.portable.load.E.<type>(<type>* ptr, i32 alignment, <o:p></o:p></p><p class=MsoNormal>i1 host, i1 atomic, i1 volatile, i1 nontemporal, i1 singlethread) <o:p></o:p></p><p class=MsoNormal>// big endian load<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>declare void @llvm.portable.store.e.<type>(<type> data, <type>* ptr, <o:p></o:p></p><p class=MsoNormal>i32 alignment, i1 host, i1 atomic, i1 volatilei1 nontemporal, <o:p></o:p></p><p class=MsoNormal>i1 singlethread) // little endian store<o:p></o:p></p><p class=MsoNormal>declare void @llvm.portable.store.E.<type>(<type> data, <type>* ptr, <o:p></o:p></p><p class=MsoNormal>i32 alignment, i1 host, i1 atomic, i1 volatile, i1 nontemporal, <o:p></o:p></p><p class=MsoNormal>i1 singlethread) // big endian store<o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='font-family:Symbol;color:#1F497D'><span style='mso-list:Ignore'>·<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='color:#1F497D'>I don’t like the ‘e’/’E’ representation. If there were only little or big endian loads throughout an IR file, it wouldn’t be obvious to me what the ‘e’/’E’ meant. It’s only seeing the two in tandem where it jumps out at me. I’d prefer the standard ‘le’/’be’.<o:p></o:p></span></p><p class=MsoNormal><b><i><span style='color:#1F497D'>[Villmow, Micah] Good suggestion, I was using the ‘e’ and ‘E’ as that is what is in the target data description from the LLVM spec.</span></i></b><span style='color:#1F497D'><o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='font-family:Symbol;color:#1F497D'><span style='mso-list:Ignore'>·<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='color:#1F497D'>You’ve put the OpenCL concept of “host” and “device” in a supposedly target-agnostic IR. Why should there be only one device? More importantly, why is host/device an attribute of the load or store as opposed to the pointer to load/store to? Does it semantically make sense to have both a host load and a device load of the same memory location in the same module?<o:p></o:p></span></p><p class=MsoNormal><b><i><span style='color:#1F497D'>[Villmow, Micah] Abstracting LLVM-IR so it can encode multiple device execution information from a single compilation unit is outside the scope of this proposal, hence the single device. The reason for not adding the attribute to the pointer is that each load/store can be unique in how to represent the endianness of the memory it points to. As for the third question, it isn’t a host load and a device load, it is a load with host endianess and a load with device endianess. A hypothetical example of this is a simple embedded co-processor attached to a general purpose processor(i.e. AMD’s Torrenza initiative) where the co-processor did not have hardware to convert between the endianness but memory spans across its own memory and the system memory. In this case, the compiler when it generates executables needs to make sure that loads from the host have memory ordered correctly for the device. Again, this is just an example, but a possible valid situation.</span></i></b><span style='color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal>-------------------------------------------------------------------------------<o:p></o:p></p><p class=MsoNormal>POINTER ATTRIBUTES:<o:p></o:p></p><p class=MsoNormal>-------------------------------------------------------------------------------<o:p></o:p></p><p class=MsoNormal>In OpenCL, a pointer can have attributes attached, and this information needs <o:p></o:p></p><p class=MsoNormal>to be encoded. In LLVM, the method of encoding extra information is via <o:p></o:p></p><p class=MsoNormal>metadata nodes and this is used so that the intrinsic do not need to be <o:p></o:p></p><p class=MsoNormal>modified to add extra information. One example of this is the endian(host) <o:p></o:p></p><p class=MsoNormal>attribute that can be attached to a pointer argument(see 6.10.3 of OpenCL <o:p></o:p></p><p class=MsoNormal>1.1 spec). This information can be encoded in a metadata node which is attached<o:p></o:p></p><p class=MsoNormal>to the intrinsic. An example encoding of this information is as follows:<o:p></o:p></p><p class=MsoNormal>!0 = metadata !{<o:p></o:p></p><p class=MsoNormal> i32, ;; Tag = <OpenCL version number> using the official OpenCL version macro<o:p></o:p></p><p class=MsoNormal> i1,;;Boolean value to specify that load is from host on true, device on false<o:p></o:p></p><p class=MsoNormal> metadata ;; List of attributes for this intrinsic instruction<o:p></o:p></p><p class=MsoNormal>}<o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Does this subsection add anything extra to the RFC? It talks about a format for metadata, but doesn’t appear to really add any suggestions or requirements for changing LLVM IR.<o:p></o:p></span></p><p class=MsoNormal><b><i><span style='color:#1F497D'>[Villmow, Micah] Your right, this is more on how to encode pointer information, this can be ignored.</span></i></b><span style='color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>If your intention was just to make the IR endian-agnostic, I don’t see why you wouldn’t just propose an extra attribute on the load/store instructions (load be %0, load le %0) instead of recreating all loads and stores in a new form and having to make all passes interact with them.<o:p></o:p></span></p><p class=MsoNormal><b><i><span style='color:#1F497D'>[Villmow, Micah] While we could go this route, this would make the endian agnostic IR compatible with LLVM-IR passes, which we don’t want to do, hence the use of intrinsic. Basically we want the endian agnostic IR to be mostly compatible with LLVM-IR, but will require a transformation pass to generate the correct load/store instructions for the device it will be generated for. I believe there was other reasons brought up by other contributors, but they escape me right now.</span></i></b><span style='color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>My general summary is that I think your suggestions take a “somewhat language-agnostic and somewhat target-agnostic” IR and turn it into a “somewhat language-dependent and more target-agnostic” IR, by embedding OpenCL specifics. I’m not sure I think that’s the best way to go.<o:p></o:p></span></p><p class=MsoNormal><b><i><span style='color:#1F497D'>[Villmow, Micah] That is correct, that is basically what we are attempting to do. We want a single IR that can be used across multiple devices for OpenCL. If this is something that can be modified to be less language dependent but keep the target agnostic and fulfill our needs, then we are willing to go down that path. This is why we believe involving the LLVM community is important so we can get this kind of feedback and hopefully agree on something that we can use, but other non-related projects can also use.</span></i></b><span style='color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Cheers,<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>James<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal>Thanks,<o:p></o:p></p><p class=MsoNormal>Micah Villmow<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p></div></div></body></html>