<div class="__aliyun_email_body_block"><div  style="clear:both;"><span  style="font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;color:#000000;">Hi, guys.</span></div><div  style="clear:both;"><span  style="font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;color:#000000;"><br ></span></div><div  style="clear:both;">I re-active this email thread talk because found a related issue recently.</div><div  style="clear:both;"><br ></div><div  style="clear:both;">After the thread talk before, I have no wondering the design that i32 type is illegal in llvm codegen(backend). But is this needed to be consistent for layout string? Now, the layout string is "e-m:e-p:64:64-i64:64-i128:128-n64-S128" for 64-bit arch. As it indicates that native integer type is only i64 (-n64-), it influences the predictor(<span  style="color:#000000;font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;text-align:start;text-indent:.0px;text-transform:none;widows:2;background-color:#ffffff;text-decoration-thickness:initial;text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline;">"</span><span  style="color:#000000;font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;text-align:start;text-indent:.0px;text-transform:none;widows:2;background-color:#ffffff;text-decoration-thickness:initial;text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline;">DL.isLegalInteger"</span>) result which is used across many middle-end passes. This stops from some optmization such as LSR. Sepecificly, ~157th line, at IVUsers.cpp.<div  style="color:#d4d4d4;background-color:#1e1e1e;font-family:Menlo,Monaco,Courier New,monospace;font-weight:normal;font-size:12.0px;line-height:18.0px;"><div ><span  style="color:#6a9955;">  // LSR is not APInt clean, do not touch integers bigger than 64-bits.</span></div><div ><span  style="color:#6a9955;">  // Also avoid creating IVs of non-native types. For example, we don't want a</span></div><div ><span  style="color:#6a9955;">  // 64-bit IV in 32-bit code just because the loop has one 64-bit cast.</span></div><div ><span  style="color:#d4d4d4;">  </span><span  style="color:#569cd6;">uint64_t</span><span  style="color:#d4d4d4;"> Width = </span><span  style="color:#9cdcfe;">SE</span><span  style="color:#d4d4d4;">-></span><span  style="color:#dcdcaa;">getTypeSizeInBits</span><span  style="color:#d4d4d4;">(</span><span  style="color:#9cdcfe;">I</span><span  style="color:#d4d4d4;">-></span><span  style="color:#dcdcaa;">getType</span><span  style="color:#d4d4d4;">());</span></div><div ><span  style="color:#d4d4d4;">  </span><span  style="color:#c586c0;">if</span><span  style="color:#d4d4d4;"> (Width > </span><span  style="color:#b5cea8;">64</span><span  style="color:#d4d4d4;"> || !</span><span  style="color:#9cdcfe;">DL</span><span  style="color:#d4d4d4;">.</span><span  style="color:#dcdcaa;">isLegalInteger</span><span  style="color:#d4d4d4;">(Width))</span></div><div ><span  style="color:#d4d4d4;">    </span><span  style="color:#c586c0;">return</span><span  style="color:#d4d4d4;"> </span><span  style="color:#569cd6;">false</span><span  style="color:#d4d4d4;">;</span></div></div><div  style="clear:both;"></div></div><div  style="clear:both;"><div  style="clear:both;"><span  style="font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;color:#000000;"><br ></span></div></div><div  style="clear:both;"><div  style="clear:both;"><span  style="font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;color:#000000;">I draft some ways to solve this issue. Could we just use n32:64 in layout string without degression of some other passes(optimization) use this info? Or we need some API like `</span>DL.isLegalOrPromoteInteger(Width)`.</div></div><div  style="clear:both;"><div  style="clear:both;"><br ></div></div><div  style="clear:both;"><div  style="clear:both;"><div  style="margin:.0px;padding:.0px;border:.0px;outline:.0px;color:#000000;font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;text-align:start;text-indent:.0px;text-transform:none;widows:2;background-color:#ffffff;text-decoration-thickness:initial;text-decoration-style:initial;text-decoration-color:initial;clear:both;">Regards,</div><div  style="margin:.0px;padding:.0px;border:.0px;outline:.0px;color:#000000;font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;text-align:start;text-indent:.0px;text-transform:none;widows:2;background-color:#ffffff;text-decoration-thickness:initial;text-decoration-style:initial;text-decoration-color:initial;clear:both;">Zeson</div></div></div><div  style="clear:both;"><div  style="clear:both;"><br ></div></div><div  style="clear:both;"><div  style="clear:both;"><span  style="font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;color:#000000;">------------------------------------------------------------------</span></div><div  style="clear:both;"><span  style="font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;color:#000000;">Sender:Craig Topper <craig.topper@gmail.com></span></div><div  style="clear:both;"><span  style="font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;color:#000000;">Sent At:2021 Sep. 17 (Fri.) 02:03</span></div><div  style="clear:both;"><span  style="font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;color:#000000;">Recipient:Zeson <zixuan.wu@linux.alibaba.com></span></div><div  style="clear:both;"><span  style="font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;color:#000000;">Cc:llvm-dev <llvm-dev@lists.llvm.org></span></div><div  style="clear:both;"><span  style="font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;color:#000000;">Subject:Re: [llvm-dev] [SelectionDAG][RISCV] i32 type illegal in 64-bit target is really a good design in RISCV?</span></div><div  style="clear:both;"><span  style="font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;color:#000000;"><br ></span></div><div >Hi Zeson,<div ><br ></div><div >I've given this some thought recently. PowerPC, unlike RISCV64 has different register classes for 32 and 64 and they have a full set of instructions for both register classes. RV64 only has 64-bit AND/OR/XOR/compares and the ABI requires 32-bit values to be passed sign extended.</div><div ><br ></div><div >If we make i32 legal, then all values between basic blocks will be i32 instead of i64. We currently try to insert sext_inreg when we type legalize so that we can make use of SelectionDAGBuilder's ability to propagate known sign bits across basic blocks using AssertSExt nodes. If we start using i32 across basic blocks we lose this and will need a MachineIR pass to clean it up. Granted we're not perfect today and maybe should have such a MachineIR pass anyway.</div><div ><br ></div><div >I have thought about adopting the approach of Mips64 where i32 is legal but the upper bits of the register are always sign extended. I believe their 32-bit instructions explicitly check this in hardware. This could simplify some of the cross basic block issues because now everything is always sign extended. It does require some tricky things like an i64->i32 truncate must be emitted as a sext.w in order to enforce the sign extension rule. These might be unnecessary depending what the using instructions are, but again SelectionDAG's single basic block limitation makes this difficult to see. So we would again probably need a MachineIR pass to do cleanup.</div><div ><br ></div><div >I don't know what the right answer is.</div><div ><br  clear="all"><div ><div  class="gmail_signature">~Craig</div></div><br ></div></div><br ><div  class="gmail_quote"><div  class="gmail_attr">On Thu, Sep 16, 2021 at 3:22 AM Zeson via llvm-dev <<a  href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br ></div><div ><div  style="clear:both;"><span  class=" __aliyun_node_has_color" style="font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;color:#000000;">Hi, all.</span></div><div  style="clear:both;"><span  class=" __aliyun_node_has_color" style="font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;color:#000000;"><br ></span></div><div  style="clear:both;"><span  class=" __aliyun_node_has_color" style="font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;color:#000000;">Considering the issue to leverage i32 series instructions, <a  href="https://reviews.llvm.org/D107658" target="_blank">https://reviews.llvm.org/D107658</a>. Also some other target DAG combine actions such as combining any_ext node to leverage ADDW/SUBW/... </span></div><div  style="clear:both;"><span  class=" __aliyun_node_has_color" style="font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;color:#000000;"> I think those effects are caused by originally and naturally treating i32 type illegal in 64-bit target for RISCV. And it makes much following work to add patches.</span></div><div  style="clear:both;">Is it really a good way to handle i32 type in 64-bit mode RISCV target? </div><div  style="clear:both;">Could it be just like what PowerPC does that make both i32 and i64 are legal in DAG selection phase?</div><div  style="clear:both;"><br ></div><div  style="clear:both;"><br ></div><div  style="clear:both;"><br ></div><div  style="clear:both;">Regards,</div><div  style="clear:both;">Zeson</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" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br ></div></div><div ><br ></div></div>