[AVR] Always expand STDSPQRr & STDWSPQRr

Currently, STDSPQRr and STDWSPQRr are expanded only during
AVRFrameLowering - this means that if any of those instructions happen
to appear _outside_ of the

[AVR] Always expand STDSPQRr & STDWSPQRr

Currently, STDSPQRr and STDWSPQRr are expanded only during
AVRFrameLowering - this means that if any of those instructions happen
to appear _outside_ of the typical FrameSetup / FrameDestroy
context, they wouldn't get substituted, eventually leading to a crash:

```
LLVM ERROR: Not supported instr: <MCInst XXX <MCOperand Reg:1>
<MCOperand Imm:15> <MCOperand Reg:53>>
```

This commit fixes this issue by moving expansion of those two opcodes
into AVRExpandPseudo.

This bug was originally discovered due to the Rust compiler_builtins
library. Its 0.1.37 release contained a 128-bit software
division/remainder routine that exercised this buggy branch in the code.

Reviewed By: benshi001

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

show more ...

[AVR] Avoid reusing the same variable name (NFC)

Apparently GCC 5.4 (a supported compiler) has a bug where it will
use the "MachineInstr &MI" defined by the range-based for loop
to evaluate the for

[AVR] Avoid reusing the same variable name (NFC)

Apparently GCC 5.4 (a supported compiler) has a bug where it will
use the "MachineInstr &MI" defined by the range-based for loop
to evaluate the for loop expression. Pick a different variable
name to avoid this.

show more ...

[AVR] Fix atomicrmw result value

This patch fixes the atomicrmw result value to be the value before the
operation instead of the value after the operation. This was a bug, left
as a FIXME in the cod

[AVR] Fix atomicrmw result value

