DebugInfo: Move missing-abstract-variable.ll test from Generic to X86

[tstellar]

Summary

This test is XFAIL'd on most arches, and seems too fragile to be run on non-X86.

[mehdi_amini]

when llvm is configured with LLVM_DEFAULT_TARGET_TRIPLE set to a non-empty value,

Do you mean an empty value? I believe this is set to the host by default.

[tstellar]

In D109806#3001029, @mehdi_amini wrote:

when llvm is configured with LLVM_DEFAULT_TARGET_TRIPLE set to a non-empty value,

Do you mean an empty value? I believe this is set to the host by default.

Yes, you are correct, there is a default value form this variable which comes from config.guess. So I guess this means this test is sensitive to what the target triple is, because it's failing for me when I set the default triple to ppc64le-redhat-linux-gnu, but not when it uses the default triple of powerpc64le-unknown-linux-gnu.

[jmorse]

LGTM

[jmorse]

Also, the test passes for me when LLVM is configured to use the default triple of powerpc64le-unknown-linux-gnu, but fails when I configure the default triple to be ppc64le-redhat-linux-gnu.

Hmmm. Possibly the longer term fix is for this test to
a) Not be in the 'Generic' directory, or
b) Become a MIR test instead of exercising instruction selection as part of the test too.

(Adding an XFail in the meantime seems fine to me, especially as powerpc64 is already known to have this issue).

[kwk]

This needs rebasing...

[tstellar]

Move test to X86 directory.

[tstellar]

In D109806#3018155, @jmorse wrote:

Also, the test passes for me when LLVM is configured to use the default triple of powerpc64le-unknown-linux-gnu, but fails when I configure the default triple to be ppc64le-redhat-linux-gnu.

Hmmm. Possibly the longer term fix is for this test to
a) Not be in the 'Generic' directory, or
b) Become a MIR test instead of exercising instruction selection as part of the test too.

(Adding an XFail in the meantime seems fine to me, especially as powerpc64 is already known to have this issue).

In the mean time, the test has been XFAIL'd on many more arches, so I just moved it to the X86 directory.

[probinson]

Seems like a reasonable resolution. Better than continually extending the XFAIL list.

llvm/test/DebugInfo/X86/missing-abstract-variable.ll

-; RUN: %llc_dwarf -O0 -filetype=obj < %s | llvm-dwarfdump -debug-info - | FileCheck %s
-
-; The formal parameter 'b' for Function 'x' when inlined within 'a' is lost on
-; powerpc64 (and on x86_64 at at least -O2). Presumably this is a SelectionDAG
-; issue.
-; FIXME: arm64 is an alias for aarch64 on macs, apparently?
-; XFAIL: powerpc64, aarch64, arm64, hexagon, riscv, sparc, loongarch
+; RUN: %llc_dwarf -mtriple x86_64-gnu-linux -O0 -filetype=obj < %s | llvm-dwarfdump -debug-info - | FileCheck %s
 
 ; Build from the following source with clang -O2.
 
 ; The important details are that 'x's abstract definition is first built during
 ; the definition of 'b', where the parameter to 'x' is constant and so 'x's 's'
 ; variable is optimized away. No abstract definition DIE for 's' is constructed.
 ; Then, during 'a' emission, the abstract DbgVariable for 's' is created, but
 ; the abstract DIE isn't (since the abstract definition for 'b' is already