[ARM] Use MCRegister in more places. NFC

[MC] Remove unnecessary DWARFMustBeAtTheEnd check

36a15cb975334403216e6145d4abece3026af17a introduced the
DWARFMustBeAtTheEnd check to ensure DWARF sections were placed after all
text sections to he

[MC] Remove unnecessary DWARFMustBeAtTheEnd check

36a15cb975334403216e6145d4abece3026af17a introduced the
DWARFMustBeAtTheEnd check to ensure DWARF sections were placed after all
text sections to help avoid out-of-range branches for Darwin ARM. The
commit removed a Darwin ARM hack from
20e5f5ed7930efdf2bd34bf099f24ac88798c5ea (2009), likely due to a
no-longer-relevant assembler limitation.

However, this check is no longer relevant due to the following:

* Our CodeGen approach reliably places DWARF sections at the end.
* Darwin AArch32 is less relevant today.

Removing this check also addresses a minor clang cc1as crash that could
occur when text sections were placed after DWARF sections
(e9ad54b3ee905ea3a77c35ca7d6e843b2c552e0b (2015)).

show more ...

[MC] Remove RelaxAll parameters from create*Streamer

Related to clean-up opportunities discussed at #90013.

After these cleanups, the `RelaxAll` parameter from
`createMCObjectStreamer` can be remov

[MC] Remove RelaxAll parameters from create*Streamer

Related to clean-up opportunities discussed at #90013.

After these cleanups, the `RelaxAll` parameter from
`createMCObjectStreamer` can be removed as well. As
`createMCObjectStreamer` is a more user-facing API and used by two files
in mlir/, we postpone the cleanup to the future.

show more ...

[NFC][ARM][AArch64] Cleanup TargetParser includes

llvm/TargetParser/TargetParser.h now only includes AMDGPU-specific
functionality, the ARM- and AArch64-specific functionality is in other
headers.

Simplify with hasFeature. NFC

[NFC][TargetParser] Remove llvm/ADT/Triple.h

I also ran `git clang-format` to get the headers in the right order for
the new location, which has changed the order of other headers in two
files.

[NFC][TargetParser] Remove llvm/Support/TargetParser.h

[MC] Make more use of MCInstrDesc::operands. NFC.

Change MCInstrDesc::operands to return an ArrayRef so we can easily use
it everywhere instead of the (IMHO ugly) opInfo_begin and opInfo_end.
A futu

[MC] Make more use of MCInstrDesc::operands. NFC.

Change MCInstrDesc::operands to return an ArrayRef so we can easily use
it everywhere instead of the (IMHO ugly) opInfo_begin and opInfo_end.
A future patch will remove opInfo_begin and opInfo_end.

Also use it instead of raw access to the OpInfo pointer. A future patch
will remove this pointer.

Differential Revision: https://reviews.llvm.org/D142213

show more ...

[MC] llvm::Optional => std::optional

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

[Target] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of

[Target] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...

[CodeGen] Move instruction predicate verification to emitInstruction

D25618 added a method to verify the instruction predicates for an
emitted instruction, through verifyInstructionPredicates added

[CodeGen] Move instruction predicate verification to emitInstruction

D25618 added a method to verify the instruction predicates for an
emitted instruction, through verifyInstructionPredicates added into
<Target>MCCodeEmitter::encodeInstruction. This is a very useful idea,
but the implementation inside MCCodeEmitter made it only fire for object
files, not assembly which most of the llvm test suite uses.

This patch moves the code into the <Target>_MC::verifyInstructionPredicates
method, inside the InstrInfo. The allows it to be called from other
places, such as in this patch where it is called from the
<Target>AsmPrinter::emitInstruction methods which should trigger for
both assembly and object files. It can also be called from other places
such as verifyInstruction, but that is not done here (it tends to catch
errors earlier, but in reality just shows all the mir tests that have
incorrect feature predicates). The interface was also simplified
slightly, moving computeAvailableFeatures into the function so that it
does not need to be called externally.

The ARM, AMDGPU (but not R600), AVR, Mips and X86 backends all currently
show errors in the test-suite, so have been disabled with FIXME
comments.

Recommitted with some fixes for the leftover MCII variables in release
builds.

Differential Revision: https://reviews.llvm.org/D129506

show more ...

Revert "Move instruction predicate verification to emitInstruction"

