[llvm-dev] How to implement lowerReturn for poring GlobalISel to RISCV?

翟翔 via llvm-dev llvm-dev at lists.llvm.org
Tue Dec 26 03:24:04 PST 2017


Merry Christmas:) Thanks for your leading! I chose the second option https://github.com/xiangzhai/llvm/commit/d1b5bdbb2f8f4b5ad559b2a9662745d0fa9ef83d


发自我的iPad

------------------ Original ------------------
From: Alex Bradbury <asb at lowrisc.org>
Date: 周二,12月 26,2017 19:17
To: Leslie Zhai <lesliezhai at llvm.org.cn>
Cc: Aditya Nandakumar <aditya_nandakumar at apple.com>, LLVM Developers Mailing List <llvm-dev at lists.llvm.org>
Subject: Re: How to implement lowerReturn for poring GlobalISel to RISCV?



On 26 December 2017 at 07:50, Leslie Zhai <lesliezhai at llvm.org.cn> wrote:
> Hi Alex,
>
> Sorry to bother you for the holidays!
>
> I am stuck at CC_RISCV[1] you removed RetCC_RISCV32 and CC_RISCV32 from
> RISCVCallingConv.td and implemented a custom calling convention[2] function
> owing to TableGen-based calling convention definitions to lack flexibility
> and require substantial boilerplate when you reach their limitations.
>
> I asked the similar question[3] in the mailing list before, and Diana
> suggested that having a CCAssignFn available would make it easier to use the
> existing infrastructure. Because ValueHandler needs a CCAssignFn varaible
> for handling return not void value in lowerReturn.
>
> Please lead me to give me some direction, thanks a lot!

Hi Leslie. It seems the options are either:
1) Refactoring the existing CC_RISCV32 function to conform to the
CCAssignFn type. This would require stuffing the extra needed
information into a CCState subclass.
2) Pass a dummy AssignFn to the ValueHandler constructor and override
ValueHandler::assignArg.

Option 2) provides a straight-forward route to just getting something
working but isn't really a long-term solution. However, with a working
baseline implementation it's easier to explore and test alternative
approaches. If I were you, I'd probably start with 2) in order to make
immediate progress, but plan to change approach prior to merging
upstream.

Best,

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171226/54dc3c8d/attachment.html>


More information about the llvm-dev mailing list