This is an archive of the discontinued LLVM Phabricator instance.

Fix for "Bug 49146 - Crash with MIPS16 multiply"
Needs ReviewPublic

Authored by jdeguire on Apr 9 2021, 10:50 AM.

Details

Reviewers
atanasyan
RKSimon
Summary

This is a potential fix for a bug I reported here (Bug 49146) in which a basic integer multiply instruction will crash Clang/LLVM when building for MIPS16. The test code I used is in the bug report. I manually verified the patch by examining the resulting disassembly from "llvm-objdump" to see the resulting "MULT->MFLO" instructions. I'm not sure if this patch should have been submitted to that bug report or here, so please let know me know if I'm in the wrong place.

(Note that there might be another minor bug in which a 3-bit "zero" field in the MIPS16 MFLO/MFHI is not set to zero, but I can look at that more closely and submit another patch later.)

The issue appeared to be that an "ISD::MUL" operation was being translated to a pseudo-instruction called "Mult16RxRyRz", but that pseudo-instruction was never translated to the real instruction sequence. Other operations that require the MIPS HI/LO registers are manually translated in the MIPS target-specific code and so this patch removes that pseudo-instruction and follows how the other HI/LO instructions are handled.

I'm not familiar with the LLVM review process and so any help with regards to documentation, providing tests, etc. would be appreciated.

Diff Detail

Event Timeline

jdeguire created this revision.Apr 9 2021, 10:50 AM
jdeguire requested review of this revision.Apr 9 2021, 10:50 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 9 2021, 10:50 AM
RKSimon resigned from this revision.Apr 13 2021, 2:43 AM

Sorry, but I don't know enough about MIPS16 to help with this.

I'd recommend adding some tests though!

jdeguire updated this revision to Diff 337560.Apr 14 2021, 2:30 PM

Updated the patch to add a very simple test. This test fails pre-patch and passes after the patch. This test does not check for correctness of the generated code, only that Clang does not crash.

jdeguire updated this revision to Diff 339273.Apr 21 2021, 9:39 AM

This applies "git format-clang" to the patch. I didn't do this originally because, as you can see, "git clang-format" makes changes that do not match the style of the surrounding code and so I was not sure what the proper course of action was. I can always either resubmit the previous patch or make another patch (maybe for a separate review) that re-formats the rest of the code.

atanasyan added inline comments.Apr 26 2021, 3:38 AM
clang/test/CodeGen/mips16-mult.c
2
  1. You need to create a test case in the llvm/test/CodeGen/Mips folder. Sometimes LLVM build without Clang.
  2. Test case should check result of code generation. Not only the fact that the program does not crash.
llvm/lib/Target/Mips/MipsISelLowering.cpp
208

It's better to keep formattings the same as the code around.

llvm/lib/Target/Mips/MipsISelLowering.h
57

Please revert this too big change unrelated to this patch.

jdeguire updated this revision to Diff 340670.Apr 26 2021, 3:34 PM

As requested, this patch removes the formatting changes that "git clang-format" had made to the previous patch. This also updates the test in clang/test/CodeGen to verify that assembly for a MULT, MFLO sequence is emitted. An equivalent test was generated from clang -S -emit-llvm and cleaned up to be added to llvm/test/CodeGen/Mips.

While I was able to update the test to verify that assembly was generated, I may need guidance as to verifying direct code generation (ie. calling Clang without the "-S" or "-emit-llvm" options). My original plan was to generate an object file, give that to llvm-objdump, and pipe that output to FileCheck, but I cannot get llvm-objdump to emit decoded MIPS16 assembly. It emits raw bytes and instructions are listed as "<unknown>" when using --triple=mipsel-linux-gnu --mattr=mips16. I was able to manually decode the output to verify that the raw bytes corresponded to the correct MULT, MFLO sequence, but I am not sure how I can reliably do that with FileCheck. Should I try to have FileCheck search for the raw sequence of bytes (which in this case is 78 ea 52 ea)?

jdeguire marked 3 inline comments as done.May 13 2021, 9:26 AM

Apologies for the very, very late responses to your comments. Yes, it really did take me 3 weeks to figure out that the "Submit" button is at the very bottom.

I would still appreciate any guidance on verifying direct code generation (or if that's even normally done as part of these tests). Thank you.

clang/test/CodeGen/mips16-mult.c
2

Mostly done, anyway. As stated my in most recent patch update, I was able to complete (1) but (2) I was able to complete for assembly output but not for direct machine code generation due to issues I'm having with llvm-objdump.

llvm/lib/Target/Mips/MipsISelLowering.cpp
208

Understood, reverted.

llvm/lib/Target/Mips/MipsISelLowering.h
57

Reverted.