llvm / llvm-project

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.
http://llvm.org
Other
28.78k stars 11.9k forks source link

[Clang][OpenMP] Fix multi arch compilation for -march option #92290

Closed saiislam closed 5 months ago

saiislam commented 5 months ago

Legacy toolchain to handle multiple target architectures specified using -Xopenmp-target=<triple> -march=<arch> was only processing a single architecture. This patch also fixes the use of comma to specify multiple archs for a single triple.

llvmbot commented 5 months ago

@llvm/pr-subscribers-clang-driver

@llvm/pr-subscribers-backend-amdgpu

Author: Saiyedul Islam (saiislam)

Changes Legacy toolchain to handle multiple target architectures specified using `-Xopenmp-target=<triple> -march=<arch>` was only processing a single architecture. This patch also fixes the use of comma to specify multiple archs for a single triple. --- Full diff: https://github.com/llvm/llvm-project/pull/92290.diff 2 Files Affected: - (modified) clang/lib/Driver/Driver.cpp (+2-1) - (modified) clang/test/Driver/amdgpu-openmp-toolchain.c (+36-6) ``````````diff diff --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp index 2868b4f2b02e9..9ba148dd93d0a 100644 --- a/clang/lib/Driver/Driver.cpp +++ b/clang/lib/Driver/Driver.cpp @@ -4486,7 +4486,8 @@ Driver::getOffloadArchs(Compilation &C, const llvm::opt::DerivedArgList &Args, // Add or remove the seen architectures in order of appearance. If an // invalid architecture is given we simply exit. - if (Arg->getOption().matches(options::OPT_offload_arch_EQ)) { + if (Arg->getOption().matches(options::OPT_offload_arch_EQ)|| + Arg->getOption().matches(options::OPT_march_EQ)) { for (StringRef Arch : llvm::split(Arg->getValue(), ",")) { if (Arch == "native" || Arch.empty()) { auto GPUsOrErr = TC->getSystemGPUArchs(Args); diff --git a/clang/test/Driver/amdgpu-openmp-toolchain.c b/clang/test/Driver/amdgpu-openmp-toolchain.c index 849afb871ddbf..f4172841e160d 100644 --- a/clang/test/Driver/amdgpu-openmp-toolchain.c +++ b/clang/test/Driver/amdgpu-openmp-toolchain.c @@ -18,18 +18,48 @@ // CHECK-PHASES: 0: input, "[[INPUT:.+]]", c, (host-openmp) // CHECK-PHASES: 1: preprocessor, {0}, cpp-output, (host-openmp) // CHECK-PHASES: 2: compiler, {1}, ir, (host-openmp) -// CHECK-PHASES: 3: input, "[[INPUT]]", c, (device-openmp) -// CHECK-PHASES: 4: preprocessor, {3}, cpp-output, (device-openmp) -// CHECK-PHASES: 5: compiler, {4}, ir, (device-openmp) -// CHECK-PHASES: 6: offload, "host-openmp (x86_64-unknown-linux-gnu)" {2}, "device-openmp (amdgcn-amd-amdhsa)" {5}, ir -// CHECK-PHASES: 7: backend, {6}, ir, (device-openmp) -// CHECK-PHASES: 8: offload, "device-openmp (amdgcn-amd-amdhsa)" {7}, ir +// CHECK-PHASES: 3: input, "[[INPUT]]", c, (device-openmp, gfx906) +// CHECK-PHASES: 4: preprocessor, {3}, cpp-output, (device-openmp, gfx906) +// CHECK-PHASES: 5: compiler, {4}, ir, (device-openmp, gfx906) +// CHECK-PHASES: 6: offload, "host-openmp (x86_64-unknown-linux-gnu)" {2}, "device-openmp (amdgcn-amd-amdhsa:gfx906)" {5}, ir +// CHECK-PHASES: 7: backend, {6}, ir, (device-openmp, gfx906) +// CHECK-PHASES: 8: offload, "device-openmp (amdgcn-amd-amdhsa:gfx906)" {7}, ir // CHECK-PHASES: 9: clang-offload-packager, {8}, image, (device-openmp) // CHECK-PHASES: 10: offload, "host-openmp (x86_64-unknown-linux-gnu)" {2}, "device-openmp (x86_64-unknown-linux-gnu)" {9}, ir // CHECK-PHASES: 11: backend, {10}, assembler, (host-openmp) // CHECK-PHASES: 12: assembler, {11}, object, (host-openmp) // CHECK-PHASES: 13: clang-linker-wrapper, {12}, image, (host-openmp) +// RUN: %clang -ccc-print-phases --target=x86_64-unknown-linux-gnu -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa \ +// RUN: -Xopenmp-target=amdgcn-amd-amdhsa -march=gfx90a:xnack+ \ +// RUN: -Xopenmp-target=amdgcn-amd-amdhsa -march=gfx90a:xnack- %s 2>&1 \ +// RUN: | FileCheck --check-prefix=CHECK-PHASES-MULTI %s + +// RUN: %clang -ccc-print-phases --target=x86_64-unknown-linux-gnu -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa \ +// RUN: -Xopenmp-target=amdgcn-amd-amdhsa -march=gfx90a:xnack+,gfx90a:xnack- %s 2>&1 \ +// RUN: | FileCheck --check-prefix=CHECK-PHASES-MULTI %s + +// CHECK-PHASES-MULTI: 0: input, "[[INPUT:.+]]", c, (host-openmp) +// CHECK-PHASES-MULTI: 1: preprocessor, {0}, cpp-output, (host-openmp) +// CHECK-PHASES-MULTI: 2: compiler, {1}, ir, (host-openmp) +// CHECK-PHASES-MULTI: 3: input, "[[INPUT]]", c, (device-openmp, gfx90a:xnack+) +// CHECK-PHASES-MULTI: 4: preprocessor, {3}, cpp-output, (device-openmp, gfx90a:xnack+) +// CHECK-PHASES-MULTI: 5: compiler, {4}, ir, (device-openmp, gfx90a:xnack+) +// CHECK-PHASES-MULTI: 6: offload, "host-openmp (x86_64-unknown-linux-gnu)" {2}, "device-openmp (amdgcn-amd-amdhsa:gfx90a:xnack+)" {5}, ir +// CHECK-PHASES-MULTI: 7: backend, {6}, ir, (device-openmp, gfx90a:xnack+) +// CHECK-PHASES-MULTI: 8: offload, "device-openmp (amdgcn-amd-amdhsa:gfx90a:xnack+)" {7}, ir +// CHECK-PHASES-MULTI: 9: input, "[[INPUT]]", c, (device-openmp, gfx90a:xnack-) +// CHECK-PHASES-MULTI: 10: preprocessor, {9}, cpp-output, (device-openmp, gfx90a:xnack-) +// CHECK-PHASES-MULTI: 11: compiler, {10}, ir, (device-openmp, gfx90a:xnack-) +// CHECK-PHASES-MULTI: 12: offload, "host-openmp (x86_64-unknown-linux-gnu)" {2}, "device-openmp (amdgcn-amd-amdhsa:gfx90a:xnack-)" {11}, ir +// CHECK-PHASES-MULTI: 13: backend, {12}, ir, (device-openmp, gfx90a:xnack-) +// CHECK-PHASES-MULTI: 14: offload, "device-openmp (amdgcn-amd-amdhsa:gfx90a:xnack-)" {13}, ir +// CHECK-PHASES-MULTI: 15: clang-offload-packager, {8, 14}, image, (device-openmp) +// CHECK-PHASES-MULTI: 16: offload, "host-openmp (x86_64-unknown-linux-gnu)" {2}, "device-openmp (x86_64-unknown-linux-gnu)" {15}, ir +// CHECK-PHASES-MULTI: 17: backend, {16}, assembler, (host-openmp) +// CHECK-PHASES-MULTI: 18: assembler, {17}, object, (host-openmp) +// CHECK-PHASES-MULTI: 19: clang-linker-wrapper, {18}, image, (host-openmp) + // RUN: %clang -### --target=x86_64-unknown-linux-gnu -ccc-print-bindings -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa -march=gfx803 -nogpulib %s 2>&1 | FileCheck %s --check-prefix=CHECK-BINDINGS // RUN: %clang -### --target=x86_64-unknown-linux-gnu -ccc-print-bindings -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa --offload-arch=gfx803 -nogpulib %s 2>&1 | FileCheck %s --check-prefix=CHECK-BINDINGS // CHECK-BINDINGS: "x86_64-unknown-linux-gnu" - "clang", inputs: ["[[INPUT:.+]]"], output: "[[HOST_BC:.+]]" ``````````
llvmbot commented 5 months ago

