The m68k backend will always emit external calls (including libcalls)
with
PC-relative PLT relocations, even when in non-pic mode or -fno-plt is
used.
This is unexpected, as other function calls are emitted with absolute
addressing, and a static code modes suggests that there is no PLT. It
also
leads to a miscompilation where the call instruction emitted expects an
immediate address, while the relocation emitted for that instruction is
PC-relative.
This miscompilation can even be seen in the default C function in
godbolt:
https://godbolt.org/z/zEoazovzo
Fix the issue by classifying external function references based upon the
pic
mode. This triggers a change in the static code model, making it more in
line
with the expected behaviour and allowing use of this backend in more
bare-metal
situations where a PLT does not exist.
The change avoids the issue where we emit a PLT32 relocation for an
absolute
call, and makes libcalls and other external calls use absolute
addressing modes
when a static code model is desired.
Further work should be done in instruction lowering and validation to
ensure
that miscompilations of the same type don't occur.
Put the value into A0 instead of data registers. And remove the
redundant `RetCC_M68kCommon` as there aren't many rules shared between
existing CCs other than the pointer one.
This change is tested by existing tests.
Previously ADD & ADDA (as well as SUB & SUBA) instructions are mixed
together, which not only violated Motorola assembly's syntax but also
made asm parsing more difficult. This patch separates these two kinds of
instructions migrate rest of the tests from
test/CodeGen/M68k/Encoding/Arithmetic to test/MC/M68k/Arithmetic.
Note that we observed minor regressions on codegen quality: Sometimes
isel uses ADD instead of ADDA even the latter can lead to shorter
sequence of code. This issue implies that some isel patterns might need
to be updated.
And a small utilities -- extract-section.py -- that helps extracting
specific object file section and printing in textual format. This
utility is just a workaround for tests inside `Encoding`. Hopefully in
the future we can replace dependencies in those tests with existing tools
(e.g. llvm-readobj). Please refer to this bug for more context:
https://bugs.llvm.org/show_bug.cgi?id=49245
Note that since we don't have AsmParser for now, we are testing the MC
part using MIR as input and put those tests under the `Encoding` folder.
In the future when AsmParser (and disassembler) is finished, those tests
will be moved to `test/MC/M68k`.
Authors: myhsu, m4yers, glaubitz
Differential Revision: https://reviews.llvm.org/D88392
