Ricky Taylor via llvm-dev
2021-Aug-27 12:15 UTC
[llvm-dev] [M68k] CCR usage / instruction encoding
Hi, I've been angling at migrating changes from my proof-of-concept Mega Drive fork back into mainline LLVM. There are a fair few smaller pieces (a few extra instruction implementations, some minor bug fixes) but the fork itself made some large changes in order to get a working demo on the hardware proper. Additionally, as it was part of a proof-of-concept (and I lack experience working on the LLVM backend), a lot of the original implementation is not going to have been implemented in the best way. I'm hesitant to try and migrate any of the smaller changes before some of the larger questions are answered because it might result in redundant work. The two biggest areas of concern I have are: - CCR usage - At the moment, the M68k target doesn't actually support the 68000, because it relies on saving the CCR which wasn't introduced until the 68010. (You can save the SR, which includes the CCR, but that is a privileged instruction.) - In my PoC for the Mega Drive, I disabled allocation of the CCR and had the code generate CCR in the immediately preceding instruction - this was flaky because sometimes the instructions got split - Instruction encoding - This is the point of discussion of PR48792: Review options between using CodeBeads v.s. TSFlags (https://bugs.llvm.org/show_bug.cgi?id=48792) - The code-beads implementation is particularly painful for disassembly, even the landed disassembler feels messy - There is an instruction definition per set of operand permutations in the M68k backend, which makes manipulating the instructions in the backend outside of codegen quite difficult - I wrote up some thoughts in a previous message: https://lists.llvm.org/pipermail/llvm-dev/2021-February/148408.html I'm happy to put some effort into either of these problems, though I could definitely benefit from some guidance. I'm not entirely sure what the process is from here. Prepare an RFC for any major changes and start landing incrementally once they achieve some kind of consensus? Thanks, Ricky Taylor
Renato Golin via llvm-dev
2021-Aug-28 12:33 UTC
[llvm-dev] [M68k] CCR usage / instruction encoding
On Fri, 27 Aug 2021 at 13:15, Ricky Taylor via llvm-dev < llvm-dev at lists.llvm.org> wrote:> I'm not entirely sure what the process is from here. Prepare an RFC > for any major changes and start landing incrementally once they achieve > some kind of consensus?Hi Ricky, I can't comment on the m68k stuff directly, but I can give some pointers on the general consensus building framework. First of all, you seem to have a pretty good idea on what the next steps are, so that's half of the problem solved. M68k also has a pretty solid sub-community, which makes driving local changes much easier. On consensus building... IIUC, most of those questions are related to the target itself and not the generic code generation framework (sel-dag, legalizatio, MIR, etc). The only one I remember was more generic is the code-beads that needed table-gen support, but adding a new table-gen back-end is less controversial than changing how sel-dag works, so not super controversial. I'm sure there will be dependencies between wider changes and local changes, and that's up to the community how to divide the RFCs and work. But when bringing RFCs to the attention of the wider community, it's best if the sub-community is already in agreement on what they want to do and what are the valid alternatives (in case the first option doesn't work). So, I'd encourage you to start RFCs for the local changes targeting the sub-community, but using this list, so that other people can participate and give opinions. Once there is consensus on the changes you can start another RFC to a wider audience, for example, to introduce code-beads into table-gen, with some alternatives. All of the local changes that don't need wider consensus can already be implemented in the target itself, approved by the local community, as long as it doesn't change wider behaviour or break bots, etc. Hopefully this is helpful in some way... cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210828/202ba442/attachment.html>
Min-Yih Hsu via llvm-dev
2021-Aug-30 06:28 UTC
[llvm-dev] [M68k] CCR usage / instruction encoding
Hi Ricky, On Fri, Aug 27, 2021 at 5:15 AM Ricky Taylor <rickytaylor26 at gmail.com> wrote:> Hi, > > I've been angling at migrating changes from my proof-of-concept Mega Drive > fork > back into mainline LLVM. There are a fair few smaller pieces (a few extra > instruction implementations, some minor bug fixes) but the fork itself > made some > large changes in order to get a working demo on the hardware proper. > > Additionally, as it was part of a proof-of-concept (and I lack experience > working on the LLVM backend), a lot of the original implementation is not > going > to have been implemented in the best way. > > I'm hesitant to try and migrate any of the smaller changes before some of > the > larger questions are answered because it might result in redundant work. > > The two biggest areas of concern I have are: > > - CCR usage > - At the moment, the M68k target doesn't actually support the 68000, > because > it relies on saving the CCR which wasn't introduced until the 68010. > (You can save the SR, which includes the CCR, but that is a privileged > instruction.) > - In my PoC for the Mega Drive, I disabled allocation of the CCR and had > the > code generate CCR in the immediately preceding instruction - this was > flaky because sometimes the instructions got split >I haven't looked into this problem TBH.> > - Instruction encoding > - This is the point of discussion of PR48792: Review options between > using > CodeBeads v.s. TSFlags (https://bugs.llvm.org/show_bug.cgi?id=48792) > - The code-beads implementation is particularly painful for disassembly, > even the landed disassembler feels messy > - There is an instruction definition per set of operand permutations in > the M68k backend, which makes manipulating the instructions in the > backend outside of codegen quite difficult > - I wrote up some thoughts in a previous message: > https://lists.llvm.org/pipermail/llvm-dev/2021-February/148408.html > >Sorry I missed your previous message on the mailing list. In addition to the TSFlags solution recently I've been studying if the tablegen-ed MCCodeEmitter (i.e. the `-gen-emitter` TG backend) can help on this problem. Though it's mostly used by ISA that has (sorta) fixed-size instructions, the fact is that it never puts any limitation on the size of instructions as well as asking to have uniform size across all instructions. What's more, despite the fact that M68k has variable-length instructions, it has more regular sizes since it's always multiple of words (16 bits) and more importantly, as you also mentioned in your February post, in most cases we can determine the address mode of an instruction operand by only looking at the first word. In other words, even if we can't carry every encoding info using the aforementioned tablegen solution or TSFlags, we can at least use them to specify the encoding of the first word. Regarding the permutation problem...I also feel the pain in terms of maintenance, but I can't really find any other solution based on the current tablegen design. To be fair, most of these permutations have been factored out using multiclass or class. Which, IMAO, is still readable for now. One really bold idea will be addressing this problem from the tablegen language itself by adding some sort of multidimensional table that, for instance, has two-dimension columns (corresponding to the source and destination operands' addressing mode) and puts data (the complete instruction definition) in the third dimension.> I'm happy to put some effort into either of these problems, though I could > definitely benefit from some guidance. > > I'm not entirely sure what the process is from here. Prepare an RFC > for any major changes and start landing incrementally once they achieve > some kind of consensus? > > Thanks, > Ricky Taylor >-- Min-Yih Hsu Ph.D Student in ICS Department, University of California, Irvine (UCI). -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210829/e38c4960/attachment.html>