@llvm/pr-subscribers-clang

Author: Saiyedul Islam (saiislam)

Changes Legacy toolchain to handle multiple target architectures specified using `-Xopenmp-target=<triple> -march=<arch>` was only processing a single architecture. This patch also fixes the use of comma to specify multiple archs for a single triple. --- Full diff: https://github.com/llvm/llvm-project/pull/92290.diff 2 Files Affected: - (modified) clang/lib/Driver/Driver.cpp (+2-1) - (modified) clang/test/Driver/amdgpu-openmp-toolchain.c (+36-6) ``````````diff diff --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp index 2868b4f2b02e9..9ba148dd93d0a 100644 --- a/clang/lib/Driver/Driver.cpp +++ b/clang/lib/Driver/Driver.cpp @@ -4486,7 +4486,8 @@ Driver::getOffloadArchs(Compilation &C, const llvm::opt::DerivedArgList &Args, // Add or remove the seen architectures in order of appearance. If an // invalid architecture is given we simply exit. - if (Arg->getOption().matches(options::OPT_offload_arch_EQ)) { + if (Arg->getOption().matches(options::OPT_offload_arch_EQ)|| + Arg->getOption().matches(options::OPT_march_EQ)) { for (StringRef Arch : llvm::split(Arg->getValue(), ",")) { if (Arch == "native" || Arch.empty()) { auto GPUsOrErr = TC->getSystemGPUArchs(Args); diff --git a/clang/test/Driver/amdgpu-openmp-toolchain.c b/clang/test/Driver/amdgpu-openmp-toolchain.c index 849afb871ddbf..f4172841e160d 100644 --- a/clang/test/Driver/amdgpu-openmp-toolchain.c +++ b/clang/test/Driver/amdgpu-openmp-toolchain.c @@ -18,18 +18,48 @@ // CHECK-PHASES: 0: input, "[[INPUT:.+]]", c, (host-openmp) // CHECK-PHASES: 1: preprocessor, {0}, cpp-output, (host-openmp) // CHECK-PHASES: 2: compiler, {1}, ir, (host-openmp) -// CHECK-PHASES: 3: input, "[[INPUT]]", c, (device-openmp) -// CHECK-PHASES: 4: preprocessor, {3}, cpp-output, (device-openmp) -// CHECK-PHASES: 5: compiler, {4}, ir, (device-openmp) -// CHECK-PHASES: 6: offload, "host-openmp (x86_64-unknown-linux-gnu)" {2}, "device-openmp (amdgcn-amd-amdhsa)" {5}, ir -// CHECK-PHASES: 7: backend, {6}, ir, (device-openmp) -// CHECK-PHASES: 8: offload, "device-openmp (amdgcn-amd-amdhsa)" {7}, ir +// CHECK-PHASES: 3: input, "[[INPUT]]", c, (device-openmp, gfx906) +// CHECK-PHASES: 4: preprocessor, {3}, cpp-output, (device-openmp, gfx906) +// CHECK-PHASES: 5: compiler, {4}, ir, (device-openmp, gfx906) +// CHECK-PHASES: 6: offload, "host-openmp (x86_64-unknown-linux-gnu)" {2}, "device-openmp (amdgcn-amd-amdhsa:gfx906)" {5}, ir +// CHECK-PHASES: 7: backend, {6}, ir, (device-openmp, gfx906) +// CHECK-PHASES: 8: offload, "device-openmp (amdgcn-amd-amdhsa:gfx906)" {7}, ir // CHECK-PHASES: 9: clang-offload-packager, {8}, image, (device-openmp) // CHECK-PHASES: 10: offload, "host-openmp (x86_64-unknown-linux-gnu)" {2}, "device-openmp (x86_64-unknown-linux-gnu)" {9}, ir // CHECK-PHASES: 11: backend, {10}, assembler, (host-openmp) // CHECK-PHASES: 12: assembler, {11}, object, (host-openmp) // CHECK-PHASES: 13: clang-linker-wrapper, {12}, image, (host-openmp) +// RUN: %clang -ccc-print-phases --target=x86_64-unknown-linux-gnu -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa \ +// RUN: -Xopenmp-target=amdgcn-amd-amdhsa -march=gfx90a:xnack+ \ +// RUN: -Xopenmp-target=amdgcn-amd-amdhsa -march=gfx90a:xnack- %s 2>&1 \ +// RUN: | FileCheck --check-prefix=CHECK-PHASES-MULTI %s + +// RUN: %clang -ccc-print-phases --target=x86_64-unknown-linux-gnu -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa \ +// RUN: -Xopenmp-target=amdgcn-amd-amdhsa -march=gfx90a:xnack+,gfx90a:xnack- %s 2>&1 \ +// RUN: | FileCheck --check-prefix=CHECK-PHASES-MULTI %s + +// CHECK-PHASES-MULTI: 0: input, "[[INPUT:.+]]", c, (host-openmp) +// CHECK-PHASES-MULTI: 1: preprocessor, {0}, cpp-output, (host-openmp) +// CHECK-PHASES-MULTI: 2: compiler, {1}, ir, (host-openmp) +// CHECK-PHASES-MULTI: 3: input, "[[INPUT]]", c, (device-openmp, gfx90a:xnack+) +// CHECK-PHASES-MULTI: 4: preprocessor, {3}, cpp-output, (device-openmp, gfx90a:xnack+) +// CHECK-PHASES-MULTI: 5: compiler, {4}, ir, (device-openmp, gfx90a:xnack+) +// CHECK-PHASES-MULTI: 6: offload, "host-openmp (x86_64-unknown-linux-gnu)" {2}, "device-openmp (amdgcn-amd-amdhsa:gfx90a:xnack+)" {5}, ir +// CHECK-PHASES-MULTI: 7: backend, {6}, ir, (device-openmp, gfx90a:xnack+) +// CHECK-PHASES-MULTI: 8: offload, "device-openmp (amdgcn-amd-amdhsa:gfx90a:xnack+)" {7}, ir +// CHECK-PHASES-MULTI: 9: input, "[[INPUT]]", c, (device-openmp, gfx90a:xnack-) +// CHECK-PHASES-MULTI: 10: preprocessor, {9}, cpp-output, (device-openmp, gfx90a:xnack-) +// CHECK-PHASES-MULTI: 11: compiler, {10}, ir, (device-openmp, gfx90a:xnack-) +// CHECK-PHASES-MULTI: 12: offload, "host-openmp (x86_64-unknown-linux-gnu)" {2}, "device-openmp (amdgcn-amd-amdhsa:gfx90a:xnack-)" {11}, ir +// CHECK-PHASES-MULTI: 13: backend, {12}, ir, (device-openmp, gfx90a:xnack-) +// CHECK-PHASES-MULTI: 14: offload, "device-openmp (amdgcn-amd-amdhsa:gfx90a:xnack-)" {13}, ir +// CHECK-PHASES-MULTI: 15: clang-offload-packager, {8, 14}, image, (device-openmp) +// CHECK-PHASES-MULTI: 16: offload, "host-openmp (x86_64-unknown-linux-gnu)" {2}, "device-openmp (x86_64-unknown-linux-gnu)" {15}, ir +// CHECK-PHASES-MULTI: 17: backend, {16}, assembler, (host-openmp) +// CHECK-PHASES-MULTI: 18: assembler, {17}, object, (host-openmp) +// CHECK-PHASES-MULTI: 19: clang-linker-wrapper, {18}, image, (host-openmp) + // RUN: %clang -### --target=x86_64-unknown-linux-gnu -ccc-print-bindings -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa -march=gfx803 -nogpulib %s 2>&1 | FileCheck %s --check-prefix=CHECK-BINDINGS // RUN: %clang -### --target=x86_64-unknown-linux-gnu -ccc-print-bindings -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa --offload-arch=gfx803 -nogpulib %s 2>&1 | FileCheck %s --check-prefix=CHECK-BINDINGS // CHECK-BINDINGS: "x86_64-unknown-linux-gnu" - "clang", inputs: ["[[INPUT:.+]]"], output: "[[HOST_BC:.+]]" ``````````
saiislam commented 5 months ago

