[ARM][Thumb] Command-line option to ensure AAPCS compliant Frame Records

Currently the a AAPCS compliant frame record is not always created for
functions when it should. Although a consistent frame

[ARM][Thumb] Command-line option to ensure AAPCS compliant Frame Records

Currently the a AAPCS compliant frame record is not always created for
functions when it should. Although a consistent frame record might not
be required in some cases, there are still scenarios where applications
may want to make use of the call hierarchy made available trough it.

In order to enable the use of AAPCS compliant frame records whilst keep
backwards compatibility, this patch introduces a new command-line option
(`-mframe-chain=[none|aapcs|aapcs+leaf]`) for Aarch32 and Thumb backends.
The option allows users to explicitly select when to use it, and is also
useful to ensure the extra overhead introduced by the frame records is
only introduced when necessary, in particular for Thumb targets.

Reviewed By: efriedma

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

show more ...

Revert "[ARM][Thumb] Command-line option to ensure AAPCS compliant Frame Records AND [NFC][Thumb] Update frame-chain codegen test to use thumbv6m"

This reverts commit 7625e01d661644a560884057755d48a

Revert "[ARM][Thumb] Command-line option to ensure AAPCS compliant Frame Records AND [NFC][Thumb] Update frame-chain codegen test to use thumbv6m"

This reverts commit 7625e01d661644a560884057755d48a0da8b77b4 and
dependent cbcce82ef6b512d97e92a319a75a03e997c844e1.

Commit 7625e01d661644a560884057755d48a0da8b77b4 causes some new codegen test
failures under asan, e.g., CodeGen/ARM/execute-only.ll:
https://lab.llvm.org/buildbot/#/builders/5/builds/24659/steps/15/logs/stdio.

show more ...

[ARM][Thumb] Command-line option to ensure AAPCS compliant Frame Records

Currently the a AAPCS compliant frame record is not always created for
functions when it should. Although a consistent frame

[ARM][Thumb] Command-line option to ensure AAPCS compliant Frame Records

Currently the a AAPCS compliant frame record is not always created for
functions when it should. Although a consistent frame record might not
be required in some cases, there are still scenarios where applications
may want to make use of the call hierarchy made available trough it.

In order to enable the use of AAPCS compliant frame records whilst keep
backwards compatibility, this patch introduces a new command-line option
(`-mframe-chain=[none|aapcs|aapcs+leaf]`) for Aarch32 and Thumb backends.
The option allows users to explicitly select when to use it, and is also
useful to ensure the extra overhead introduced by the frame records is
only introduced when necessary, in particular for Thumb targets.

Reviewed By: efriedma

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

show more ...

[ARM] Fix "local variable is initialized but not referenced" MSVX warning. NFC

Revert "[ARM][Thumb] Command-line option to ensure AAPCS compliant Frame Records"

Reverting change due to test failure.

This reverts commit 6119053dab67129eb1700dbf36db3524dd3e421f.

[ARM][Thumb] Command-line option to ensure AAPCS compliant Frame Records

Currently the a AAPCS compliant frame record is not always created for
functions when it should. Although a consistent frame

[ARM][Thumb] Command-line option to ensure AAPCS compliant Frame Records

Currently the a AAPCS compliant frame record is not always created for
functions when it should. Although a consistent frame record might not
be required in some cases, there are still scenarios where applications
may want to make use of the call hierarchy made available trough it.

In order to enable the use of AAPCS compliant frame records whilst keep
backwards compatibility, this patch introduces a new command-line option
(`-mframe-chain=[none|aapcs|aapcs+leaf]`) for Aarch32 and Thumb backends.
The option allows users to explicitly select when to use it, and is also
useful to ensure the extra overhead introduced by the frame records is
only introduced when necessary, in particular for Thumb targets.

Reviewed By: efriedma

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

show more ...

[NFC][Thumb1] Use FrameDestroy flag to identify epilog instructions

Simiarly to what's done on both ARM's and AArch64's frame lowering code,
this updates Thumb1FrameLowering to use the FrameDestroy

[NFC][Thumb1] Use FrameDestroy flag to identify epilog instructions

