<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:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=iso-8859-1"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:"Ericsson Hilda";
        panose-1:0 0 5 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;
        mso-fareast-language:EN-US;}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Ericsson Hilda",serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;
        mso-fareast-language:EN-US;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=SV link="#0563C1" vlink="#954F72"><div class=WordSection1><p class=MsoNormal><span lang=EN-US style='font-family:"Ericsson Hilda",serif'>We have a special architecture where i24 is a legal data type, and where 16 bits – not 8 bits – is considered a byte. Thus, the smallest addressable unit is 16 bits, which in combination with i24 causes problems during matching in global-isel. Let us assume that we have the following pattern:<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Ericsson Hilda",serif'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New";color:black'>  (ld:{ *:[i24] } aN32_0_7:{ *:[i32] }:$addr)<<P:Predicate_unindexedload>><<P:Predicate_load>></span><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New";color:black;mso-fareast-language:SV'><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Ericsson Hilda",serif'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Ericsson Hilda",serif'>for which the matching table looks as follows:<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Ericsson Hilda",serif'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Courier New"'>  ...<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New";color:black'>  GIM_CheckMemorySizeEqualToLLT, /*MI*/0, /*MMO*/0, /*OpIdx*/0,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New";color:black'>  GIM_CheckAtomicOrdering, /*MI*/0, /*Order*/(int64_t)AtomicOrdering::NotAtomic,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New";color:black'> // MIs[0] addr<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New";color:black'>  GIM_CheckPointerToAny, /*MI*/0, /*Op*/1, /*SizeInBits*/32,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New";color:black'>  GIM_CheckRegBankForClass, /*MI*/0, /*Op*/1, /*RC*/PHX::aN32_0_7RegClassID,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Courier New"'>  ...<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Ericsson Hilda",serif'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Ericsson Hilda",serif'>Because 24 bits is not a multiple of 16, we load 2 “bytes” aligned at 1. Hence, the table above is expected to match:<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Ericsson Hilda",serif'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Courier New"'>  %1(s24) = G_LOAD %0 :: (load 2, align 1)<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Ericsson Hilda",serif'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Ericsson Hilda",serif'>However, this is always rejected due to:<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Ericsson Hilda",serif'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New";color:black'>  GIM_CheckMemorySizeEqualToLLT, /*MI*/0, /*MMO*/0, /*OpIdx*/0,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;font-family:"Courier New";color:black'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Ericsson Hilda",serif'>which checks whether the size of the result (24 bits) is equal to the size of the memory size (32 bits), which naturally is false.</span><span lang=EN-US style='font-family:"Ericsson Hilda",serif'><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Ericsson Hilda",serif'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Ericsson Hilda",serif'>A simple fix would be to simply remove the check, but then there is no check ensuring that the result of the source pattern matches the result of the destination pattern. Also, I get the feeling that there are underlying assumptions surrounding G_LOAD that you either load data of equal or greater size (which is then extended), but never of smaller size (as in this case).<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Ericsson Hilda",serif'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Ericsson Hilda",serif'>What is the proper fix to this problem? As I see it, either we allow G_LOAD to load smaller sizes and patch the code impacted by this, or we patch TableGen to generate code that allows such matches.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Ericsson Hilda",serif'>We could also try to promote i24 to i32, but that would involve modifying a lot of the existing patterns we have (and i24 is anyhow a legal size in our architecture).<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Ericsson Hilda",serif'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Ericsson Hilda",serif'>Best regards, <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Ericsson Hilda",serif'>Gabriel Hjort Åkerlund<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div></body></html>