[AArch64] Stack probing for dynamic allocas in GlobalISel

[momchil-velikov]

No description provided.

[github-actions]

✅ With the latest revision this PR passed the C/C++ code formatter.

[aemerson]

This looks like too many changes for a single PR.

[momchil-velikov]

This looks like too many changes for a single PR.

Yeah, it's too many, I have separate PRs for:

• [AArch64] Stack probing for function prologues #66524 (Stack probing in prologues)
• [AArch64] Stack probing for dynamic allocas in SelectionDAG #66525 (Stack probing for dynamic allocation in SelectionDSG)
• this one (Stack probing for dynamic allocation in GlobalISel)
• maybe others

In the Phabricator days those would be dependent reviews, here they are just three branches on top of each other,
with each commit visible.

Perhaps I should mark the head of each PR in the commit message, so the structure is evident and people can start review from the first one, while still seeing the big picture.

[oskarwirga]

I found an interaction between -fstack-clash-protection and -ftrivial-auto-var-init=zero that can be triggered with:

// RUN: %clang_cc1 "-triple" "aarch64-none-linux-android28" "-emit-obj" "-Os" "-fstack-clash-protection" "-mstack-probe-size=65536" "-ftrivial-auto-var-init=zero" "-vectorize-loops" "-x" "c" "%s" "-o" "/dev/null"

// This test case examines a specific interaction between the -fstack-clash-protection
// mitigation and the -ftrivial-auto-var-init=zero option.
// The -fstack-clash-protection option inserts a stack probe loop into the compiled code to protect
// against stack clashes. The -ftrivial-auto-var-init=zero option initializes automatic variables to zero.
// The test case was reduced from an instance where the compiler crashed when these options were used together.
// The crash occurred when condition flags were situated at the insertion point of the stack probe loop.

# 4 "" 3
typedef a;
typedef b;
typedef struct {
  b c
} d;
#define e(f, g, h) h f[g]
i(d *j) {
  a k;
  e(l, j->c == 2, a);
  if (j->c == 2)
    k = l;
  m(k);
}

I have a fix but I do not know if it is the correct way to do it. I will add it inline.

[momchil-velikov]

I found an interaction between -fstack-clash-protection and -ftrivial-auto-var-init=zero that can be triggered with:

Thank you, I'll take a look.

[momchil-velikov]

Indeed, that's a bug in 86e003f , specifically in the definition on PROBED_STACKALLOC_DYN pseudo-instruction - it must declare that it implicitly modifies flags.

Thank you again, I will fix that in a follow-up update.

[oskarwirga]

I was able to confirm this stack works as expected in my local testing. I haven't uncovered any further interactions with other mitigations. Thank you for working on this!