[Target] Remove unused includes (NFC) (#116577)

Identified with misc-include-cleaner.

[NFC] Update function names in MCTargetAsmParser.h (#108643)

Update function names to adhere to LLVM coding standard.

[AVR] Use MCRegister in AsmParser. NFC

[AVR] Fix parsing & emitting relative jumps (#106722)

Ever since 6859685a87ad093d60c8bed60b116143c0a684c7 (or, precisely,
84428dafc0941e3a31303fa1b286835ab2b8e234) relative jumps emitted by the
AV

[AVR] Fix parsing & emitting relative jumps (#106722)

Ever since 6859685a87ad093d60c8bed60b116143c0a684c7 (or, precisely,
84428dafc0941e3a31303fa1b286835ab2b8e234) relative jumps emitted by the
AVR codegen are off by two bytes - this pull request fixes it.

## Abstract

As compared to absolute jumps, relative jumps - such as rjmp, rcall or
brsh - have an implied `pc+2` behavior; that is, `jmp 100` is `pc =
100`, but `rjmp 100` gets understood as `pc = pc + 100 + 2`.

This is not reflected in the AVR codegen:


https://github.com/llvm/llvm-project/blob/f95026dbf66e353128a3a3d7b55f3e52d5985535/llvm/lib/Target/AVR/MCTargetDesc/AVRAsmBackend.cpp#L89

... which always emits relative jumps that are two bytes too far - or
rather it _would_ emit such jumps if not for this check:


https://github.com/llvm/llvm-project/blob/f95026dbf66e353128a3a3d7b55f3e52d5985535/llvm/lib/Target/AVR/MCTargetDesc/AVRAsmBackend.cpp#L517

... which causes most of the relative jumps to be actually resolved
late, by the linker, which applies the offsetting logic on its own,
hiding the issue within LLVM.

[Some time
ago](https://github.com/llvm/llvm-project/commit/697a162fa63df328ec9ca334636c5e85390b2bf0)
we've had a similar "jumps are off" problem that got solved by touching
`shouldForceRelocation()`, but I think that has worked only by accident.
It's exploited the fact that absolute vs relative jumps in the parsed
assembly can be distinguished through a "side channel" check relying on
the existence of labels (i.e. absolute jumps happen to named labels, but
relative jumps are anonymous, so to say). This was an alright idea back
then, but it got broken by 6859685a87ad093d60c8bed60b116143c0a684c7.

I propose a different approach:
- when emitting relative jumps, offset them by `-2` (well, `-1`,
strictly speaking, because those instructions rely on right-shifted
offset),
- when parsing relative jumps, treat `.` as `+2` and read `rjmp .+1234`
as `rjmp (1234 + 2)`.

This approach seems to be sound and now we generate the same assembly as
avr-gcc, which can be confirmed with:

```cpp
// avr-gcc test.c -O3 && avr-objdump -d a.out

int main() {
asm(
" foo:\n\t"
" rjmp .+2\n\t"
" rjmp .-2\n\t"
" rjmp foo\n\t"
" rjmp .+8\n\t"
" rjmp end\n\t"
" rjmp .+0\n\t"
" end:\n\t"
" rjmp .-4\n\t"
" rjmp .-6\n\t"
" x:\n\t"
" rjmp x\n\t"
" .short 0xc00f\n\t"
);
}
```

avr-gcc is also how I got the opcodes for all new tests like `inst-brbc.s`, so we should be good.

show more ...

[MC] Make `MCParsedAsmOperand::getReg()` return `MCRegister` (#86444)

[MC][AsmParser] Make `MatchRegisterName` return `MCRegister` (NFC) (#81408)

`MCRegister` is preferred over `unsigned` nowadays.

[MC] Change tryParseRegister to return ParseStatus (NFC)

This finishes the work of replacing OperandMatchResultTy with
ParseStatus, started in D154101.
As a drive-by change, rename some RegNo variab

[MC] Change tryParseRegister to return ParseStatus (NFC)

This finishes the work of replacing OperandMatchResultTy with
ParseStatus, started in D154101.
As a drive-by change, rename some RegNo variables to just Reg
(a leftover from the days when RegNo had 'unsigned' type).

show more ...

[AVR][BPF][Lanai][Xtensa] Replace OperandMatchResultTy with ParseStatus (NFC)

ParseStatus is slightly more convenient to use due to implicit
conversion from bool, which allows to do something like:

[AVR][BPF][Lanai][Xtensa] Replace OperandMatchResultTy with ParseStatus (NFC)

ParseStatus is slightly more convenient to use due to implicit
conversion from bool, which allows to do something like:
```
return Error(L, "msg");
```
when with MatchOperandResultTy it had to be:
```
Error(L, "msg");
return MatchOperand_ParseFail;
```
It also has more appropriate name since parse* methods are not only for
parsing operands.

Reviewed By: MaskRay

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

show more ...

[MC] Add three-state parseDirective as a replacement for ParseDirective

Conventionally, parsing methods return false on success and true on
error. However, directive parsing methods need a third sta

[MC] Add three-state parseDirective as a replacement for ParseDirective

Conventionally, parsing methods return false on success and true on
error. However, directive parsing methods need a third state: the
directive is not target specific. AsmParser::parseStatement detected
this case by using a fragile heuristic: if the target parser did not
consume any tokens, the directive is assumed to be not target-specific.

Some targets fail to follow the convention: they return success after
emitting an error or do not consume the entire line and return failure
on successful parsing. This was partially worked around by checking for
pending errors in parseStatement.

This patch tries to improve the situation by introducing parseDirective
method that returns ParseStatus -- three-state class. The new method
should eventually replace the old one returning bool.

ParseStatus is intentionally implicitly constructible from bool to allow
uses like `return Error(Loc, "message")`. It also has a potential to
replace OperandMatchResulTy as it is more convenient to use due to the
implicit construction from bool and more type safe.

Reviewed By: MaskRay

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

show more ...

[AVR] Fix some ambiguous cases in AsmParser

Some specific operands in specific instructions should be treated
as variables/symbols/labels, other than registers.

This patch fixes those ambiguous cas

[AVR] Fix some ambiguous cases in AsmParser

Some specific operands in specific instructions should be treated
as variables/symbols/labels, other than registers.

This patch fixes those ambiguous cases, such as "lds r25, r24",
which means loading the value inside symbol 'r24' into register 'r25'.

Fixes https://github.com/llvm/llvm-project/issues/58853

Reviewed by: aykevl

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

show more ...

[AVR][MC] Fix illegal operand forms.

These operands are illegal and rejected by avr-gcc.
subi r24, -lo8(symobl+offset)
sbci r25, -hi8(symobl+offset)

And their correct form should be
sub

[AVR][MC] Fix illegal operand forms.

These operands are illegal and rejected by avr-gcc.
subi r24, -lo8(symobl+offset)
sbci r25, -hi8(symobl+offset)

And their correct form should be
subi r24, lo8(-(symobl+offset))
sbci r25, hi8(-(symobl+offset))

Reviewed By: aykevl

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

show more ...

[MC] Use `MCRegister` instead of `unsigned` in `MCTargetAsmParser`

Reviewed By: MaskRay

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

[llvm] LLVM_FALLTHROUGH => [[fallthrough]]. NFC

With C++17 there is no Clang pedantic warning or MSVC C5051.

[AVR] Reject/Reserve R0~R15 on AVRTiny.

Reviewed By: aykevl, dylanmckay

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

[Target] Remove redundant member initialization (NFC)

Identified with readability-redundant-member-init.

Revert "[llvm] Remove redundant member initialization (NFC)"

This reverts commit fd4808887ee47f3ec8a030e9211169ef4fb094c3.

This patch causes gcc to issue a lot of warnings like:

warning: base cl

Revert "[llvm] Remove redundant member initialization (NFC)"

This reverts commit fd4808887ee47f3ec8a030e9211169ef4fb094c3.

This patch causes gcc to issue a lot of warnings like:

warning: base class ‘class llvm::MCParsedAsmOperand’ should be
explicitly initialized in the copy constructor [-Wextra]

show more ...

[llvm] Remove redundant member initialization (NFC)

Identified with readability-redundant-member-init.

[llvm] Use nullptr instead of 0 (NFC)

Identified with modernize-use-nullptr.

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 ...

[NFC] Run clang-format on llvm/lib/Trget/AVR/

The current inconsistency confuse contributors which coding guidlines to follow.
It would be better to have it consistent using clang-format tool.

Revi

[NFC] Run clang-format on llvm/lib/Trget/AVR/

The current inconsistency confuse contributors which coding guidlines to follow.
It would be better to have it consistent using clang-format tool.

Reviewed By: mhjacobson

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

show more ...

[llvm] Remove redundant calls to str() and c_str() (NFC)

Identified with readability-redundant-string-cstr.

[llvm] Don't include StringSwitch.h where unnecessary (NFC)

Don't dereference from a dyn_cast<>. NFCI.

Use cast<> instead which will assert if it fails and not just return null.

Fixes clang static analyzer warning.

[NFC] Add 'override' keyword where missing in include/ and lib/.

This fixes warnings raised by Clang's new -Wsuggest-override, in preparation for enabling that warning in the LLVM build. This patch

[NFC] Add 'override' keyword where missing in include/ and lib/.

This fixes warnings raised by Clang's new -Wsuggest-override, in preparation for enabling that warning in the LLVM build. This patch also removes the virtual keyword where redundant, but only in places where doing so improves consistency within a given file. It also removes a couple unnecessary virtual destructor declarations in derived classes where the destructor inherited from the base class is already virtual.

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

show more ...

[MCStreamer] De-capitalize EmitValue EmitIntValue{,InHex}