<div dir="ltr"><div dir="ltr"><div>I also think the pointee type shouldn't matter; my impression was that ty* and ty'* should be treated equivalently and bitcasting between these should not have any side effects.<br></div><div>But, when it is used by load, which receives a type for interpretation of the loaded value, I don't think it's safe to convert load ty to load ty' with the same bit width in general.</div><div>A relevant bug in gcc: <a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416">https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416</a> , the transformation is also happening in LLVM: <a href="https://bugs.llvm.org/show_bug.cgi?id=45152">https://bugs.llvm.org/show_bug.cgi?id=45152</a></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 18, 2021 at 5:56 PM Wang, Pengfei via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-US" style="overflow-wrap: break-word;">
<div class="gmail-m_8804662747320759555WordSection1">
<p class="MsoNormal">Hi,<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">We are developing prototypes for Intel Advanced Matrix Extensions (AMX) [1] programing model in Clang and LLVM [2].<u></u><u></u></p>
<p class="MsoNormal">We met several cases when the certain type we added are optimized unexpectedly in the middle-end. E.g. optimizing phi + biscast + load:<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">From<u></u><u></u></p>
<p class="MsoNormal">%a = load <256 x i32>, <256 x i32>* %mem, align 64<u></u><u></u></p>
<p class="MsoNormal">… …<u></u><u></u></p>
<p class="MsoNormal">%b = phi <256 x i32> [ %a, %label1 ], [%someother, %label2]<u></u><u></u></p>
<p class="MsoNormal">%c = bitcast <256 x i32> %b to x86_amx<u></u><u></u></p>
<p class="MsoNormal">To<u></u><u></u></p>
<p class="MsoNormal">%a = bitcast <256 x i32>* %mem to x86_amx*<u></u><u></u></p>
<p class="MsoNormal">%b = load x86_amx, x86_amx*, align 64<u></u><u></u></p>
<p class="MsoNormal">… …<u></u><u></u></p>
<p class="MsoNormal">%c = phi x86_amx [ %b, %label1 ], [%someother, %label2]<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">To prevent such unexpected transforms, we concretely added the type check in each point of the optimizations.
<u></u><u></u></p>
<p class="MsoNormal">Roman pointed out the changes are not the right direction [3], and thought it’s bug for backend. While we agreed backend might be able to handle it for the functionality, we think it is better to handle it in the midden-end since they are
negative optimizations for AMX.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">First, let me put some background here:<u></u><u></u></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="gmail-m_8804662747320759555MsoListParagraph" style="margin-left:0in">x86_amx* is different from trivial pointers.<u></u><u></u></li></ol>
<p class="gmail-m_8804662747320759555MsoListParagraph">The AMX load instruction is much different from other load instructions. It is not only need the memory address but also the shape / stride of the tile register. We did some extra work in the backend to deduce the shape information
from the context. We don’t want the pass to add new x86_amx related usage because this will result in the difficulty in deduction. That said bitcasting other pointer types to x86_amx* is not trivial as assumed here.<u></u><u></u></p>
<ol style="margin-top:0in" start="2" type="1">
<li class="gmail-m_8804662747320759555MsoListParagraph" style="margin-left:0in">The physical tile registers have more limitations.
<u></u><u></u></li><ol style="margin-top:0in" start="1" type="a">
<li class="gmail-m_8804662747320759555MsoListParagraph" style="margin-left:0in">No copy instruction between tile registers.<u></u><u></u></li><li class="gmail-m_8804662747320759555MsoListParagraph" style="margin-left:0in">Spilling / reload a tile register is expensive in light of its size is 1024 bytes.<u></u><u></u></li><li class="gmail-m_8804662747320759555MsoListParagraph" style="margin-left:0in">The shapes of tile registers need to be pre-configured before use and all data in tile registers will turn into invalid once re-configured. That said we need to dominate as more tile
registers as possible to configure their shapes with one configure instruction, otherwise we need to spill and reload the live registers once we need to re-configure.<u></u><u></u></li><li class="gmail-m_8804662747320759555MsoListParagraph" style="margin-left:0in">The number of tile registers is rather small (only 8) and different shapes cannot be reused.<u></u><u></u></li></ol>
</ol>
<p class="MsoNormal" style="margin-left:0.5in">Based on the limitations, we need to reduce the use / live range of tile registers. But optimizations may increase the opportunity of the use. So even we can handle some combined operation for AMX type, we still
prefer to prevent it from the beginning. Unless we can totally roll back the optimization. Which is also not a good solution in my opinion.<u></u><u></u></p>
<ol style="margin-top:0in" start="3" type="1">
<li class="gmail-m_8804662747320759555MsoListParagraph" style="margin-left:0in">For more information, please refer to discussion in [3].<u></u><u></u></li></ol>
<p class="MsoNormal">For other optimization points, please refer [4][5].<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I think the main controversy from Roman is if middle-end pass should consider some special type when doing optimization. I tend to let middle-end do the type check on account of the peculiarity of AMX type. But I’m not sure if we have precedent
to handle the similar issue in other targets. I’m open and glad to do it either way so long as we have an elegant solution.<u></u><u></u></p>
<p class="MsoNormal">Any suggestions are welcome.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">[1] <a href="https://software.intel.com/content/www/us/en/develop/articles/intel-sdm.html#architecture" target="_blank">
https://software.intel.com/content/www/us/en/develop/articles/intel-sdm.html#architecture</a><u></u><u></u></p>
<p class="MsoNormal">[2] <a href="https://lists.llvm.org/pipermail/llvm-dev/2020-November/146770.html" target="_blank">
https://lists.llvm.org/pipermail/llvm-dev/2020-November/146770.html</a><u></u><u></u></p>
<p class="MsoNormal">[3] <a href="https://reviews.llvm.org/D98247" target="_blank">https://reviews.llvm.org/D98247</a><u></u><u></u></p>
<p class="MsoNormal">[4] <a href="https://reviews.llvm.org/D98595" target="_blank">https://reviews.llvm.org/D98595</a><u></u><u></u></p>
<p class="MsoNormal">[5] <a href="https://reviews.llvm.org/D98757" target="_blank">https://reviews.llvm.org/D98757</a><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Thanks<u></u><u></u></p>
<p class="MsoNormal">Pengfei<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
</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://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><br></div><font size="1">Juneyoung Lee</font><div><font size="1">Software Foundation Lab, Seoul National University</font></div></div></div></div>