This patch fixes the atomicrmw result value to be the value before the
operation instead of the value after the operation. This was a bug, left
as a FIXME in the code (see https://reviews.llvm.org/D97127).

From the LangRef:

> The contents of memory at the location specified by the <pointer>
> operand are atomically read, modified, and written back. The original
> value at the location is returned.

Doing this expansion early allows the register allocator to arrange
registers in such a way that commutable operations are simply swapped
around as needed, which results in shorter code while still being
correct.

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

show more ...

[AVR] Do not clear r0 at interrupt entry

There is no reason to do this: it's a scratch register and can therefore
hold any arbitrary value. And because it is in an interrupt, this code
is performanc

[AVR] Do not clear r0 at interrupt entry

There is no reason to do this: it's a scratch register and can therefore
hold any arbitrary value. And because it is in an interrupt, this code
is performance critical so it should be as short as possible.

I believe r0 was cleared because of the following:

1. There used to be a bug that the cleared register was r0, not r1 as
it should have been.
2. This was fixed in https://reviews.llvm.org/D99467, but left the code
to clear r0.

This patch completes D99467 by removing the `clr r0` instruction.

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

show more ...

[AVR] Remove redundant dynalloca SP save/restore pass

I think this pass was previously used under the assumption that most
functions would not need a frame pointer and it would be more efficient
to

[AVR] Remove redundant dynalloca SP save/restore pass

I think this pass was previously used under the assumption that most
functions would not need a frame pointer and it would be more efficient
to store the old stack pointer in a regular register pair.

Unfortunately, right now we're forced to always reserve the Y register
as a frame pointer: whether or not this is needed is only known after
regsiter allocation at which point it doesn't make sense anymore to mark
it as non-reserved. Therefore, it makes sense to use the Y register to
store the old stack pointer in functions with dynamic allocas (with a
variable size or not in the entry block). Knowing this can make the code
around dynamic allocas a lot simpler: simply save/restore the frame
pointer.

This is especially relevant in functions that have a frame pointer
anyway (for example, because they have stack spills). The stack restore
in the epilogue will implicitly restore the old stack pointer, so there
is no need to store the old stack pointer separately. It even reduces
register pressure as a side effect.

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

show more ...

[NFC] Use Register instead of unsigned

[Target] Use llvm::reverse (NFC)

[Target] Use make_early_inc_range (NFC)

[llvm] Use drop_begin (NFC)

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

[AVR] Fix a bug in prologue of ISR

The r1 register should be cleared in prologue of ISR as it is used
as constant zero.

Reviewed By: dylanmckay

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

[AVR] Fix a bug in prologue of ISR

The r1 register should be cleared in prologue of ISR as it is used
as constant zero.

Reviewed By: dylanmckay

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

show more ...

[AVR] Fix lifeness issues in the AVR backend

This patch is a large number of small changes that should hopefully not
affect the generated machine code but are still important to get right
so that th

[AVR] Fix lifeness issues in the AVR backend

This patch is a large number of small changes that should hopefully not
affect the generated machine code but are still important to get right
so that the machine verifier won't complain about them.

The llvm/test/CodeGen/AVR/pseudo/*.mir changes are also necessary
because without the liveins the used registers are considered undefined
by the machine verifier and it will complain about them.

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

show more ...

[AVR] fix interrupt stack pointer restoration

This patch fixes a corruption of the stack pointer and several registers in any AVR interrupt with non-empty stack frame. Previously, the callee-saved

[AVR] fix interrupt stack pointer restoration

This patch fixes a corruption of the stack pointer and several registers in any AVR interrupt with non-empty stack frame. Previously, the callee-saved registers were popped before restoring the stack pointer, causing the pointer math to use the wrong base value while also corrupting the caller's register. This change fixes the code to restore the stack pointer last before exiting the interrupt service routine.

https://bugs.llvm.org/show_bug.cgi?id=47253

Reviewed By: dylanmckay

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

Patch by Andrew Dona-Couch.

show more ...

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

[AVR] Remove faulty stack pushing behavior

An instruction like this will need to allocate some stack space for the
last parameter:

%x = call addrspace(1) i16 @bar(i64 undef, i64 undef, i16 undef,

[AVR] Remove faulty stack pushing behavior

An instruction like this will need to allocate some stack space for the
last parameter:

%x = call addrspace(1) i16 @bar(i64 undef, i64 undef, i16 undef, i16 0)

This worked fine when passing an actual value (in this case 0). However,
when passing undef, no value was pushed to the stack and therefore no
push instructions were created. This caused an unbalanced stack leading
to interesting results.

This commit fixes that by replacing the push logic with a regular stack
adjustment and stack-relative load/stores. This is less efficient but at
least it correctly compiles the code.

I can think of a few improvements in the future:

* The stack should have been adjusted in the function prologue when
there are no allocas in the function.
* Many (if not most) stack adjustments can be replaced by
pushing/popping the values directly. Exactly like the previous code
attempted but didn't do correctly.
* Small stack adjustments can be done more efficiently with a few
push/pop instructions (pushing/popping bogus values), both for code
size and for speed.

All in all, as long as there are no allocas in the function I think that
it is almost always more efficient to emit regular push/pop
instructions. This is however left for future optimizations.

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

show more ...

[AVR] Fix stack size in functions with a frame pointer

This patch fixes a bug in stack save/restore code. Because the frame
pointer was saved/restored manually (not by marking it as clobbered) the
S

[AVR] Fix stack size in functions with a frame pointer

This patch fixes a bug in stack save/restore code. Because the frame
pointer was saved/restored manually (not by marking it as clobbered) the
StackSize variable was not updated accordingly. Most code still worked,
but code that tried to load a parameter passed on the stack did not.

This commit fixes this by marking the frame pointer as a
callee-clobbered register. This will let it be saved without any effort
in prolog/epilog code and will make sure the correct address is
calculated for loading parameters that are passed on the stack.

This approach is used by most other targets (such as X86, AArch64 and
RISC-V).

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

show more ...

Remove unused variable

[AVR] Generalize the previous interrupt bugfix to signal handlers too

[AVR] Respect the 'interrupt' function attribute

In the past, AVR functions were only lowered with interrupt-specific
machine code if the function was defined with the "avr-interrupt" or
"avr-signal

[AVR] Respect the 'interrupt' function attribute

In the past, AVR functions were only lowered with interrupt-specific
machine code if the function was defined with the "avr-interrupt" or
"avr-signal" calling conventions.

This patch modifies the backend so that if the function does not have a
special calling convention, but does have an "interrupt" attribute,
that function is interpreted as a function with interrupts.

This also extracts the "is this function an interrupt" logic from
several disparate places in the backend into one AVRMachineFunctionInfo
attribute.

Bug found by Wilhelm Meier.

show more ...

[Alignment][NFC] Use TFL::getStackAlign()

Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/1

[Alignment][NFC] Use TFL::getStackAlign()

Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790

Reviewers: courbet

Subscribers: dylanmckay, sdardis, nemanjai, hiraditya, kbarton, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, Jim, lenary, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, llvm-commits

Tags: #llvm

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

show more ...

[AVR][NFC] Use Register instead of unsigned

Summary: Use Register type for variables instead of unsigned type.

Reviewers: dylanmckay

Reviewed By: dylanmckay

Subscribers: hiraditya, llvm-commits

[AVR][NFC] Use Register instead of unsigned

Summary: Use Register type for variables instead of unsigned type.

Reviewers: dylanmckay

Reviewed By: dylanmckay

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

show more ...

ArrayRef'ize restoreCalleeSavedRegisters. NFCI.

restoreCalleeSavedRegisters can mutate the contents of the
CalleeSavedInfos, so use a MutableArrayRef.

ArrayRef'ize spillCalleeSavedRegisters. NFCI.

[Alignment][NFC] Deprecate Align::None()

Summary:
This is a follow up on https://reviews.llvm.org/D71473#inline-647262.
There's a caveat here that `Align(1)` relies on the compiler understanding of

[Alignment][NFC] Deprecate Align::None()

Summary:
This is a follow up on https://reviews.llvm.org/D71473#inline-647262.
There's a caveat here that `Align(1)` relies on the compiler understanding of `Log2_64` implementation to produce good code. One could use `Align()` as a replacement but I believe it is less clear that the alignment is one in that case.

Reviewers: xbolva00, courbet, bollu

Subscribers: arsenm, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, hiraditya, kbarton, jrtc27, atanasyan, jsji, Jim, kerbowa, cfe-commits, llvm-commits

Tags: #clang, #llvm

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

show more ...

[Alignment][NFC] Use Align for TargetFrameLowering/Subtarget

Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/l

[Alignment][NFC] Use Align for TargetFrameLowering/Subtarget

Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790

Reviewers: courbet

Subscribers: jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, hiraditya, aheejin, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, jsji, Jim, lenary, s.egerton, pzheng, llvm-commits

Tags: #llvm

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

llvm-svn: 375084

show more ...