[X86] Move target-generic code into CodeGen [NFC]

This code is the same for all platforms.

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

MachineModuleInfo: Remove UsesMorestackAddr

This is x86 specific, and adds statefulness to
MachineModuleInfo. Instead of explicitly tracking this, infer if we
need to declare the symbol based on the

MachineModuleInfo: Remove UsesMorestackAddr

This is x86 specific, and adds statefulness to
MachineModuleInfo. Instead of explicitly tracking this, infer if we
need to declare the symbol based on the reference previously inserted.

This produces a small change in the output due to the move from
AsmPrinter::doFinalization to X86's emitEndOfAsmFile. This will now be
moved relative to other end of file fields, which I'm assuming doesn't
matter (e.g. the __morestack_addr declaration is now after the
.note.GNU-split-stack part)

This also produces another small change in code if the module happened
to define/declare __morestack_addr, but I assume that's invalid and
doesn't really matter.

show more ...

MachineModuleInfo: Move HasSplitStack handling to AsmPrinter

This is used to emit one field in doFinalization for the module. We
can accumulate this when emitting all individual functions directly i

MachineModuleInfo: Move HasSplitStack handling to AsmPrinter

This is used to emit one field in doFinalization for the module. We
can accumulate this when emitting all individual functions directly in
the AsmPrinter, rather than accumulating additional state in
MachineModuleInfo.

Move the special case behavior predicate into MachineFrameInfo to
share it. This now promotes it to generic behavior. I'm assuming this
is fine because no other target implements adjustForSegmentedStacks,
or has tests using the split-stack attribute.

show more ...

[X86] Set frame-setup/frame-destroy on prologue/epilogue CFI instructions

This approach is used by AArch64/RISCV to make frame-setup/frame-destroy
instructions contiguous instead of being interleave

[X86] Set frame-setup/frame-destroy on prologue/epilogue CFI instructions

This approach is used by AArch64/RISCV to make frame-setup/frame-destroy
instructions contiguous instead of being interleaved by CFI instructions. Code
checking `MBBI->getFlag(MachineInstr::FrameSetup) || MBBI->isCFIInstruction()`
can be simplified to just check FrameSetup.

This helps locate all CFI instructions in the prologue, which can be handy to use
.cfi_remember_state/.cfi_restore_state to decrease unwind table size (D114545).

Reviewed By: RKSimon

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

show more ...

Cleanup codegen includes

This is a (fixed) recommit of https://reviews.llvm.org/D121169

after: 1061034926
before: 1063332844

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-in

Cleanup codegen includes

This is a (fixed) recommit of https://reviews.llvm.org/D121169

after: 1061034926
before: 1063332844

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D121681

show more ...

Revert "Cleanup codegen includes"

This reverts commit 7f230feeeac8a67b335f52bd2e900a05c6098f20.
Breaks CodeGenCUDA/link-device-bitcode.cu in check-clang,
and many LLVM tests, see comments on https:/

Revert "Cleanup codegen includes"

This reverts commit 7f230feeeac8a67b335f52bd2e900a05c6098f20.
Breaks CodeGenCUDA/link-device-bitcode.cu in check-clang,
and many LLVM tests, see comments on https://reviews.llvm.org/D121169

show more ...

Cleanup codegen includes

after: 1061034926
before: 1063332844

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

[X86] Zero out the 32-bit GPRs explicitly

This should ensure that only the 32-bit xors are emitted, and not the
64-bit xors.

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

[X86] Only force FP usage in the presence of pushf/popf on Win64

This ensures that the Windows unwinder will work at every instruction
boundary, and allows other targets to read and write flags with

[X86] Only force FP usage in the presence of pushf/popf on Win64

This ensures that the Windows unwinder will work at every instruction
boundary, and allows other targets to read and write flags without
setting up a frame pointer.

Fixes GH-46875

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

show more ...

[X86] Specify Undef for the registers we xor

Fixes expensive check failures from D110869.

[X86] Implement -fzero-call-used-regs option

The "-fzero-call-used-regs" option tells the compiler to zero out
certain registers before the function returns. It's also available as a
function attrib

[X86] Implement -fzero-call-used-regs option

The "-fzero-call-used-regs" option tells the compiler to zero out
certain registers before the function returns. It's also available as a
function attribute: zero_call_used_regs.

The two upper categories are:

- "used": Zero out used registers.
- "all": Zero out all registers, whether used or not.

The individual options are:

- "skip": Don't zero out any registers. This is the default.
- "used": Zero out all used registers.
- "used-arg": Zero out used registers that are used for arguments.
- "used-gpr": Zero out used registers that are GPRs.
- "used-gpr-arg": Zero out used GPRs that are used as arguments.
- "all": Zero out all registers.
- "all-arg": Zero out all registers used for arguments.
- "all-gpr": Zero out all GPRs.
- "all-gpr-arg": Zero out all GPRs used for arguments.

This is used to help mitigate Return-Oriented Programming exploits.

Reviewed By: nickdesaulniers

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

show more ...

[NFC] Use Register instead of unsigned

[CodeGen] Rename emitCalleeSavedFrameMoves

This diff renames emitCalleeSavedFrameMoves to avoid conflicts with
non-virtual methods of derived classes having the same name but different semantics.
E.

[CodeGen] Rename emitCalleeSavedFrameMoves

This diff renames emitCalleeSavedFrameMoves to avoid conflicts with
non-virtual methods of derived classes having the same name but different semantics.
E.g. the class AArch64FrameLowering used to have (non-virtual) "emitCalleeSavedFrameMoves"
but it started to override TargetFrameLowering::emitCalleeSavedFrameMoves after
https://github.com/llvm/llvm-project/commit/c3e6555616 though its usage and semantics didn't change.
P.S. for x86 there was no conflict because the signature of
non-virtual X86FrameLowering::emitCalleeSavedFrameMoves is different