Simiarly to what's done on both ARM's and AArch64's frame lowering code,
this updates Thumb1FrameLowering to use the FrameDestroy Machine
Instruction flag to identify instructions inserted as part of the epilog
instead of relying on assumptions about specific machine instructions.

Reviewed By: efriedma

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

show more ...

[NFC] Use Register instead of unsigned

[Target] Use llvm::reverse (NFC)

[NFC] Rename MachineFunction::deleteMachineInstr (coding style)

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

[ARM] Change a couple of instances of LiveRegs.contains to !LiveRegs.available

This changes a couple of calls to LiveRegs.contains to
!LiveRegs.available, one in Thumb1FrameLoweringInfo (which modif

[ARM] Change a couple of instances of LiveRegs.contains to !LiveRegs.available

This changes a couple of calls to LiveRegs.contains to
!LiveRegs.available, one in Thumb1FrameLoweringInfo (which modifies a
test to look more correct to me, given r7 should be the frame pointer so
is not available), and another in the ARMLoadStoreOptimizer, that I
don't have a test for, it was just found by inspection.

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

show more ...

[ARM][NFC] Tidy up subtarget frame pointer routines

getFramePointerReg only depends on information in ARMSubtarget,
so move it in there so it can be accessed from more places.

Make use of ARMSubtar

[ARM][NFC] Tidy up subtarget frame pointer routines

getFramePointerReg only depends on information in ARMSubtarget,
so move it in there so it can be accessed from more places.

Make use of ARMSubtarget::getFramePointerReg to remove duplicated code.

The main use of useR7AsFramePointer is getFramePointerReg, so inline it.

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

show more ...

[NFC][CodeGen] Tidy up TargetRegisterInfo stack realignment functions

Currently needsStackRealignment returns false if canRealignStack returns false.
This means that the behavior of needsStackRealig

[NFC][CodeGen] Tidy up TargetRegisterInfo stack realignment functions

Currently needsStackRealignment returns false if canRealignStack returns false.
This means that the behavior of needsStackRealignment does not correspond to
it's name and description; a function might need stack realignment, but if it
is not possible then this function returns false. Furthermore,
needsStackRealignment is not virtual and therefore some backends have made use
of canRealignStack to indicate whether a function needs stack realignment.

This patch attempts to clarify the situation by separating them and introducing
new names:

- shouldRealignStack - true if there is any reason the stack should be
realigned

- canRealignStack - true if we are still able to realign the stack (e.g. we
can still reserve/have reserved a frame pointer)

- hasStackRealignment = shouldRealignStack && canRealignStack (not target
customisable)

Targets can now override shouldRealignStack to indicate that stack realignment
is required.

This change will make it easier in a future change to handle the case where we
need to realign the stack but can't do so (for example when the register
allocator creates an aligned spill after the frame pointer has been
eliminated).

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

Change-Id: Ib9a4d21728bf9d08a545b4365418d3ffe1af4d87

show more ...

[MC] Change MCCFIInstruction::createDefCfaOffset to cfiDefCfaOffset which does not negate Offset

The negative Offset has caused a bunch of problems and confused quite a
few call sites. Delete the un

[MC] Change MCCFIInstruction::createDefCfaOffset to cfiDefCfaOffset which does not negate Offset

The negative Offset has caused a bunch of problems and confused quite a
few call sites. Delete the unneeded negation and fix all call sites.

show more ...

[MC] Change MCCFIInstruction::createDefCfa to cfiDefCfa which does not negate Offset

The negative Offset has caused a bunch of problems and confused quite a
few call sites. Delete the unneeded negat

[MC] Change MCCFIInstruction::createDefCfa to cfiDefCfa which does not negate Offset

The negative Offset has caused a bunch of problems and confused quite a
few call sites. Delete the unneeded negation and fix all call sites.

show more ...

Re-commit: [ARM] CMSE code generation

This patch implements the final bits of CMSE code generation:

* emit special linker symbols

* restrict parameter passing to no use memory

* emit BXNS and BLX

Re-commit: [ARM] CMSE code generation

This patch implements the final bits of CMSE code generation:

