This reverts commit 80a34ae311 with fixes.
Previously, since bots turning on EXPENSIVE_CHECKS are essentially turning on
MachineVerifierPass by default on X86 and the fact that
inline-asm-avx-v-constraint-32bit.ll and inline-asm-avx512vl-v-constraint-32bit.ll
are not expected to generate functioning machine code, this would go
down to `report_fatal_error` in MachineVerifierPass. Here passing
`-verify-machineinstrs=0` to make the intent explicit.
This reverts commit 80a34ae311 with fixes.
On bots llvm-clang-x86_64-expensive-checks-ubuntu and
llvm-clang-x86_64-expensive-checks-debian only,
llc returns 0 for these two tests unexpectedly. I tweaked the RUN line a little
bit in the hope that LIT is the culprit since this change is not in the
codepath these tests are testing.
llvm\test\CodeGen\X86\inline-asm-avx-v-constraint-32bit.ll
llvm\test\CodeGen\X86\inline-asm-avx512vl-v-constraint-32bit.ll
This reverts commit rGcd5b308b828e, rGcd5b308b828e, rG8cedf0e2994c.
There are issues to be investigated for polly bots and bots turning on
EXPENSIVE_CHECKS.
Summary:
Implements the jump pseudo-instruction, which is used in e.g. the Linux kernel.
Reviewers: asb, lenary
Reviewed By: lenary
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D73178
Summary:
Previously, we would erroneously turn %pcrel_lo(label), where label has
a %pcrel_hi against a weak symbol, into %pcrel_lo(label + offset), as
evaluatePCRelLo would believe the target independent logic was going to
fold it. Moreover, even if that were fixed, shouldForceRelocation lacks
an MCAsmLayout and thus cannot evaluate the %pcrel_hi fixup to a value
and check the symbol, so we would then erroneously constant-fold the
%pcrel_lo whilst leaving the %pcrel_hi intact. After D72197, this same
sequence also occurs for symbols with global binding, which is triggered
in real-world code.
Instead, as discussed in D71978, we introduce a new FKF_IsTarget flag to
avoid these kinds of issues. All the resolution logic happens in one
place, with no coordination required between RISCAsmBackend and
RISCVMCExpr to ensure they implement the same logic twice. Although the
implementation of %pcrel_hi can be left as target independent, we make
it target dependent to ensure that they are handled identically to
%pcrel_lo, otherwise we risk one of them being constant folded but the
other being preserved. This also allows us to properly support fixup
pairs where the instructions are in different fragments.
Reviewers: asb, lenary, efriedma
Reviewed By: efriedma
Subscribers: arichardson, hiraditya, rbar, johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217, MaskRay, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D73211
Summary:
This patch could be treated as a rebase of D33960. It also fixes PR35547.
A fix for `llvm/test/Other/close-stderr.ll` is proposed in D68164. Seems
the consensus is that the test is passing by chance and I'm not
sure how important it is for us. So it is removed like in D33960 for now.
The rest of the test fixes are just adding `--crash` flag to `not` tool.
** The reason it fixes PR35547 is
`exit` does cleanup including calling class destructor whereas `abort`
does not do any cleanup. In multithreading environment such as ThinLTO or JIT,
threads may share states which mostly are ManagedStatic<>. If faulting thread
tearing down a class when another thread is using it, there are chances of
memory corruption. This is bad 1. It will stop error reporting like pretty
stack printer; 2. The memory corruption is distracting and nondeterministic in
terms of error message, and corruption type (depending one the timing, it
could be double free, heap free after use, etc.).
Reviewers: rnk, chandlerc, zturner, sepavloff, MaskRay, espindola
Reviewed By: rnk, MaskRay
Subscribers: wuzish, jholewinski, qcolombet, dschuff, jyknight, emaste, sdardis, nemanjai, jvesely, nhaehnle, sbc100, arichardson, jgravelle-google, aheejin, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, jsji, lenary, s.egerton, pzheng, cfe-commits, MaskRay, filcab, davide, MatzeB, mehdi_amini, hiraditya, steven_wu, dexonsmith, rupprecht, seiya, llvm-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D67847
Summary:
AMO memory operands use a custom parser in order to accept both (reg)
and 0(reg). However, the validation predicate used for these operands
was only checking that they were registers, and not the register class,
so non-GPRs (such as FPRs) were also accepted. Thus, fix this by making
the predicate check that they are GPRs.
Reviewers: asb, lenary
Reviewed By: asb, lenary
Subscribers: hiraditya, rbar, johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217, MaskRay, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D72471
Summary:
This is analogous to D58943, which correctly finds the corresponding
fixup. However, when linker relaxations are disabled and we evaluate the
fixup, we need to also ensure we use an offset of 0 rather than the size
of the previous fragment.
Reviewers: asb, efriedma, lenary
Reviewed By: efriedma
Subscribers: hiraditya, rbar, johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217, MaskRay, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71978
Summary: Instead of crashing due to the `llvm_unreachable`, provide a proper
error when invalid fixups/relocations are encountered.
Reviewers: asb, lenary
Reviewed By: asb
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71536
Summary:
This copy ensures that debug location information is kept for
compressed instructions. There are places where both compressInstruction and
uncompressInstruction are called that were not doing this copy, discarding some
debug info.
This change merely moves the copy into the generated file, so you cannot forget
to copy the location over when compressing or uncompressing.
Reviewers: asb, luismarques
Reviewed By: luismarques
Subscribers: sameer.abuasal, aprantl, hiraditya, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, s.egerton, pzheng, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D67493
This adds support for printing improved missing feature error messages
from the assembler, which now indicates which feature caused the parse
to fail.
Differential Revision: https://reviews.llvm.org/D69899
The following testcase
function:
.Lpcrel_label1:
auipc a0, %pcrel_hi(other_function)
addi a1, a0, %pcrel_lo(.Lpcrel_label1)
.p2align 2 # Causes a new fragment to be emitted
.type other_function,@function
other_function:
ret
exposes an odd behaviour in which only the %pcrel_hi relocation is
evaluated but not the %pcrel_lo.
$ llvm-mc -triple riscv64 -filetype obj t.s | llvm-objdump -d -r -
<stdin>: file format ELF64-riscv
Disassembly of section .text:
0000000000000000 function:
0: 17 05 00 00 auipc a0, 0
4: 93 05 05 00 mv a1, a0
0000000000000004: R_RISCV_PCREL_LO12_I other_function+4
0000000000000008 other_function:
8: 67 80 00 00 ret
The reason seems to be that in RISCVAsmBackend::shouldForceRelocation we
only consider the fragment but in RISCVMCExpr::evaluatePCRelLo we
consider the section. This usually works but there are cases where the
section may still be the same but the fragment may be another one. In
that case we end forcing a %pcrel_lo relocation without any %pcrel_hi.
This patch makes RISCVAsmBackend::shouldForceRelocation use the section,
if any, to determine if the relocation must be forced or not.
Differential Revision: https://reviews.llvm.org/D60657
These old aliases were renamed, but are still used by some projects (eg newlib).
Differential Revision: https://reviews.llvm.org/D68392
llvm-svn: 373618
Summary:
Now that llvm-objdump allows target-specific options, we match the
`no-aliases` and `numeric` options for RISC-V, as supported by GNU objdump.
This is done by overriding the variables used for the command-line options, so
that the command-line options are still supported.
This patch updates all tests using `llvm-objdump -riscv-no-aliases` to use
`llvm-objdump -M no-aliases`.
Reviewers: luismarques, asb
Reviewed By: luismarques, asb
Subscribers: pzheng, hiraditya, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, s.egerton, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D66139
llvm-svn: 371534
Summary:
This is an option primarily to use during testing. Instead of always
printing registers using their ABI names, this allows a user to request they
are printed with their architectural name.
This is then used in the register constraint tests to ensure the mapping
between architectural and abi names is correct.
Reviewers: asb, luismarques
Reviewed By: asb
Subscribers: pzheng, hiraditya, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, s.egerton, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65950
llvm-svn: 371531
The hint instructions are enabled by default (if the standard C extension is
enabled). To disable them pass -mattr=-rvc-hints.
Differential Revision: https://reviews.llvm.org/D62592
llvm-svn: 369528
Follow binutils in using RISCV_32_PCREL for the FDE initial location. As
explained in the relevant binutils commit
<a6cbf936e3>,
the ADD/SUB pair of relocations is problematic in the presence of linker
relaxation.
This patch has the same end goal as D64715 but includes test changes and
avoids adding a new global VariantKind to MCExpr.h (preferring
RISCVMCExpr VKs like the rest of the RISC-V backend).
Differential Revision: https://reviews.llvm.org/D66419
llvm-svn: 369375
The current behavior of shouldForceRelocation forces relocations for the
majority of fixups when relaxation is enabled. This makes sense for
fixups which incorporate symbols but is unnecessary for simple data
fixups where the fixup target is already resolved to an absolute value.
Differential Revision: https://reviews.llvm.org/D63404
Patch by Edward Jones.
llvm-svn: 369257
This patch allows symbols followed by an expression for an offset to be
parsed as bare symbols.
Differential Revision: https://reviews.llvm.org/D57332
llvm-svn: 369097
Summary:
GCC Accepts both (reg) and 0(reg) for atomic instruction memory
operands. These instructions do not allow for an offset in their
encoding, so in the latter case, the 0 is silently dropped.
Due to how we have structured the RISCVAsmParser, the easiest way to add
support for parsing this offset is to add a custom AsmOperand and
parser. This parser drops all the parens, and just keeps the register.
This commit also adds a custom printer for these operands, which matches
the GCC canonical printer, printing both `(a0)` and `0(a0)` as `(a0)`.
Reviewers: asb, lewis-revill
Reviewed By: asb
Subscribers: s.egerton, hiraditya, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, jfb, PkmX, jocewei, psnobl, benna, Jim, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65205
llvm-svn: 367553
These tests have been disabled on Linux and Windows due to failing
there. I think that could be down to a race condition between stdout
and stderr, so I have disabled output to stdout.
For the moment, only re-enable on linux, because I don't have a windows
machine to test on.
llvm-svn: 367311
Because they fail there too.
FAIL: LLVM :: MC/RISCV/rv32i-aliases-invalid.s (24397 of 32659)
******************** TEST 'LLVM :: MC/RISCV/rv32i-aliases-invalid.s' FAILED ********************
Script:
--
: 'RUN: at line 2'; not c:\src\llvm.monorepo\build.release2\bin\llvm-mc.exe C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv32i-aliases-invalid.s -triple=riscv32 -riscv-no-aliases 2>&1 | c:\src\llvm.monorepo\build.release2\bin\filecheck.exe C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv32i-aliases-invalid.s
: 'RUN: at line 3'; not c:\src\llvm.monorepo\build.release2\bin\llvm-mc.exe C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv32i-aliases-invalid.s -triple=riscv32 2>&1 | c:\src\llvm.monorepo\build.release2\bin\filecheck.exe C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv32i-aliases-invalid.s
--
Exit Code: 1
Command Output (stdout):
--
$ ":" "RUN: at line 2"
$ "not" "c:\src\llvm.monorepo\build.release2\bin\llvm-mc.exe" "C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv32i-aliases-invalid.s" "-triple=riscv32" "-riscv-no-aliases"
$ "c:\src\llvm.monorepo\build.release2\bin\filecheck.exe" "C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv32i-aliases-invalid.s"
C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv32i-aliases-invalid.s:10:21: error: CHECK: expected string not found in input
li t4, foo # CHECK: :[[@LINE]]:8: error: immediate must be an integer in the range [-2147483648, 4294967295]
^
<stdin>:5:1: note: scanning from here
li x0, -2147483649 # CHECK: :[[@LINE]]:8: error: immediate must be an integer in the range [-2147483648, 4294967295]
^
<stdin>:5:1: note: with "@LINE" equal to "10"
li x0, -2147483649 # CHECK: :[[@LINE]]:8: error: immediate must be an integer in the range [-2147483648, 4294967295]
^
<stdin>:5:38: note: possible intended match here
li x0, -2147483649 # CHECK: :[[@LINE]]:8: error: immediate must be an integer in the range [-2147483648, 4294967295]
^
error: command failed with exit status: 1
--
--
********************
Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70
FAIL: LLVM :: MC/RISCV/rv64i-aliases-invalid.s (24416 of 32659)
******************** TEST 'LLVM :: MC/RISCV/rv64i-aliases-invalid.s' FAILED ********************
Script:
--
: 'RUN: at line 2'; not c:\src\llvm.monorepo\build.release2\bin\llvm-mc.exe C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv64i-aliases-invalid.s -triple=riscv64 -riscv-no-aliases 2>&1 | c:\src\llvm.monorepo\build.release2\bin\filecheck.exe C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv64i-aliases-invalid.s
: 'RUN: at line 3'; not c:\src\llvm.monorepo\build.release2\bin\llvm-mc.exe C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv64i-aliases-invalid.s -triple=riscv64 2>&1 | c:\src\llvm.monorepo\build.release2\bin\filecheck.exe C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv64i-aliases-invalid.s
--
Exit Code: 1
Command Output (stdout):
--
$ ":" "RUN: at line 2"
$ "not" "c:\src\llvm.monorepo\build.release2\bin\llvm-mc.exe" "C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv64i-aliases-invalid.s" "-triple=riscv64" "-riscv-no-aliases"
$ "c:\src\llvm.monorepo\build.release2\bin\filecheck.exe" "C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv64i-aliases-invalid.s"
C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv64i-aliases-invalid.s:6:21: error: CHECK: expected string not found in input
li t4, foo # CHECK: :[[@LINE]]:8: error: operand must be a constant 64-bit integer
^
<stdin>:2:1: note: scanning from here
li t5, 0x10000000000000000 # CHECK: :[[@LINE]]:8: error: unknown operand
^
<stdin>:2:1: note: with "@LINE" equal to "6"
li t5, 0x10000000000000000 # CHECK: :[[@LINE]]:8: error: unknown operand
^
<stdin>:13:67: note: possible intended match here
C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv64i-aliases-invalid.s:12:13: error: immediate must be an integer in the range [0, 63]
^
error: command failed with exit status: 1
llvm-svn: 367215
We were getting test failures on some builders, which pointed to @LINE
being an undefined variable. I think that these failures should have
been fixed by https://reviews.llvm.org/rL366434, so I'm re-enabling the
test.
llvm-svn: 366797
In debug frame information, some fields, e.g., Length in CIE/FDE and
Offset in FDE are attributes to describe the structure of CIE/FDE. They
are not related to the relaxed code. However, these attributes are
symbol differences. So, in current design, these attributes will be
filled as zero and LLVM generates relocations for them.
We only need to generate relocations for symbols in executable sections.
So, if the symbols are not located in executable sections, we still
evaluate their values under relaxation.
Differential Revision: https://reviews.llvm.org/D61584
llvm-svn: 366531
It is necessary to generate fixups in .debug_frame or .eh_frame as
relaxation is enabled due to the address delta may be changed after
relaxation.
There is an opcode with 6-bits data in debug frame encoding. So, we
also need 6-bits fixup types.
Differential Revision: https://reviews.llvm.org/D58335
llvm-svn: 366442
The canonical GNU form of JALR resembles a load/store instruction rather
than placing the immediate offset as a separate argument, so match this
behaviour. Also add parser-only aliases for the three-operand form, and
add other shorter aliases also emitted by GNU tools.
Differential Revision: https://reviews.llvm.org/D55277
Patch by James Clarke.
llvm-svn: 366179
RISCVAsmBackend::shouldInsertExtraNopBytesForCodeAlign() assumed that the
align specified would be greater than or equal to the minimum nop length, but
that is not always the case - for example if a user specifies ".align 0" in
assembly.
Differential Revision: https://reviews.llvm.org/D63274
Patch by Edward Jones.
llvm-svn: 366176
Summary:
Useful for jumps, such as `j .`.
I am not sure who should review this. Do not hesitate to change the reviewers if needed.
Reviewers: asb, jrtc27, lenary
Reviewed By: lenary
Subscribers: MaskRay, lenary, hiraditya, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63669
Patch by John LLVM (JohnLLVM)
llvm-svn: 365881
This patch adds the PseudoCALLReg instruction which allows using an
explicit register operand as the destination for the return address.
GCC can successfully parse this form of the call instruction, which
would be used for calls to functions which do not use ra as the return
address register, such as the __riscv_save libcalls. This patch forms
the first part of an implementation of -msave-restore for RISC-V.
Differential Revision: https://reviews.llvm.org/D62685
llvm-svn: 364403
This patch allows immediates (and CSR alias immediates) which start with
a tilde token or an exclaim (!) token to be parsed as intended.
Differential Revision: https://reviews.llvm.org/D57320
llvm-svn: 363783
Since the parser attempts to parse an operand as a register with
parentheses before parsing it as an immediate, immediates in
parentheses should not be parsed by parseRegister. However in the case
where the immediate does not start with an identifier, the LParen is not
unlexed and so the RParen causes an unexpected token error.
This patch adds the missing UnLex, and modifies the existing UnLex to
not use a buffered token, as it should always be unlexing an LParen.
Differential Revision: https://reviews.llvm.org/D57319
llvm-svn: 363782
This patch adds the pseudo instructions la.tls.ie and la.tls.gd, used in
the initial-exec and global-dynamic TLS models respectively when
addressing a global. The pseudo instructions are expanded in the
assembly parser.
llvm-svn: 361499
We use both -long-option and --long-option in tests. Switch to --long-option for consistency.
In the "llvm-readelf" mode, -long-option is discouraged as it conflicts with grouped short options and it is not accepted by GNU readelf.
While updating the tests, change llvm-readobj -s to llvm-readobj -S to reduce confusion ("s" is --section-headers in llvm-readobj but --symbols in llvm-readelf).
llvm-svn: 359649
This patch adds support for parsing and assembling the %tls_ie_pcrel_hi
and %tls_gd_pcrel_hi modifiers.
Differential Revision: https://reviews.llvm.org/D55342
llvm-svn: 358994
RISCVMCCodeEmitter::expandAddTPRel asserts that the second operand must be
x4/tp. As we are not currently checking this in the RISCVAsmParser, the assert
is easy to trigger due to wrong assembly input.
This patch does a late check of this constraint.
An alternative could be using a singleton register class for x4/tp similar to
the current one for sp. Unfortunately it does not result in a good diagnostic.
Because add is an overloaded mnemonic, if no matching is possible, the
diagnostic of the first failing alternative seems to be used as the diagnostic
itself. This means that this case the %tprel_add is diagnosed as an invalid
operand (because the real add instruction only has 3 operands).
Differential Revision: https://reviews.llvm.org/D60528
llvm-svn: 358183
This patch adds support in the MC layer for parsing and assembling the
4-operand add instruction needed for TLS addressing. This also involves
parsing the %tprel_hi, %tprel_lo and %tprel_add operand modifiers.
Differential Revision: https://reviews.llvm.org/D55341
llvm-svn: 357698
This patch allows symbols appended with @plt to parse and assemble with the
R_RISCV_CALL_PLT relocation.
Differential Revision: https://reviews.llvm.org/D55335
Patch by Lewis Revill.
llvm-svn: 357470
A pcrel_lo will point to the associated pcrel_hi fixup which in turn points to
the real target. RISCVMCExpr::evaluatePCRelLo will work around this
indirection in order to allow the fixup to be evaluate properly. However, if
relocations are forced (e.g. due to linker relaxation is enabled) then its
evaluation is undesired and will result in a relocation with the wrong target.
This patch modifies evaluatePCRelLo so it will not try to evaluate if the
fixup will be forced as a relocation. A new helper method is added to
RISCVAsmBackend to query this.
Differential Revision: https://reviews.llvm.org/D59686
llvm-svn: 357374
Fangrui Song