This is an archive of the discontinued LLVM Phabricator instance.

[M68k][GlobalISel] Fix a big-endian-related bug in CallLowering
AbandonedPublic

Authored by 0x59616e on Jan 7 2022, 5:50 PM.

Details

Reviewers
None
Summary

When dealing with i64 data in function call, such as
incoming argument, return value, passing argument to another
function, GlobalISel splits i64 into 2 i32 in little endian
order. We need to reverse the order since M68k is big endian.

This patch hacks on this by defining our own ValueAssigner.
When spliting arguments, we cache the results. After
the work is done, we store the results back in reverse order.

Diff Detail

Event Timeline

0x59616e created this revision.Jan 7 2022, 5:50 PM
0x59616e requested review of this revision.Jan 7 2022, 5:50 PM
Herald added a project: Restricted Project. · View Herald TranscriptJan 7 2022, 5:50 PM

GlobalISel also has the same problem on load / store of i64. We need to hack on Legalizer to make it correct. The next patch will fix this.

arsenm added a subscriber: arsenm.Jan 7 2022, 6:05 PM
arsenm added inline comments.
llvm/lib/Target/M68k/GISel/M68kCallLowering.cpp
94–96

I think it would be more appropriate to reverse the order where the parts were split in the first place (i.e. make splitToValueTypes endian aware)

0x59616e added inline comments.Jan 7 2022, 8:52 PM
llvm/lib/Target/M68k/GISel/M68kCallLowering.cpp
94–96

Hi arsenm:

Thanks for reviewing ! I think you're right. Fixing this in the main framework of CallLowering benefits to all of the big endian user (if any).

I already had some ideas when I hacked on this. I'll put it into practice asap :)

0x59616e added a comment.EditedJan 8 2022, 8:39 PM

I've submitted a new patch D116877 that fixes this in CallLowering directly.

0x59616e abandoned this revision.Jan 11 2022, 3:57 PM