This reverts commit e2fb8c0f4b940e0285ee36c112469fa75d4b60ff as it does
not build for Release builds, and some buildbots are givin

Revert "Move instruction predicate verification to emitInstruction"

This reverts commit e2fb8c0f4b940e0285ee36c112469fa75d4b60ff as it does
not build for Release builds, and some buildbots are giving more warning
than I saw locally. Reverting to fix those issues.

show more ...

Move instruction predicate verification to emitInstruction

D25618 added a method to verify the instruction predicates for an
emitted instruction, through verifyInstructionPredicates added into
<Targ

Move instruction predicate verification to emitInstruction

D25618 added a method to verify the instruction predicates for an
emitted instruction, through verifyInstructionPredicates added into
<Target>MCCodeEmitter::encodeInstruction. This is a very useful idea,
but the implementation inside MCCodeEmitter made it only fire for object
files, not assembly which most of the llvm test suite uses.

This patch moves the code into the <Target>_MC::verifyInstructionPredicates
method, inside the InstrInfo. The allows it to be called from other
places, such as in this patch where it is called from the
<Target>AsmPrinter::emitInstruction methods which should trigger for
both assembly and object files. It can also be called from other places
such as verifyInstruction, but that is not done here (it tends to catch
errors earlier, but in reality just shows all the mir tests that have
incorrect feature predicates). The interface was also simplified
slightly, moving computeAvailableFeatures into the function so that it
does not need to be called externally.

The ARM, AMDGPU (but not R600), AVR, Mips and X86 backends all currently
show errors in the test-suite, so have been disabled with FIXME
comments.

Differential Revision: https://reviews.llvm.org/D129506

show more ...

[ARM] Undeprecate complex IT blocks

AArch32/Armv8A introduced the performance deprecation of certain patterns
of IT instructions. After some debate internal to ARM, this is now being
reverted; i.e

[ARM] Undeprecate complex IT blocks

AArch32/Armv8A introduced the performance deprecation of certain patterns
of IT instructions. After some debate internal to ARM, this is now being
reverted; i.e. no IT instruction patterns are performance deprecated
anymore, as the perfomance degredation is not significant enough.

This reverts the following:

"ARMv8-A deprecates some uses of the T32 IT instruction. All uses of
IT that apply to instructions other than a single subsequent 16-bit
instruction from a restricted set are deprecated, as are explicit
references to the PC within that single 16-bit instruction. This permits
the non-deprecated forms of IT and subsequent instructions to be treated
as a single 32-bit conditional instruction."

The deprecation no longer applies, but the behaviour may be controlled
by the -arm-restrict-it and -arm-no-restrict-it command-line options,
with the latter being the default. No warnings about complex IT blocks
will be generated.

Reviewed By: dmgreen

Differential Revision: https://reviews.llvm.org/D118044

show more ...

[Target] Use range-based for loops (NFC)

Move TargetRegistry.(h|cpp) from Support to MC

This moves the registry higher in the LLVM library dependency stack.
Every client of the target registry needs to link against MC anyway to
actually us

Move TargetRegistry.(h|cpp) from Support to MC

This moves the registry higher in the LLVM library dependency stack.
Every client of the target registry needs to link against MC anyway to
actually use the target, so we might as well move this out of Support.

This allows us to ensure that Support doesn't have includes from MC/*.

Differential Revision: https://reviews.llvm.org/D111454

show more ...

[ARM][llvm-objdump] Annotate PC-relative memory operands of VLDR instructions

This extends D105979 and adds support for VLDR instructions.

Differential Revision: https://reviews.llvm.org/D105980

[ARM][llvm-objdump] Annotate PC-relative memory operands

This implements `MCInstrAnalysis::evaluateMemoryOperandAddress()` for
Arm so that the disassembler can print the target address of memory
ope

[ARM][llvm-objdump] Annotate PC-relative memory operands

This implements `MCInstrAnalysis::evaluateMemoryOperandAddress()` for
Arm so that the disassembler can print the target address of memory
operands that use PC+immediate addressing.

Differential Revision: https://reviews.llvm.org/D105979

show more ...

[ARMInstPrinter] Print the target address of a branch instruction

This follows other patches that changed printing immediate values of
branch instructions to target addresses, see D76580 (x86), D765

[ARMInstPrinter] Print the target address of a branch instruction

