<div style="min-height:22px;margin-bottom:8px;">Merry Christmas:) Thanks for your leading! I chose the second option <a href="https://github.com/xiangzhai/llvm/commit/d1b5bdbb2f8f4b5ad559b2a9662745d0fa9ef83d">https://github.com/xiangzhai/llvm/commit/d1b5bdbb2f8f4b5ad559b2a9662745d0fa9ef83d</a></div><div style="min-height:22px;margin-bottom:8px;"><br></div><span class="mail-footer">发自我的iPad</span><div id="original-content"><br><br><div><div style="font-size:70%;padding:2px 0;">------------------ Original ------------------</div><div style="font-size:70%;background:#f0f0f0;color:#212121;padding:8px;border-radius:4px"><div><b>From:</b> Alex Bradbury <asb@lowrisc.org></div><div><b>Date:</b> 周二,12月 26,2017 19:17</div><div><b>To:</b> Leslie Zhai <lesliezhai@llvm.org.cn></div><div><b>Cc:</b> Aditya Nandakumar <aditya_nandakumar@apple.com>, LLVM Developers Mailing List <llvm-dev@lists.llvm.org></div><div><b>Subject:</b> Re: How to implement lowerReturn for poring GlobalISel to RISCV?</div></div></div><br>On 26 December 2017 at 07:50, Leslie Zhai <lesliezhai@llvm.org.cn> wrote:<br>> Hi Alex,<br>><br>> Sorry to bother you for the holidays!<br>><br>> I am stuck at CC_RISCV[1] you removed RetCC_RISCV32 and CC_RISCV32 from<br>> RISCVCallingConv.td and implemented a custom calling convention[2] function<br>> owing to TableGen-based calling convention definitions to lack flexibility<br>> and require substantial boilerplate when you reach their limitations.<br>><br>> I asked the similar question[3] in the mailing list before, and Diana<br>> suggested that having a CCAssignFn available would make it easier to use the<br>> existing infrastructure. Because ValueHandler needs a CCAssignFn varaible<br>> for handling return not void value in lowerReturn.<br>><br>> Please lead me to give me some direction, thanks a lot!<br><br>Hi Leslie. It seems the options are either:<br>1) Refactoring the existing CC_RISCV32 function to conform to the<br>CCAssignFn type. This would require stuffing the extra needed<br>information into a CCState subclass.<br>2) Pass a dummy AssignFn to the ValueHandler constructor and override<br>ValueHandler::assignArg.<br><br>Option 2) provides a straight-forward route to just getting something<br>working but isn't really a long-term solution. However, with a working<br>baseline implementation it's easier to explore and test alternative<br>approaches. If I were you, I'd probably start with 2) in order to make<br>immediate progress, but plan to change approach prior to merging<br>upstream.<br><br>Best,<br><br>Alex</div>