Test plan: make check-all

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

show more ...

[X86] add dwarf information for loop stack probe

This patch is based on https://reviews.llvm.org/D99585.

While inside the stack probing loop, temporarily change the CFA
to be based on r11/eax, whic

[X86] add dwarf information for loop stack probe

This patch is based on https://reviews.llvm.org/D99585.

While inside the stack probing loop, temporarily change the CFA
to be based on r11/eax, which are already used to hold the loop bound.
The stack pointer cannot be used for CFI here as it changes during the loop,
so it does not have a constant offset to the CFA.

Co-authored-by: YangKeao <[email protected]>

Reviewed By: nagisa

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

show more ...

[X86] Improve selection of the mov instruction in FrameLowering

MOV64ri results in a significantly longer encoding, and use of this
operator is fairly avoidable as we can always check the size of th

[X86] Improve selection of the mov instruction in FrameLowering

MOV64ri results in a significantly longer encoding, and use of this
operator is fairly avoidable as we can always check the size of the
immediate we're using.

This is an updated version of D99045.

Co-authored-by: Simonas Kazlauskas <[email protected]>

Reviewed By: craig.topper

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

show more ...

[Target] Use llvm::reverse (NFC)

[DebugInfo][InstrRef][X86] Instrument expanded DYN_ALLOCAs

If we have a DYN_ALLOCA_* instruction, it will eventually be expanded to a
stack probe and subtract-from-SP. Add debug-info instrumentation

[DebugInfo][InstrRef][X86] Instrument expanded DYN_ALLOCAs

If we have a DYN_ALLOCA_* instruction, it will eventually be expanded to a
stack probe and subtract-from-SP. Add debug-info instrumentation to
X86FrameLowering::emitStackProbe so that it can redirect debug-info for the
DYN_ALLOCA to the lowered stack probe. In practice, this means putting an
instruction number label either the call instruction to _chkstk for win32,
or more commonly on the subtract from SP instruction. The two tests added
cover both of these cases.

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

show more ...

[DebugInfo][InstrRef] Cope with win32 calls changing SP in LiveDebugValues

Almost all of the time, call instructions don't actually lead to SP being
different after they return. An exception is win3

[DebugInfo][InstrRef] Cope with win32 calls changing SP in LiveDebugValues

Almost all of the time, call instructions don't actually lead to SP being
different after they return. An exception is win32's _chkstk, which which
implements stack probes. We need to recognise that as modifying SP, so
that copies of the value are tracked as distinct vla pointers.

This patch adds a target frame-lowering hook to see whether stack probe
functions will modify the stack pointer, store that in an internal flag,
and if it's true then scan CALL instructions to see whether they're a
stack probe. If they are, recognise them as defining a new stack-pointer
value.

The added test exercises this behaviour: two calls to _chkstk should be
considered as producing two different values.

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

show more ...

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

[X86][AMX] Don't emit tilerelease for old AMX instrisic.

We should avoid mixing old AMX instrinsic with new AMX intrinsic. For
old AMX intrinsic, user is responsible for invoking tile release. This

[X86][AMX] Don't emit tilerelease for old AMX instrisic.

We should avoid mixing old AMX instrinsic with new AMX intrinsic. For
old AMX intrinsic, user is responsible for invoking tile release. This
patch is to check if there is any tile config generated by compiler. If
so it emit tilerelease instruction, otherwise it don't emit the
instruction.

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

show more ...

[Target, Transforms] Use StringRef::contains (NFC)

Add a command-line flag to control the Swift extended async frame info.

Introduce a new command-line flag `-swift-async-fp={auto|always|never}`
that controls how code generation sets the Swift exte

Add a command-line flag to control the Swift extended async frame info.

Introduce a new command-line flag `-swift-async-fp={auto|always|never}`
that controls how code generation sets the Swift extended async frame
info bit. There are three possibilities:

* `auto`: which determines how to set the bit based on deployment target, either
statically or dynamically via `swift_async_extendedFramePointerFlags`.
* `always`: the default, always set the bit statically, regardless of deployment
target.
* `never`: never set the bit, regardless of deployment target.

Patch by Doug Gregor <[email protected]>

Reviewed By: doug.gregor

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

show more ...

SwiftAsync: use runtime-provided flag for extended frame if back-deploying

When back-deploying Swift async code we can't always toggle the flag showing an
extended frame is present because it will c

SwiftAsync: use runtime-provided flag for extended frame if back-deploying

When back-deploying Swift async code we can't always toggle the flag showing an
extended frame is present because it will confuse unwinders on systems released
before this feature. So in cases where the code might run there, we `or` in a
mask provided by the runtime (as an absolute symbol) telling us whether the
unwinders can cope.

When deploying only for newer OSs, we can still hard-code the bit-set for
greater efficiency.

show more ...

[X86] Don't clobber EBX in stackprobes

On X86, the stackprobe emission code chooses the `R11D` register, which
is illegal on i686. This ends up wrapping around to `EBX`, which does
not get properly

[X86] Don't clobber EBX in stackprobes

On X86, the stackprobe emission code chooses the `R11D` register, which
is illegal on i686. This ends up wrapping around to `EBX`, which does
not get properly callee-saved within the stack probing prologue,
clobbering the register for the callers.

We fix this by explicitly using `EAX` as the stack probe register.

Reviewed By: pengfei

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

show more ...

[X86] Simplify condition guarding emitCalleeSavedFrameMoves. NFC