* emit special linker symbols

* restrict parameter passing to no use memory

* emit BXNS and BLXNS instructions for returns from non-secure entry
functions, and non-secure function calls, respectively

* emit code to save/restore secure floating-point state around calls
to non-secure functions

* emit code to save/restore non-secure floating-pointy state upon
entry to non-secure entry function, and return to non-secure state

* emit code to clobber registers not used for arguments and returns

* when switching to no-secure state

Patch by Momchil Velikov, Bradley Smith, Javed Absar, David Green,
possibly others.

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

show more ...

Revert "[ARM] CMSE code generation"

This reverts commit 7cbbf89d230d46c3de9a7affc29b23f08c4377a1.

The regression tests fail with the expensive checks.

[ARM] CMSE code generation

This patch implements the final bits of CMSE code generation:

* emit special linker symbols

* restrict parameter passing to not use memory

* emit BXNS and BLXNS instruc

[ARM] CMSE code generation

This patch implements the final bits of CMSE code generation:

* emit special linker symbols

* restrict parameter passing to not use memory

* emit BXNS and BLXNS instructions for returns from non-secure entry
functions, and non-secure function calls, respectively

* emit code to save/restore secure floating-point state around calls
to non-secure functions

* emit code to save/restore non-secure floating-pointy state upon
entry to non-secure entry function, and return to non-secure state

* emit code to clobber registers not used for arguments and returns
when switching to no-secure state

Patch by Momchil Velikov, Bradley Smith, Javed Absar, David Green,
possibly others.

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

show more ...

[ARM] unwinding .pad instructions missing in execute-only prologue

If the stack pointer is altered for local variables and we are generating
Thumb2 execute-only code the .pad directive is missing.

[ARM] unwinding .pad instructions missing in execute-only prologue

If the stack pointer is altered for local variables and we are generating
Thumb2 execute-only code the .pad directive is missing.

Usually the size of the adjustment is stored in a PC-relative location
and loaded into a register which is then added to the stack pointer.
However when we are generating execute-only code code the size of the
adjustment is instead generated using the MOVW/MOVT instruction pair.

As a by product of handling the execute-only case this also fixes an
existing issue that in the none execute-only case the .pad directive was
generated against the load of the constant to a register instruction,
instead of the instruction which adds the register to the stack pointer.

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

show more ...

Revert "[IPRA][ARM] Spill extra registers at -Oz"

Reverting because this is causing failures on bots with expensive checks
enabled.

This reverts commit 73cea83a6f5ab521edf3cccfc603534776d691ec.

[Alignment][NFC] Use llvmTargetFrameLowering::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/ll

[Alignment][NFC] Use llvmTargetFrameLowering::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

Reviewed By: courbet

Subscribers: wuzish, arsenm, jyknight, nemanjai, jvesely, nhaehnle, hiraditya, kbarton, fedor.sergeev, jrtc27, kerbowa, llvm-commits

Tags: #llvm

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

show more ...

[IPRA][ARM] Spill extra registers at -Oz

When optimising for code size at the expense of performance, it is often
worth saving and restoring some of r0-r3, if IPRA will be able to take
advantage of

[IPRA][ARM] Spill extra registers at -Oz

When optimising for code size at the expense of performance, it is often
worth saving and restoring some of r0-r3, if IPRA will be able to take
advantage of them. This doesn't cost any extra code size if we already
have a PUSH/POP pair, and increases the number of available registers
across any calls to the function.

We already have an optimisation which tries fold the subtract/add of the
SP into the PUSH/POP by using extra registers, which somewhat conflicts
with this. I've made the new optimisation less aggressive in cases where
the existing one is likely to trigger, which gives better results than
either of these optimisations by themselves.

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

show more ...

[Alignment][NFC] Deprecate getMaxAlignment

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/

[Alignment][NFC] Deprecate getMaxAlignment

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, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, hiraditya, aheejin, kbarton, fedor.sergeev, 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, kerbowa, llvm-commits

Tags: #llvm

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

show more ...

ArrayRef'ize restoreCalleeSavedRegisters. NFCI.

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