<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I meant extract_element instead of GEP (sorry for the confusion).</div><div class="">Sequence would be load i128, then bitcast to a vector and extract the first byte. </div><div class=""><br class=""></div><div class="">James explained me on IRC why it works :)</div><div class=""><br class=""></div><div class="">— </div><div class="">Mehdi</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Jan 12, 2016, at 8:53 AM, James Molloy <<a href="mailto:james@jamesmolloy.co.uk" class="">james@jamesmolloy.co.uk</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">i128 => <16 x i8> => GEP 0</div><div class="">i128 => <2 x i64> => GEP 0 => <8 x i8> => GEP 0</div><div class="">i128 => <2 x i64> => GEP 0 => <2 x i32> => GEP 0 => <4 x i8> => GEP 0</div><div class=""><br class=""></div><div class="">They all reference the same memory object from the same base address. If the result is loaded, the in-register contents will differ between them though (because there's a special "load a vector of this type" instruction (LD1)).</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, 12 Jan 2016 at 16:46 Mehdi Amini <<a href="mailto:mehdi.amini@apple.com" class="">mehdi.amini@apple.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">What happens when you cascade bitcast?<div class="">Are these sequences all equivalent at the IR level (i.e. do they reference the same byte from the original i128)? </div><div class=""><br class=""></div><div class=""><div class="">i128 => <16 x i8> => GEP 0</div></div><div class=""><div class="">i128 => <2 x i64> => GEP 0 => <8 x i8> => GEP 0</div></div><div class=""><div class="">i128 => <2 x i64> => GEP 0 => <2 x i32> => GEP 0 => <4 x i8> => GEP 0</div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">— </div><div class="">Mehdi</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 12, 2016, at 6:37 AM, Daniel Sanders via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class=""><div class=""><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class="">Thanks, I didn't know about that page. It's a much clearer explanation of why the backend choses the code it does. However, there's a bit I'm trying to explain that isn't covered on that page. I'm trying to explain why the seemingly contradictory statements at<a href="http://llvm.org/docs/LangRef.html#bitcast-to-instruction" style="color:purple;text-decoration:underline" target="_blank" class="">http://llvm.org/docs/LangRef.html#bitcast-to-instruction</a><span class=""> </span>don't actually contradict each other (even for big-endian NEON/MSA) while we're at the LLVM-IR level and why it's safe for LLVM-IR-level optimizations to use the zero-instruction definition despite the backend relying on the store/load definition. It boils down to both definitions being equivalent until we specialize to a target at which point the two definitions sometimes diverge. They diverge when the mapping of virtual bits to physical bits differs between LLVM-IR types.<u class=""></u><u class=""></u></span></div></div></div></blockquote></div></div></div><div style="word-wrap:break-word" class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></span></div><div style="border-style:none none none solid;border-left-color:blue;border-left-width:1.5pt;padding:0cm 0cm 0cm 4pt" class=""><div class=""><div style="border-style:solid none none;border-top-color:rgb(181,196,223);border-top-width:1pt;padding:3pt 0cm 0cm" class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><b class=""><span lang="EN-US" style="font-size:10pt;font-family:Tahoma,sans-serif" class="">From:</span></b><span lang="EN-US" style="font-size:10pt;font-family:Tahoma,sans-serif" class=""><span class=""> </span>James Molloy [<a href="mailto:james@jamesmolloy.co.uk" target="_blank" class="">mailto:james@jamesmolloy.co.uk</a>]<span class=""> </span><br class=""><b class="">Sent:</b><span class=""> </span>12 January 2016 13:56<br class=""><b class="">To:</b><span class=""> </span>Daniel Sanders; Quentin Colombet<br class=""><b class="">Cc:</b><span class=""> </span>llvm-dev<br class=""><b class="">Subject:</b><span class=""> </span>Re: [llvm-dev] [GlobalISel] A Proposal for global instruction selection<u class=""></u><u class=""></u></span></div></div></div><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><u class=""></u> <u class=""></u></div><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class="">Hi,<u class=""></u><u class=""></u></div><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><u class=""></u> <u class=""></u></div></div><div class=""><div class=""><div class=""><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class="">> I found this thinking quite difficult to explain. Does it make sense?</span><u class=""></u><u class=""></u></div><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class="">It might help to link to the documentation on why bitcasts are weird on big-endian NEON: <a href="http://llvm.org/docs/BigEndianNEON.html#bitconverts" style="color:purple;text-decoration:underline" target="_blank" class="">http://llvm.org/docs/BigEndianNEON.html#bitconverts</a></span><u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><u class=""></u> <u class=""></u></div></div><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class="">Cheers,</span><u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><u class=""></u> <u class=""></u></div></div><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class="">James</span><u class=""></u><u class=""></u></div></div></div></div></div></div></div><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><u class=""></u> <u class=""></u></div><div class=""><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class="">On Tue, 12 Jan 2016 at 13:23 Daniel Sanders via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" style="color:purple;text-decoration:underline" target="_blank" class="">llvm-dev@lists.llvm.org</a>> wrote:<u class=""></u><u class=""></u></div></div><blockquote style="border-style:none none none solid;border-left-color:rgb(204,204,204);border-left-width:1pt;padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm" class=""><div class=""><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class="">Hi,</span><u class=""></u><u class=""></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class=""> </span><u class=""></u><u class=""></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class="">I haven't found much time to look into the LLVM-IR-level optimizations yet so I'm not sure how they handle bitcasts. With that disclaimer in mind, I expect it's fine for the LLVM-IR level optimizations to handle them using either definition since they are equivalent at the LLVM-IR level. My thinking is that LLVM-IR is consistent about how virtual bits are assigned to types and that non-zero instruction nops arise when there is inconsistency.</span><u class=""></u><u class=""></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class=""> </span><u class=""></u><u class=""></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class="">At the LLVM-IR level, bits 0-127 of <4 x i32> map directly onto bits 0-127 of <2 x i64> using the identity map. It's therefore ok to interpret such bitcasts as zero-instruction no-ops. As far as I can tell, LLVM-IR has been defined such that the identity map can be used for bitcasts between all same-sized types, and also such that bitcasting between different-sized types is invalid.</span><u class=""></u><u class=""></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class=""> </span><u class=""></u><u class=""></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class="">Similarly, most targets have a single mapping of virtual bit numbers to physical bit numbers for each size that is applied consistently when mapping a type to memory. For example 32-bits map like so:</span><u class=""></u><u class=""></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif;text-indent:36pt" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class="">Little Endian Targets: virtual register bits {0..7,8..15,16..23,24..31} map to physical memory bits {0..7,8..15,16..23,24..31}</span><u class=""></u><u class=""></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif;text-indent:36pt" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class="">Big Endian Targets: virtual register bits {0..7,8..15,16..23,24..31} map to physical memory bits {24..31,16..23,8..15,0..7}</span><u class=""></u><u class=""></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class="">regardless of whether it's a float, or an i32. We therefore need zero instructions to re-map physical memory bits for one type onto another type.</span><u class=""></u><u class=""></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class=""> </span><u class=""></u><u class=""></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class="">The same idea holds for physical register classes. There's a single consistent mapping from physical memory bits to physical register bits that applies for all types that can be stored in that class. As long as this is the case the load/store and zero-instruction interpretation of bitcasts are equivalent.</span><u class=""></u><u class=""></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class="">In the case of big-endian MSA and NEON, there isn't a single consistent mapping from physical memory bits to physical register bits so the equivalence in the two definitions breaks down:</span><u class=""></u><u class=""></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class=""> i128: virtual register bits {0..31, 32..63, 64..95, 96...127} map to physical memory bits {96..127, 64..95, 32..63, 0..31}</span><u class=""></u><u class=""></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class=""> <4 x i32>: virtual register bits {0..31, 32..63, 64..95, 96...127} map to physical memory bits {0..31, 32..63, 64..95, 96..127}</span><u class=""></u><u class=""></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class=""> <2 x i64>: virtual register bits {0..31, 32..63, 64..95, 96...127} map to physical memory bits {32..63, 0..31, 96..127, 64..95}</span><u class=""></u><u class=""></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class="">with these inconsistent mappings we require instructions to bitcast between the types.</span><u class=""></u><u class=""></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class=""> </span><u class=""></u><u class=""></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class="">I found this thinking quite difficult to explain. Does it make sense?</span><u class=""></u><u class=""></u></div></div></div><div class=""><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class=""> </span><u class=""></u><u class=""></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class="">><span class=""> </span></span>I am fine with treating bit casts as equivalent store/load pairs in GISel, I just want to be sure we do not have a semantic gap between the LLVM-IR and the backend if we do.<u class=""></u><u class=""></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class=""> </span><u class=""></u><u class=""></u></div></div></div><div class=""><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class="">I think a gap would arise from not having a GISel equivalent to ISD::BITCAST (gBITCAST?) available when it's necessary for correctness. However, I agree that GISel should delete bitcasts for the common case where the store/load and zero-instruction definitions are equivalent.</span><u class=""></u><u class=""></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class=""> </span><u class=""></u><u class=""></u></div><div style="border-style:none none none solid;border-left-color:blue;border-left-width:1.5pt;padding:0cm 0cm 0cm 4pt" class=""><div class=""><div style="border-style:solid none none;border-top-color:rgb(181,196,223);border-top-width:1pt;padding:3pt 0cm 0cm" class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><b class=""><span lang="EN-US" style="font-size:10pt;font-family:Tahoma,sans-serif" class="">From:</span></b><span lang="EN-US" style="font-size:10pt;font-family:Tahoma,sans-serif" class=""><span class=""> </span>Quentin Colombet [mailto:<a href="mailto:qcolombet@apple.com" style="color:purple;text-decoration:underline" target="_blank" class="">qcolombet@apple.com</a>]<span class=""> </span><br class=""><b class="">Sent:</b><span class=""> </span>11 January 2016 17:23<br class=""><b class="">To:</b><span class=""> </span>Daniel Sanders<br class=""><b class="">Cc:</b><span class=""> </span>Tim Northover (<a href="mailto:t.p.northover@gmail.com" style="color:purple;text-decoration:underline" target="_blank" class="">t.p.northover@gmail.com</a>); llvm-dev</span><u class=""></u><u class=""></u></div></div></div></div></div></div><div class=""><div class=""><div style="border-style:none none none solid;border-left-color:blue;border-left-width:1.5pt;padding:0cm 0cm 0cm 4pt" class=""><div class=""><div style="border-style:solid none none;border-top-color:rgb(181,196,223);border-top-width:1pt;padding:3pt 0cm 0cm" class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span lang="EN-US" style="font-size:10pt;font-family:Tahoma,sans-serif" class=""><br class=""><b class="">Subject:</b><span class=""> </span>Re: [llvm-dev] [GlobalISel] A Proposal for global instruction selection</span><u class=""></u><u class=""></u></div></div></div></div></div></div><div class=""><div class=""><div style="border-style:none none none solid;border-left-color:blue;border-left-width:1.5pt;padding:0cm 0cm 0cm 4pt" class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""> <u class=""></u><u class=""></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class="">Hi Daniel,<u class=""></u><u class=""></u></div><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""> <u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class="">Thanks for the pointers, I wasn’t aware of the second thread you’ve mentioned.<u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""> <u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class="">I may be wrong but I think LLVM-IR optimizations really treat bistcasts as no-op casts, in the sense of no instructions are required.<u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""> <u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class="">Is there anyone that could chime in on that?<u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""> <u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class="">However, it seems SelectionDAG sticks to the load/store semantic:<u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:10pt;font-family:'Lucida Grande',serif;background-color:rgb(251,252,253);background-position:initial initial;background-repeat:initial initial" class="">"BITCAST - This operator converts between integer, vector and FP values, as if the value was<span class=""> </span><b class="">stored to memory with one type and loaded from the same address with the other type</b><span class=""> </span>(or equivalently for vector format conversions, etc)."</span><u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""> <u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class="">I am fine with treating bit casts as equivalent store/load pairs in GISel, I just want to be sure we do not have a semantic gap between the LLVM-IR and the backend if we do.<u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""> <u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class="">Thanks,<u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class="">-Quentin<u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""> <u class=""></u><u class=""></u></div><div class=""><blockquote style="margin-top:5pt;margin-bottom:5pt" class=""><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class="">On Jan 11, 2016, at 7:43 AM, Daniel Sanders <<a href="mailto:Daniel.Sanders@imgtec.com" style="color:purple;text-decoration:underline" target="_blank" class="">Daniel.Sanders@imgtec.com</a>> wrote:<u class=""></u><u class=""></u></div></div><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""> <u class=""></u><u class=""></u></div><div class=""><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class="">Hi,</span><u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class=""> </span><u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class="">It was a comment by Tim that first made me aware of it (see <a href="http://lists.llvm.org/pipermail/llvm-dev/2013-August/064714.html" style="color:purple;text-decoration:underline" target="_blank" class=""><span style="color:purple" class="">http://lists.llvm.org/pipermail/llvm-dev/2013-August/064714.html</span></a> but I think he commented on one of my patches before that).</span><u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class=""> </span><u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class="">I asked about it on llvm-dev a couple weeks later (<a href="http://lists.llvm.org/pipermail/llvm-dev/2013-August/064919.html" style="color:purple;text-decoration:underline" target="_blank" class=""><span style="color:purple" class="">http://lists.llvm.org/pipermail/llvm-dev/2013-August/064919.html</span></a>) highlighting the contradiction and was told that 'no-op cast' referred to the lack of math rather than a requirement that zero instructions are used. It's therefore my understanding that shuffling the bits to preserve the load/store based definition isn't considered to be changing the bits.</span><u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class=""> </span><u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class="">I think the main thing the current definition is unclear on is whether it refers to the bits in a physical machine register or the bits in the LLVM-IR virtual register. Most of the time these two views are the same but this doesn't quite work for big-endian MSA/NEON. For example:</span><u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif;text-indent:36pt" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class="">%0 = bitcast <4 x i32> <i32 1, i32 2, i32 3, i32 4> to <2 x i64></span><u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif;text-indent:36pt" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class="">%0 = <2 x i64> <i64 (1 << 32) | 2, i64 (3 << 32) | 4></span><u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class="">are equivalent to each other in LLVM-IR terms but the constants are physically laid out in MSA registers as:</span><u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif;text-indent:36pt" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class="">0x00000004000000030000000200000001 # <4 x i32> <i32 1, i32 2, i32 3, i32 4></span><u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif;text-indent:36pt" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class="">0x00000003000000040000000100000002 # <2 x i64> <i64 (1 << 32) | 2, i64 (3 << 32) | 4></span><u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class="">and we must therefore shuffle the bits to preserve LLVM-IR's point of view.</span><u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class=""> </span><u class=""></u><u class=""></u></div></div><div style="border-style:none none none solid;border-left-color:blue;border-left-width:1.5pt;padding:0cm 0cm 0cm 4pt" class=""><div class=""><div style="border-style:solid none none;border-top-color:rgb(181,196,223);border-top-width:1pt;padding:3pt 0cm 0cm" class=""><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><b class=""><span lang="EN-US" style="font-size:10pt;font-family:Tahoma,sans-serif" class="">From:</span></b><span lang="EN-US" style="font-size:10pt;font-family:Tahoma,sans-serif" class=""> Quentin Colombet [<a href="mailto:qcolombet@apple.com" style="color:purple;text-decoration:underline" target="_blank" class="">mailto:qcolombet@apple.com</a>] <br class=""><b class="">Sent:</b> 07 January 2016 19:58<br class=""><b class="">To:</b> Daniel Sanders<br class=""><b class="">Cc:</b> llvm-dev<br class=""><b class="">Subject:</b> Re: [llvm-dev] [GlobalISel] A Proposal for global instruction selection</span><u class=""></u><u class=""></u></div></div></div></div><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""> <u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class="">Hi Daniel,<u class=""></u><u class=""></u></div></div><div class=""><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""> <u class=""></u><u class=""></u></div></div></div><div class=""><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class="">I had a quick look at the language reference for bitcast and I have a different reading than what you were pointing out.<u class=""></u><u class=""></u></div></div></div><div class=""><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class="">Indeed, my take away is:<u class=""></u><u class=""></u></div></div></div><div class=""><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:10.5pt;font-family:'Lucida Sans Unicode',sans-serif;background-color:white;background-position:initial initial;background-repeat:initial initial" class="">"It is <b class="">always a </b></span><em class=""><b class=""><span style="font-size:10.5pt;font-family:'Lucida Sans Unicode',sans-serif" class="">no-op cast</span></b></em><span style="font-size:10.5pt;font-family:'Lucida Sans Unicode',sans-serif;background-color:white;background-position:initial initial;background-repeat:initial initial" class=""> because no bits change with this conversion."</span><u class=""></u><u class=""></u></div></div></div><div class=""><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""> <u class=""></u><u class=""></u></div></div></div><div class=""><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class="">In other words, deleting all bitcast instructions should be fine.<u class=""></u><u class=""></u></div></div></div><div class=""><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""> <u class=""></u><u class=""></u></div></div></div><div class=""><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class="">My understanding of the quote you’ve highlighted is that it tells C programmers that this is like a memcpy, not a cast :).<u class=""></u><u class=""></u></div></div></div><div class=""><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""> <u class=""></u><u class=""></u></div></div></div><div class=""><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class="">Cheers,<u class=""></u><u class=""></u></div></div></div><div class=""><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class="">-Quentin<u class=""></u><u class=""></u></div></div><div class=""><blockquote style="margin-top:5pt;margin-bottom:5pt" class=""><div class=""><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class="">On Nov 20, 2015, at 6:53 AM, Daniel Sanders <<a href="mailto:Daniel.Sanders@imgtec.com" style="color:purple;text-decoration:underline" target="_blank" class=""><span style="color:purple" class="">Daniel.Sanders@imgtec.com</span></a>> wrote:<u class=""></u><u class=""></u></div></div></div><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""> <u class=""></u><u class=""></u></div></div><div class=""><div class=""><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class="">Hi,</span><u class=""></u><u class=""></u></div></div></div><div class=""><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class=""> </span><u class=""></u><u class=""></u></div></div></div><div class=""><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class="">I haven't had chance to read all of this yet, but one minor thing occurred to me during your presentation that I want to mention. At one point you mentioned deleting all the bitcast instructions since they're equivalent to nops but this isn't always true.</span><u class=""></u><u class=""></u></div></div></div><div class=""><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class=""> </span><u class=""></u><u class=""></u></div></div></div><div class=""><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class="">The <a href="http://llvm.org/docs/LangRef.html" style="color:purple;text-decoration:underline" target="_blank" class=""><span style="color:purple" class="">http://llvm.org/docs/LangRef.html</span></a> definition of the bitcast instruction includes this sentence:</span><u class=""></u><u class=""></u></div></div></div><div class=""><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif;text-indent:36pt" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class="">The conversion is done as if the value had been stored to memory and read back as type ty2.</span><u class=""></u><u class=""></u></div></div></div><div class=""><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class="">For big-endian MSA, this is equivalent to a shuffling of the bits in the register because endianness only changes the byte order within each element. The order of the elements is unaffected by endianness. IIRC, big-endian NEON is the same way.</span><u class=""></u><u class=""></u></div></div></div><div class=""><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class=""> </span><u class=""></u><u class=""></u></div></div></div><div style="border-style:none none none solid;border-left-color:blue;border-left-width:1.5pt;padding:0cm 0cm 0cm 4pt" class=""><div class=""><div style="border-style:solid none none;border-top-color:rgb(181,196,223);border-top-width:1pt;padding:3pt 0cm 0cm" class=""><div class=""><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><b class=""><span lang="EN-US" style="font-size:10pt;font-family:Tahoma,sans-serif" class="">From:</span></b><span lang="EN-US" style="font-size:10pt;font-family:Tahoma,sans-serif" class=""> llvm-dev [<a href="mailto:llvm-dev-bounces@lists.llvm.org" style="color:purple;text-decoration:underline" target="_blank" class=""><span style="color:purple" class="">mailto:llvm-dev-bounces@lists.llvm.org</span></a>] <b class="">On Behalf Of </b>Quentin Colombet via llvm-dev<br class=""><b class="">Sent:</b> 18 November 2015 19:27<br class=""><b class="">To:</b> llvm-dev<br class=""><b class="">Subject:</b> [llvm-dev] [GlobalISel] A Proposal for global instruction selection</span><u class=""></u><u class=""></u></div></div></div></div></div><div class=""><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""> <u class=""></u><u class=""></u></div></div></div><div class=""><div class=""><div class=""><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class="">Hi,<br class=""><span style="color:rgb(18,192,14)" class=""><br class=""></span>With this email, I would like to kick-off the development for the next instruction selector that I described during the last LLVM Dev’ Meeting.<br class="">For the motivations, see Jakob’s proposal (<a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-August/064727.html" style="color:purple;text-decoration:underline" target="_blank" class=""><span style="color:purple" class="">http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-August/064727.html</span></a>) and for the proposal, see the slides (Keynote: <a href="http://llvm.org/viewvc/llvm-project/www/trunk/devmtg/2015-10/slides/Colombet-GlobalInstructionSelection.key?view=co" style="color:purple;text-decoration:underline" target="_blank" class=""><span style="color:purple" class="">http://llvm.org/viewvc/llvm-project/www/trunk/devmtg/2015-10/slides/Colombet-GlobalInstructionSelection.key?view=co</span></a> or PDF: <a href="http://llvm.org/viewvc/llvm-project/www/trunk/devmtg/2015-10/slides/Colombet-GlobalInstructionSelection.pdf?revision=252430&view=co" style="color:purple;text-decoration:underline" target="_blank" class=""><span style="color:purple" class="">http://llvm.org/viewvc/llvm-project/www/trunk/devmtg/2015-10/slides/Colombet-GlobalInstructionSelection.pdf?revision=252430&view=co</span></a>) or the talk (<a href="https://www.youtube.com/watch?v=F6GGbYtae3g&list=PL_R5A0lGi1AA4Lv2bBFSwhgDaHvvpVU21&index=2" style="color:purple;text-decoration:underline" target="_blank" class=""><span style="color:purple" class="">https://www.youtube.com/watch?v=F6GGbYtae3g&list=PL_R5A0lGi1AA4Lv2bBFSwhgDaHvvpVU21&index=2</span></a>).<u class=""></u><u class=""></u></div></div></div></div><div class=""><div class=""><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><br class="">TL;DR This is happening now, feedbacks invited!<br class=""><br class="">*** Context ***<br class=""><span style="color:rgb(18,192,14)" class=""><br class=""></span>During the last LLVM Dev’ Meeting, I have presented a proposal for the next instruction selector, GlobalISel. The proposal is basically summarized in "High Level Prototype Design” and “Roadmap”. (If you want further details, feel free to reach me.)<br class=""><span style="color:rgb(0,175,205)" class=""><br class=""></span>The first step of the development plan is to prototype the new framework on open source. The idea is to <b class="">start prototyping now(!)</b> and have the discussion ongoing in parallel. The reason of such approach is to have code that can be used to inform those discussions, e.g., by collecting data and trying different designs approaches. Regarding the discussion, I have listed a few points where your feedbacks would be particularly appreciated (see Feedback Invite).<u class=""></u><u class=""></u></div></div></div></div><div class=""><div class=""><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><span style="color:rgb(0,175,205)" class=""><br class=""></span>Also, as I have mentioned in my talk, some issues are controversial but I expect them to be resolved during prototype development. Specifically theses concern aspects of legalization (should parts of it be done at the LLVM IR level or all at the MI level?) and code re-use for instruction combiner. Please feel free to bring up your specific concern as I move along with the development plan.<br class=""><span style="color:rgb(0,175,205)" class=""><br class=""></span>I expect the design to evolve with our experimental findings and your feedbacks and contributions.<br class="">Nonetheless, we expect to nail down some design decisions once and for all as the prototype progresses. I have highlighted them with the following pattern <b class="">[final]</b>.<br class=""><span style="color:rgb(18,192,14)" class=""><br class=""><br class=""><br class=""></span>*** Feedback Invite ***<br class=""><span style="color:rgb(0,175,205)" class=""><br class=""></span>If you follow and support this work you need to be aware of three things and I am eager to hear your feedback and thoughts about them: the overall goals of Global ISel, the goals of the prototype, and the impact of the prototype work on backend design. <br class=""><span style="color:rgb(0,175,205)" class=""><br class=""></span>In the section “Goals", I defined (repeated for people that saw the talk) the goals for the Global ISel design.<br class="">- Do you see anything missing?<br class="">- Do you see something that should not be there? <br class=""><span style="color:rgb(0,175,205)" class=""><br class=""></span>The prototype will answer critical design questions (see “Design Questions the Prototype Addresses at the End of M1" for examples) before the actual design of Gobal ISel is finalized, but it cannot cover everything.<br class="">Specifically we will <b class="">*not*</b> look into improving TableGen or reuse InstCombine (see “ Proposed Approach” for the rational). Please let me know if you see any issue with that.<br class=""><span style="color:rgb(0,175,205)" class=""><br class=""></span>There is also basic ground work needed to prepare for Global ISel and I need to extend the core MachineInstr-level APIs as explained during the talk. For this, I prepared sketches of patches to illustrate them and describe the details in the “Implications” section below. Please have a look at the patches to have a better idea of the expected impact.<br class=""><span style="color:rgb(0,175,205)" class=""><br class=""></span>If there is anything else you want to discuss related to Global ISel feel free to reach me. In particular, several people expressed their interests during the LLVM Dev Meeting in contributing to the project. Let me know what is your area of interest, so that we can coordinate our efforts.<br class="">Anyhow, please add [GlobalISel] in the subject line to help categorizing the emails.<br class=""><span style="color:rgb(0,175,205)" class=""><br class=""><br class=""><br class=""></span>*** Goals ***<br class=""><span style="color:rgb(18,192,14)" class=""><br class=""></span>The high level goals of the new instruction selector are:<br class="">- Global instruction selector.<br class="">- Fast instruction selector.<br class="">- Shared code path for fast and good instruction selection.<br class="">- IR that represents ISA concepts better.<br class="">- More flexible instruction selector.<br class="">- Easier to maintain/understand framework, in particular legalization.<br class="">- Self contained machine representation, no back links to LLVM IR.<br class="">- No change to LLVM IR.<br class=""><span style="color:rgb(88,86,214)" class=""><br class=""></span>Note: The goals are common to all targets. In particular, we do not intend to work on target specific feature for the prototype.<br class="">The bottom line is please make sure those goals are compatible with what you want to achieve for your target, even if your requirement does not get listed here.<br class=""><br class=""><span style="color:rgb(18,192,14)" class=""><br class=""><br class=""></span>*** Proposed Approach ***<br class=""><span style="color:rgb(18,192,14)" class=""><br class=""></span>In this section, I describe the approach I plan to pursue in the prototype and the roadmap to get there. The final design will flow out of it.<br class=""><span style="color:rgb(18,192,14)" class=""><br class=""></span>For this prototype, we purposely exclude any work to improve or use TableGen or InstCombine <b class="">[final].</b> We will keep in mind however, that some of the C++ code we write will be table-generated at some point.<br class="">The rational is that we do not want to lay down a new TableGen/InstCombine infrastructure before being able to work on the ISel framework itself.<br class=""><span style="color:rgb(18,192,14)" class=""><br class=""></span>The prototype vehicle will be <b class="">AArch64</b>. None of the changes for GlobalISel will negatively impact the existing ISel.<br class=""><span style="color:rgb(18,192,14)" class=""><br class=""><br class=""></span>** High Level Prototype Design **<br class=""><span style="color:rgb(18,192,14)" class=""><br class=""></span>As shown in the talk, the expected pipeline for the prototype is:<br class=""><b class="">LLVM IR </b>-> IRTranslator -> <b class="">Generic (G) MachineInstr</b> -> Legalizer -> RegBankSelect -> Select -> <b class="">MachineInstr</b><br class=""><span style="color:rgb(18,192,14)" class=""><br class=""></span>Where:<br class="">- Terms in <b class="">bold</b> are intermediate representations.<br class="">- Generic MachineInstrs are machine instructions with a generic opcode, e.g., ADD, COPY.<u class=""></u><u class=""></u></div></div></div></div><div class=""><div class=""><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class="">- IRTranslator: Translate LLVM IR to (G) MachineInstr.<br class="">- Legalizer: Legalize illegal (G) MachineInstr to legal (G) MachineInstr.<br class="">- RegBankSelect: Assign virtual register with size to virtual register with Register Bank.<br class="">- Select: Translate the remaining (G) MachineInstr to MachineIntr.<br class=""><br class=""><span style="color:rgb(0,175,205)" class=""><br class=""><br class=""></span>** Implications **<br class=""><span style="color:rgb(0,175,205)" class=""><br class=""></span>As part of the bring-up of the prototype, we need to extend some of the core MachineInstr-level APIs:<br class=""> - Need to remember FastMath flags for each MachineInstr.<br class=""> - Need to know the type of each MachineInstr. We don’t want ADD8, ADD16, etc.<br class=""> - Extend the MachineRegisterInfo to support size as well as register classes for virtual registers.<br class=""><span style="color:rgb(0,175,205)" class=""><br class=""></span>I have sketched the changes in the attached patches to help picturing how the changes would impact the existing APIs.<u class=""></u><u class=""></u></div></div></div></div><div class=""><div class=""><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""> <u class=""></u><u class=""></u></div></div></div></div><div class=""><div class=""><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class="">Note: I do not intend to commit those changes as they are. They will go the usual review process in due time.<u class=""></u><u class=""></u></div></div></div></div><div class=""><div class=""><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""><br class="">The patches contain “// ***”-like comment that give a rough explanation on why those changes are needed w.r.t. the goals.<br class="">The order of the patches could be modified since the dependencies between those are not sequential. Anyhow, here are the patches:<br class="">1. Introduce (some of) the generic opcode.<br class="">2. Make MachineFunction more independent of LLVM IR to eventually be able to delete the LLVM IR instance from the memory.<br class="">3. Extend MachineInstr to represent additional information attached to generic opcode.<br class="">4. Teach MachineRegisterInfo about size for virtual registers.<br class="">5. Introduce a helper class to build MachineInstr related objects.<br class="">6. Add new target hooks to lower the ABI directly to MachineInstr.<br class="">7. Introduce the IRTranslator pass.<br class=""><br class=""><span style="color:rgb(18,192,14)" class=""><br class=""></span>** Roadmap for the Prototype **<br class=""><span style="color:rgb(0,175,205)" class=""><br class=""></span>We plan to split the prototype in three main milestones:<br class="">1. Translation: LLVM IR to (G) MachineInstr translation.<br class="">2. Basic selector: Legal LLVM IR to target specific MachineInstr.<br class="">3. Simple legalization: Support scalar type legalization and some vector instructions.<br class=""><span style="color:rgb(0,175,205)" class=""><br class=""></span>Notes:<br class="">- For #1, we will not support any fancy instructions like landing pad or switch.<br class="">- Each milestone should take about 3-4 months.<u class=""></u><u class=""></u></div></div></div></div><div class=""><div class=""><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class="">- At the end of #2, we would have a FastISel like selector.<br class=""><span style="color:rgb(0,175,205)" class=""><br class=""></span>Each milestone will be detailed right before starting it. The rational is that we want to accommodate what we discovered with the prototype for the next milestone. In other words, in this email, <b class="">I only describe the first milestone</b> in detail and I will give more details on the next milestone shortly before we start it and so on. For your information, here is the remaining of the intended roadmap for the <b class="">full</b> project:<br class="">4. Productization: Clean up implementation, stabilize the APIs.<br class="">5. Complex legalization: Extend legalization support to everything missing.<br class="">6. Completeness: Fill the blanks, e.g., landing pad.<br class="">7. Clean-up and performance: Add the necessary bits to be at parity or beat SelectionDAG generated code.<br class="">8. Transition: Document how to switch, provide tools to help.<br class=""><span style="color:rgb(0,175,205)" class=""><br class=""><br class=""></span>** Milestone 1 **<br class=""><span style="color:rgb(18,192,14)" class=""><br class=""></span>The first phase is focused on the IRTranslator pass.<br class=""><span style="color:rgb(18,192,14)" class=""><br class=""></span>The IRTranslator is responsible for translating the LLVM IR into Generic MachineInstr. The IRTranslator pass uses some target hooks to perform the ABI lowering. We can either define a new API for them, e.g., ABILoweringInfo, or extend the existing TargetLowering.<br class="">Moreover, the prototype will focus on simple instruction, i.e., we will not support switch or landing pad for this iteration.<br class=""><span style="color:rgb(18,192,14)" class=""><br class=""></span>At the end of M1, the prototype will not be able to produce code, since we would only have the beginning of the Global ISel pipeline. Instead, we will test the IRTranslator on the generic output that is produced from the tested IR.<br class=""><span style="color:rgb(18,192,14)" class=""><br class=""></span>* Design Decisions *<br class=""><span style="color:rgb(18,192,14)" class=""><br class=""></span>- The IRTranslator is a final class. Its purpose is to move away from LLVM IR to MachineInstr world <b class="">[final]</b>.<br class="">- Lower the ABI as part of the translation process <b class="">[final]</b>.<br class=""><span style="color:rgb(18,192,14)" class=""><br class=""></span>* Design Questions the Prototype Addresses at the End of M1 *<br class=""><span style="color:rgb(18,192,14)" class=""><br class=""></span>- Handling of aggregate types during the translation.<br class="">- Lowering of switches.<br class="">- What about Module pass for Machine pass?<br class="">- Introduce new APIs to have a clearer separation between:<br class=""> - Legalization (setOperationAction, etc.)<br class=""> - Cost/Combine related (isXXXFree, etc.)<br class=""> - Lowering related (LowerFormal, etc.)<br class="">- What is the contract with the backends? Is it still “should be able to select any valid LLVM IR”?<br class=""><span style="color:rgb(0,175,205)" class=""><br class=""></span>Thanks,<u class=""></u><u class=""></u></div></div></div><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class="">-Quentin<u class=""></u><u class=""></u></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></blockquote></div></div></div></div></blockquote></div><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class=""> <u class=""></u><u class=""></u></div></div></div></div></div><div style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif" class="">_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" style="color:purple;text-decoration:underline" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" style="color:purple;text-decoration:underline" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><u class=""></u><u class=""></u></div></blockquote></div></div></div></div></blockquote></div></div></div><div style="word-wrap:break-word" class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">_______________________________________________</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">LLVM Developers mailing list</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class=""><a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a></span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a></span></div></blockquote></div></div></div></blockquote></div>
</div></blockquote></div><br class=""></div></body></html>