This follows other patches that changed printing immediate values of
branch instructions to target addresses, see D76580 (x86), D76591 (PPC),
D77853 (AArch64).

As observing immediate values might sometimes be useful, they are
printed as comments for branch instructions.

// llvm-objdump -d output (before)
000200b4 <_start>:
200b4: ff ff ff fa blx #-4 <thumb>
000200b8 <thumb>:
200b8: ff f7 fc ef blx #-8 <_start>

// llvm-objdump -d output (after)
000200b4 <_start>:
200b4: ff ff ff fa blx 0x200b8 <thumb> @ imm = #-4
000200b8 <thumb>:
200b8: ff f7 fc ef blx 0x200b4 <_start> @ imm = #-8

// GNU objdump -d.
000200b4 <_start>:
200b4: faffffff blx 200b8 <thumb>
000200b8 <thumb>:
200b8: f7ff effc blx 200b4 <_start>

Differential Revision: https://reviews.llvm.org/D104701

show more ...

[objdump][ARM] Fix evaluating the target address of a Thumb BLX(i)

The instruction can be 16-bit aligned while targeting 32-bit aligned
code. To calculate the target address correctly, the address o

[objdump][ARM] Fix evaluating the target address of a Thumb BLX(i)

The instruction can be 16-bit aligned while targeting 32-bit aligned
code. To calculate the target address correctly, the address of the
instruction has to be adjusted.

Differential Revision: https://reviews.llvm.org/D104446

show more ...

[objdump][ARM] Use correct offset when printing ARM/Thumb branch targets

llvm-objdump only uses one MCInstrAnalysis object, so if ARM and Thumb
code is mixed in one object, or if an object is disass

[objdump][ARM] Use correct offset when printing ARM/Thumb branch targets

llvm-objdump only uses one MCInstrAnalysis object, so if ARM and Thumb
code is mixed in one object, or if an object is disassembled without
explicitly setting the triple to match the ISA used, then branch and
call targets will be printed incorrectly.

This could be fixed by creating two MCInstrAnalysis objects in
llvm-objdump, like we currently do for SubtargetInfo. However, I don't
think there's any reason we need two separate sub-classes of
MCInstrAnalysis, so instead these can be merged into one, and the ISA
determined by checking the opcode of the instruction.

Differential revision: https://reviews.llvm.org/D97766

show more ...

[ARM] do not consider sp as deprecated for ldm/stm

Early versions of the ARMv7 reference manuals considered the sp register
as a deprecated register for ldm/stm familiy of instructions. However,
lat

[ARM] do not consider sp as deprecated for ldm/stm

Early versions of the ARMv7 reference manuals considered the sp register
as a deprecated register for ldm/stm familiy of instructions. However,
later versions such as ARM DDI 0406C.d added a note to the Appendix:

D9.3 Use of the SP as a general-purpose register
Most ARM instructions, unlike Thumb instructions, provide exactly the
same access to the SP as to R0-R12. This means that it is possible to
use the SP as a general-purpose register. Earlier issues of this manual
deprecated the use of SP in an ARM instruction, in any way that is
deprecated, not permitted, or not possible in the corresponding
Thumb instruction. However, user feedback indicates a number of cases
where these instructions are useful. Therefore, ARM no longer deprecates
these instruction uses.
Also Armv8 manuals no longer consider SP as deprecated register for ldm/
stm A32 instructions.

Furthermore, GNU as also does not print a deprecated warning when using
SP with those instructions.

Drop deprecation warning for pop/ldm/push/stm instructions.

Patch by: Stefan Agner.

Differential Revision: https://reviews.llvm.org/D82692

show more ...

[ARM][SchedModels] Convert IsLdstsoScaledPred to MCSchedPredicate

Differential revision: https://reviews.llvm.org/D89939

[ARM][SchedModels] Convert IsCPSRDefinedPred to MCSchedPredicate

Differential revision: https://reviews.llvm.org/D89460

[COFF][ARM] Fix CodeView for Windows on 32bit ARM targets.

Create the LLVM / CodeView register mappings for the 32-bit ARM Window targets.

Reviewed By: compnerd

Differential Revision: https://revi

[COFF][ARM] Fix CodeView for Windows on 32bit ARM targets.

Create the LLVM / CodeView register mappings for the 32-bit ARM Window targets.

Reviewed By: compnerd

Differential Revision: https://reviews.llvm.org/D89622

show more ...