It will fix tests like: targetid_multi_image

github-actions[bot] commented 5 months ago

:warning: C/C++ code formatter, clang-format found issues in your code. :warning:

You can test this locally with the following command: ``````````bash git-clang-format --diff 9bbefb7f600019c9d7025281132dd160729bfff2 a6611634d03d102a8b69df8ff20d324efd81ae48 -- clang/lib/Driver/Driver.cpp clang/test/Driver/amdgpu-openmp-toolchain.c ``````````
View the diff from clang-format here. ``````````diff diff --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp index 9ba148dd93..4b2cb72c53 100644 --- a/clang/lib/Driver/Driver.cpp +++ b/clang/lib/Driver/Driver.cpp @@ -4486,7 +4486,7 @@ Driver::getOffloadArchs(Compilation &C, const llvm::opt::DerivedArgList &Args, // Add or remove the seen architectures in order of appearance. If an // invalid architecture is given we simply exit. - if (Arg->getOption().matches(options::OPT_offload_arch_EQ)|| + if (Arg->getOption().matches(options::OPT_offload_arch_EQ) || Arg->getOption().matches(options::OPT_march_EQ)) { for (StringRef Arch : llvm::split(Arg->getValue(), ",")) { if (Arch == "native" || Arch.empty()) { ``````````
jhuber6 commented 5 months ago

I don't think we want to support this. -march was the wrong option to use in the first place, and upstream LLVM never supported specifying multiple device images with -march so there isn't a legacy argument in trunk. However, AOMP did support this and if it's deemed too disruptive to request users move to --offload-arch=a,b,c then we can carry that change in the fork.

It will fix tests like: targetid_multi_image

I think the easier way to fix this is to update the Makefile.

saiislam commented 5 months ago

I don't think we want to support this. -march was the wrong option to use in the first place, and upstream LLVM never supported specifying multiple device images with -march so there isn't a legacy argument in trunk. However, AOMP did support this and if it's deemed too disruptive to request users move to --offload-arch=a,b,c then we can carry that change in the fork.

It will fix tests like: targetid_multi_image

I think the easier way to fix this is to update the Makefile.

Irrespective of what AOMP does, I think it makes sense to ensure parity between the two ways of specifying architecture. People have been historically using -Xopenmp-target -march style, and using the same for multiple architectures seems to be the most obvious choice. Isn't it quite confusing to tell the users that they can use offload-arch style for single as well as multiple archs, but can use -march style only for single arch?

jhuber6 commented 5 months ago

I don't think we want to support this. -march was the wrong option to use in the first place, and upstream LLVM never supported specifying multiple device images with -march so there isn't a legacy argument in trunk. However, AOMP did support this and if it's deemed too disruptive to request users move to --offload-arch=a,b,c then we can carry that change in the fork.

It will fix tests like: targetid_multi_image

I think the easier way to fix this is to update the Makefile.

Irrespective of what AOMP does, I think it makes sense to ensure parity between the two ways of specifying architecture. People have been historically using -Xopenmp-target -march style, and using the same for multiple architectures seems to be the most obvious choice. Isn't it quite confusing to tell the users that they can use offload-arch style for single as well as multiple archs, but can use -march style only for single arch?

-march was the wrong option to use for this from the beginning. It's supposed to be an overriding option and it shouldn't be overloaded to mean something different here. In LLVM / trunk we never supported multiple architectures with the -march option so I don't see any reason to start now. --offload-arch= is a complete replacement for this behavior and I consider the single -march option to be legacy. Even within this it's divergent because HIP / OpenCL / AMDGPU use -mcpu but the OpenMP toolchain ignored that and uses -march=.

Using --offload-arch= is a direct replacement for -march in all use-cases. It's also easier to use and interoperable with CUDA. I would just change the test, you can replace every use of -march with --offload-arch and it will work. See the following.

> clang input.c -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa,nvptx64-nvidia-cuda \
  -Xopenmp-target=amdgcn-amd-amdhsa --offload-arch=gfx1030 \
  -Xopenmp-target=amdgcn-amd-amdhsa --offload-arch=gfx90a \
  -Xopenmp-target=nvptx64-nvidia-cuda --offload-arch=sm_89 
> llvm-objdump --offloading a.out

a.out:  file format elf64-x86-64

OFFLOADING IMAGE [0]:
kind            elf
arch            sm_89
triple          nvptx64-nvidia-cuda
producer        openmp

OFFLOADING IMAGE [1]:
kind            elf
arch            gfx90a
triple          amdgcn-amd-amdhsa
producer        openmp

OFFLOADING IMAGE [2]:
kind            elf
arch            gfx1030
triple          amdgcn-amd-amdhsa
producer        openmp
saiislam commented 5 months ago

I don't think we want to support this. -march was the wrong option to use in the first place, and upstream LLVM never supported specifying multiple device images with -march so there isn't a legacy argument in trunk. However, AOMP did support this and if it's deemed too disruptive to request users move to --offload-arch=a,b,c then we can carry that change in the fork.

It will fix tests like: targetid_multi_image

I think the easier way to fix this is to update the Makefile.

Irrespective of what AOMP does, I think it makes sense to ensure parity between the two ways of specifying architecture. People have been historically using -Xopenmp-target -march style, and using the same for multiple architectures seems to be the most obvious choice. Isn't it quite confusing to tell the users that they can use offload-arch style for single as well as multiple archs, but can use -march style only for single arch?

-march was the wrong option to use for this from the beginning. It's supposed to be an overriding option and it shouldn't be overloaded to mean something different here. In LLVM / trunk we never supported multiple architectures with the -march option so I don't see any reason to start now. --offload-arch= is a complete replacement for this behavior and I consider the single -march option to be legacy. Even within this it's divergent because HIP / OpenCL / AMDGPU use -mcpu but the OpenMP toolchain ignored that and uses -march=.

Using --offload-arch= is a direct replacement for -march in all use-cases. It's also easier to use and interoperable with CUDA. I would just change the test, you can replace every use of -march with --offload-arch and it will work. See the following.

> clang input.c -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa,nvptx64-nvidia-cuda \
  -Xopenmp-target=amdgcn-amd-amdhsa --offload-arch=gfx1030 \
  -Xopenmp-target=amdgcn-amd-amdhsa --offload-arch=gfx90a \
  -Xopenmp-target=nvptx64-nvidia-cuda --offload-arch=sm_89 
> llvm-objdump --offloading a.out

a.out:    file format elf64-x86-64

OFFLOADING IMAGE [0]:
kind            elf
arch            sm_89
triple          nvptx64-nvidia-cuda
producer        openmp

OFFLOADING IMAGE [1]:
kind            elf
arch            gfx90a
triple          amdgcn-amd-amdhsa
producer        openmp

OFFLOADING IMAGE [2]:
kind            elf
arch            gfx1030
triple          amdgcn-amd-amdhsa
producer        openmp

If -march is the wrong option then let's start deprecating it and remove it altogether in the next llvm release. But, as long as it is here, it should be equivalent to --offload-arch.

jhuber6 commented 5 months ago

If -march is the wrong option then let's start deprecating it and remove it altogether in the next llvm release. But, as long as it is here, it should be equivalent to --offload-arch.

Honestly not a bad idea. I could make a patch warning users to use --offload-arch instead for now.

saiislam commented 5 months ago

If -march is the wrong option then let's start deprecating it and remove it altogether in the next llvm release. But, as long as it is here, it should be equivalent to --offload-arch.

Honestly not a bad idea. I could make a patch warning users to use --offload-arch instead for now.

Sure, let's do that. But, let this land as long as this option is supported.

jhuber6 commented 5 months ago

If -march is the wrong option then let's start deprecating it and remove it altogether in the next llvm release. But, as long as it is here, it should be equivalent to --offload-arch.

Honestly not a bad idea. I could make a patch warning users to use --offload-arch instead for now.

Sure, let's do that. But, let this land as long as this option is supported.

That doesn't track, LLVM has never supported -march to support multiple options and there's no reason to add it now when we're talking about deprecating it.

shiltian commented 5 months ago

If -march is the wrong option then let's start deprecating it and remove it altogether in the next llvm release. But, as long as it is here, it should be equivalent to --offload-arch.

Honestly not a bad idea. I could make a patch warning users to use --offload-arch instead for now.

Sure, let's do that. But, let this land as long as this option is supported.

That doesn't track, LLVM has never supported -march to support multiple options and there's no reason to add it now when we're talking about deprecating it.

+1

saiislam commented 5 months ago

Thanks for the review and comments. Closing the PR.