[PATCH] D101819: Added initial boilerplate for Call Lowering [M68k GlobaliSel]

Shivam Gupta via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue May 4 02:18:59 PDT 2021


xgupta added subscribers: aemerson, qcolombet.
xgupta added a comment.

Hi @RKSimon,

Implementing GlobalISel for M68k is one of the Outreachy (3-month internship, 24 May to 24 Aug) projects. Sushma is one of the candidates for this project. To select the candidate there is currently a contribution period(till 9 May) is going on. This patch is a kind of task to check the skills of candiadate.

So we (project mentor: Anshil & Myself) don't have an industry use case, it is more about education purpose. and then further improve it to a stable state. We know that currently, GlobalISel doesn't have big-endian targets support. But we had listed this project after an email conversation with Amara and Quentin.

So yes it is also our responsibility to add big-endian targets in GlobalISel. We ask Amara and Quentin about how we can implement this part. So I think I should also share their response with Sushma.

Amara :

The places where you’re most likely to run into issues with big endian are in the IRTranslator (including CallLowering), and the legalizer (in LegalizerHelper.cpp) (which has to deal with illegal memory operations, and therefore can split them into pieces that may not be correct when using big-endian).

The majority of this code I don’t expect to require many changes. The issue I see is that unless you already have a M68000 GISel backend, how you’re going to try test cases to see what needs fixing is going to be hard. Perhaps you could try using AArch64 scalar code with big-endian to see what problems come up (IIRC AArch64’s big-endian scheme w.r.t vectors may be different to other backends in SelectionDAG).

Quentin:

+1 on the IRTranslator and the Legalizer. Basically anything that
breaks down chunks of bytes into smaller chunks of bytes may need
fixing (e.g., lowering a structure, legalizing a large load by
splitting it in smaller loads, etc.).

Unfortunately, we didn't get much time to look at the source code to implement the support. We are also kind of inexperienced in this field and open to any suggestions from the community. But I want to assure you that as soon as or before that we select the intern we will look into this also.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D101819/new/

https://reviews.llvm.org/D101819



More information about the llvm-commits mailing list