jhuber6 wrote:
> So I should do like open 5 branches and make a PR for each?
>
> As for the cases mentioned, when I tried compile all projects (compile with
> -DLLVM_ENABLE_PROJECTS=all), I did encounter such cases when compiling and
> I've fixed them all. Now all projects can be successfully
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/126243
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/jhuber6 commented:
This should definitely be split up. Also some options are referenced in
multiple places, i.e.
```
// foo.h
extern cl::opt <...>
// foo.cpp
cl::opt <...>
use opt
//bar.cpp
use opt.
```
https://github.com/llvm/llvm-project/pull/126243
__
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/79373
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
jhuber6 wrote:
> Got it, okay, thanks.
>
> Since this change only applies to `--target=nvptx64-nvidia-cuda`, fine by me.
> Thanks for putting up with our scrutiny. :)
No problem, I probably should've have been clearer in my commit messages.
https://github.com/llvm/llvm-project/pull/79373
___
jhuber6 wrote:
> I...think I understand.
>
> Is the output of this compilation step a cubin, then?
Yes, it will spit out a simple `cubin` instead of a fatbinary. The NVIDIA
toolchain is much worse about this stuff than the AMD one, but in general it
works. You can check with `-###` or whateve
jhuber6 wrote:
> > This method of compilation is not like CUDA, so we can't target all the
> > GPUs at the same time.
>
> Can you clarify for me -- what are you compiling where it's impossible to
> target multiple GPUs in the binary? I'm confused because Art is understanding
> that it's not C
jhuber6 wrote:
> > This method of compilation is not like CUDA, so we can't target all the
> > GPUs at the same time.
>
> I think this is the key fact I was missing. If the patch is only for a
> standalone compilation which does not do multi-GPU compilation in principle,
> then your approach
jhuber6 wrote:
> > I think the semantics of native on other architectures are clear enough
> > here.
>
> I don't think we have the same idea about that. Let's spell it out, so
> there's no confusion.
>
> [GCC
> manual](https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html#index-march-16)
> sa
jhuber6 wrote:
> User confusion is only part of the issue here. With any single GPU choice we
> would still potentially produce a nonworking binary, if our GPU choice does
> not match what the user wants.
>
> "all GPUs" has the advantage of always producing the binary that's guaranteed
> to wo
jhuber6 wrote:
> On the other hand, I'd be OK with providing --offload-arch=native translating
> into "compile for all present GPU variants", with a possibility to further
> adjust the selected set with the usual --no-offload-arch-foo, if the user
> needs to. This will at least produce code th
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/79373
>From 145b7bc932ce3ffa46545cd7af29b1c93981429c Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Wed, 24 Jan 2024 15:34:00 -0600
Subject: [PATCH 1/3] [NVPTX] Add support for -march=native in standalone NVPTX
Sum
jhuber6 wrote:
Maybe need to specify `--target=x86_64-unknown-linux-gnu` in the test?
https://github.com/llvm/llvm-project/pull/79222
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -0,0 +1,5 @@
+/// Some target-specific options are ignored for GPU, so %clang exits with
code 0.
+// DEFINE: %{check} = %clang -### -c -mcmodel=medium
jhuber6 wrote:
Probably depends on the option we're testing. We could do both.
https://github.com/llvm/llvm
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/79222
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -0,0 +1,7 @@
+/// Some target-specific options are ignored for GPU, so %clang exits with
code 0.
+// DEFINE: %{gpu_opts} = --cuda-gpu-arch=sm_60
--cuda-path=%S/Inputs/CUDA/usr/local/cuda --no-cuda-version-check
+// DEFINE: %{check} = %clang -### -c %{gpu_opts} -mcmodel=medium
@@ -0,0 +1,7 @@
+/// Some target-specific options are ignored for GPU, so %clang exits with
code 0.
+// DEFINE: %{gpu_opts} = --cuda-gpu-arch=sm_60
--cuda-path=%S/Inputs/CUDA/usr/local/cuda --no-cuda-version-check
+// DEFINE: %{check} = %clang -### -c %{gpu_opts} -mcmodel=medium
@@ -58,6 +60,22 @@ class GlobalTy {
void setPtr(void *P) { Ptr = P; }
};
+typedef void *IntPtrT;
+struct __llvm_profile_data {
+#define INSTR_PROF_DATA(Type, LLVMType, Name, Initializer) Type Name;
+#include "llvm/ProfileData/InstrProfData.inc"
+};
+
+/// PGO profiling data
@@ -163,3 +163,87 @@ Error
GenericGlobalHandlerTy::readGlobalFromImage(GenericDeviceTy &Device,
return Plugin::success();
}
+
+bool GenericGlobalHandlerTy::hasProfilingGlobals(GenericDeviceTy &Device,
+ DeviceImageTy &Image) {
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/76587
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -58,6 +60,22 @@ class GlobalTy {
void setPtr(void *P) { Ptr = P; }
};
+typedef void *IntPtrT;
jhuber6 wrote:
Okay. you should use the C++ `using` keyword instead of C's `typedef.
https://github.com/llvm/llvm-project/pull/76587
__
@@ -58,6 +60,22 @@ class GlobalTy {
void setPtr(void *P) { Ptr = P; }
};
+typedef void *IntPtrT;
+struct __llvm_profile_data {
+#define INSTR_PROF_DATA(Type, LLVMType, Name, Initializer) Type Name;
+#include "llvm/ProfileData/InstrProfData.inc"
+};
+
+/// PGO profiling data
@@ -163,3 +163,87 @@ Error
GenericGlobalHandlerTy::readGlobalFromImage(GenericDeviceTy &Device,
return Plugin::success();
}
+
+bool GenericGlobalHandlerTy::hasProfilingGlobals(GenericDeviceTy &Device,
+ DeviceImageTy &Image) {
@@ -163,3 +163,87 @@ Error
GenericGlobalHandlerTy::readGlobalFromImage(GenericDeviceTy &Device,
return Plugin::success();
}
+
+bool GenericGlobalHandlerTy::hasProfilingGlobals(GenericDeviceTy &Device,
+ DeviceImageTy &Image) {
@@ -163,3 +163,87 @@ Error
GenericGlobalHandlerTy::readGlobalFromImage(GenericDeviceTy &Device,
return Plugin::success();
}
+
+bool GenericGlobalHandlerTy::hasProfilingGlobals(GenericDeviceTy &Device,
+ DeviceImageTy &Image) {
@@ -163,3 +163,87 @@ Error
GenericGlobalHandlerTy::readGlobalFromImage(GenericDeviceTy &Device,
return Plugin::success();
}
+
+bool GenericGlobalHandlerTy::hasProfilingGlobals(GenericDeviceTy &Device,
+ DeviceImageTy &Image) {
@@ -58,6 +60,22 @@ class GlobalTy {
void setPtr(void *P) { Ptr = P; }
};
+typedef void *IntPtrT;
+struct __llvm_profile_data {
+#define INSTR_PROF_DATA(Type, LLVMType, Name, Initializer) Type Name;
+#include "llvm/ProfileData/InstrProfData.inc"
+};
+
+/// PGO profiling data
@@ -58,6 +60,22 @@ class GlobalTy {
void setPtr(void *P) { Ptr = P; }
};
+typedef void *IntPtrT;
jhuber6 wrote:
What's the utility of this?
https://github.com/llvm/llvm-project/pull/76587
___
lldb-commits mailing
@@ -163,3 +163,87 @@ Error
GenericGlobalHandlerTy::readGlobalFromImage(GenericDeviceTy &Device,
return Plugin::success();
}
+
+bool GenericGlobalHandlerTy::hasProfilingGlobals(GenericDeviceTy &Device,
+ DeviceImageTy &Image) {
@@ -163,3 +163,87 @@ Error
GenericGlobalHandlerTy::readGlobalFromImage(GenericDeviceTy &Device,
return Plugin::success();
}
+
+bool GenericGlobalHandlerTy::hasProfilingGlobals(GenericDeviceTy &Device,
+ DeviceImageTy &Image) {
@@ -163,3 +163,87 @@ Error
GenericGlobalHandlerTy::readGlobalFromImage(GenericDeviceTy &Device,
return Plugin::success();
}
+
+bool GenericGlobalHandlerTy::hasProfilingGlobals(GenericDeviceTy &Device,
+ DeviceImageTy &Image) {
@@ -47,7 +47,9 @@ PluginAdaptorTy::create(const std::string &Name) {
new PluginAdaptorTy(Name, std::move(LibraryHandler)));
if (auto Err = PluginAdaptor->init())
return Err;
- return PluginAdaptor;
jhuber6 wrote:
Does putting `std::move` here not
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/66034
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -0,0 +1,19 @@
+//===-- Implementation of the GPU logbf function
jhuber6 wrote:
Fix header
https://github.com/llvm/llvm-project/pull/66034
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.
https://github.com/jhuber6 approved this pull request.
LG after fixing the header formatting.
https://github.com/llvm/llvm-project/pull/66034
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb
@@ -0,0 +1,21 @@
+//===-- Implementation of the GPU atan2f function
jhuber6 wrote:
Fix header
https://github.com/llvm/llvm-project/pull/66034
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm
@@ -0,0 +1,17 @@
+//===-- Implementation of the GPU lroundf function
jhuber6 wrote:
This and some other headers need to be reformatted.
https://github.com/llvm/llvm-project/pull/66034
___
lldb-commits mailing list
lldb
37 matches
Mail list logo
