[Hexagon][test] Fix tests on Linux/musl

[awilfox]

Summary

When running on a host system using musl, the target triple is defined
as hexagon-unknown-linux-musl by default. The Linux ABI differs from
the non-Linux one with varargs, so this causes the tests to fail.

Closes BZ49592, PR48936.

[MaskRay]

The Linux ABI differs from the non-Linux one with varargs, so this causes the tests to fail.

I think this is incorrect. This is due to difference between linux-gnu and linux-musl.

-march=hexagon uses the default target triple (which typically has linux-gnu on a linux-gnu system) and changes the arch part of hexagon.
This is subtly different from -mtriple=... which sets all components of a target triple.

Somehow linux-gnu and generic ELF have the same behavior, which linux-musl has a different behavior.

I think the better fix is to replace -march= with -mtriple=hexagon, instead of keeping both.

[awilfox]

I'm happy to refactor to remove the -march; I was just following the rest of the tests in the Hexagon directory that all have this pattern of -march followed by -mtriple (see the original musl tests added in D72701, and also the OpenBSD test in D126265). Should we remove the -march from the other tests as well?

As for "Linux ABI" vs "musl ABI", D72701 and its resultant commit specify:

Checking OS was too vague and could result in this ABI being unexpectedly enabled if the triple was not set and the host tools were built for Linux. Musl is the only C-library currently used by Hexagon Linux so that is the check I'm using to enable the ABI.

I think the original developers were under the impression that musl wasn't used for development / workstation OS, so they felt this was safe. Since we at Adélie Linux hadn't been updating our LLVM packaging, we didn't run into this issue until now.

[MaskRay]

In D126637#3549195, @awilfox wrote:

I'm happy to refactor to remove the -march; I was just following the rest of the tests in the Hexagon directory that all have this pattern of -march followed by -mtriple (see the original musl tests added in D72701, and also the OpenBSD test in D126265). Should we remove the -march from the other tests as well?

Yes. Generally -march should be avoided for llc.

As for "Linux ABI" vs "musl ABI", D72701 and its resultant commit specify:

Thx.

Checking OS was too vague and could result in this ABI being unexpectedly enabled if the triple was not set and the host tools were built for Linux. Musl is the only C-library currently used by Hexagon Linux so that is the check I'm using to enable the ABI.

I think the original developers were under the impression that musl wasn't used for development / workstation OS, so they felt this was safe. Since we at Adélie Linux hadn't been updating our LLVM packaging, we didn't run into this issue until now.

llvm/test/CodeGen/Hexagon/csr-stubs-spill-threshold.ll

-; RUN: llc -march=hexagon  -O2 -spill-func-threshold=2 < %s | FileCheck %s
+; RUN: llc -march=hexagon -mtriple=hexagon-unknown-linux-gnu -O2 -spill-func-threshold=2 < %s | FileCheck %s
 
 declare i32 @f0(i32, i32, i32, i32, i32, i32)
 

llvm/test/CodeGen/Hexagon/long-calls.ll

-; RUN: llc -march=hexagon -enable-save-restore-long -hexagon-initial-cfg-cleanup=0 < %s | FileCheck %s
+; RUN: llc -march=hexagon -mtriple=hexagon-unknown-linux-gnu -enable-save-restore-long -hexagon-initial-cfg-cleanup=0 < %s | FileCheck %s
 
 ; Check that the -long-calls feature is supported by the backend.
 

llvm/test/CodeGen/Hexagon/mlong-calls.ll

-; RUN: llc -hexagon-long-calls -march=hexagon -enable-save-restore-long=true < %s | FileCheck %s
+; RUN: llc -hexagon-long-calls -march=hexagon -mtriple=hexagon-unknown-linux-gnu -enable-save-restore-long=true < %s | FileCheck %s
 
 ; CHECK: call ##f1
 ; CHECK: jump ##__restore

llvm/test/CodeGen/Hexagon/pic-regusage.ll

-; RUN: llc  -march=hexagon -relocation-model=pic < %s | FileCheck %s
+; RUN: llc  -march=hexagon -mtriple=hexagon-unknown-linux-gnu -relocation-model=pic < %s | FileCheck %s
 
 ; Force the use of R14 (by clobbering everything else in the inline asm).
 ; Make sure that R14 is not set before the __save call (which will clobber

llvm/test/CodeGen/Hexagon/runtime-stkchk.ll

-; RUN: llc -march=hexagon -mcpu=hexagonv55 -enable-stackovf-sanitizer < %s | FileCheck %s
+; RUN: llc -march=hexagon -mcpu=hexagonv55 -mtriple=hexagon-unknown-linux-gnu -enable-stackovf-sanitizer < %s | FileCheck %s
 
 ; CHECK-LABEL: foo_1
 ; CHECK: __runtime_stack_check

llvm/test/CodeGen/Hexagon/swp-memrefs-epilog.ll

-; RUN: llc -march=hexagon -O2 -fp-contract=fast < %s -pipeliner-experimental-cg=true | FileCheck %s
+; RUN: llc -march=hexagon -mtriple=hexagon-unknown-linux-gnu -O2 -fp-contract=fast < %s -pipeliner-experimental-cg=true | FileCheck %s
 
 ; Test that the memoperands for instructions in the epilog are updated
 ; correctly. Previously, the pipeliner updated the offset for the memoperands

llvm/test/CodeGen/Hexagon/vararg-formal.ll

-; RUN: llc -march=hexagon < %s | FileCheck %s
+; RUN: llc -march=hexagon -mtriple=hexagon-unknown-linux-gnu < %s | FileCheck %s
 
 ; Make sure that the first formal argument is not loaded from memory.
 ; CHECK-NOT: memw