jhuber6 wrote:
Fixed the managed stuff in https://github.com/llvm/llvm-project/pull/123437,
should be good enough for the foreseeable future.
https://github.com/llvm/llvm-project/pull/123359
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/123437
Summary:
Previously, managed variables didn't work in rdc mode using the new
driver because we just didn't register them. This was previously ignored
because we didn't have enough space in the current struct form
jhuber6 wrote:
> > > For now, it's probably easier just to put some indirection in this and
> > > pass a struct to the first argument.
> >
> >
> > It would be even easier to not make the move. Does "addr" have different
> > meanings in each context where an offload_entry is used? Is this goin
jhuber6 wrote:
> > For now, it's probably easier just to put some indirection in this and pass
> > a struct to the first argument.
>
> It would be even easier to not make the move. Does "addr" have different
> meanings in each context where an offload_entry is used? Is this going to
> confuse
jhuber6 wrote:
> > I'd like to avoid modifying this struct to avoid breaking ABI with OpenMP.
> > Perhaps I should make `addr` a pointer to a struct and just GEP the two
> > values.
>
> Are we trying to jam a square HIP peg into a round OpenMP hole, or are we
> truly wanting to move to a lang
jhuber6 wrote:
@yxsamliu Here's the general problem, the `__hipRegisterManagedVar` call takes
the following arguments.
```c
__hipRegisterManagedVar(void ** handle, char *ManagedVarPtr, char *VarPtr,
const char *VarName, size_t Size, unsigned Alignment)
```
But the struct that we store this in
jhuber6 wrote:
I somehow totally forgot that I implemented surfaces and textures, it was
`managed` that I was having problems with.
https://github.com/llvm/llvm-project/pull/123359
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/123359
>From ce890d0f8f34dc1a32edf41571f0a432e4c03586 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Fri, 17 Jan 2025 09:35:34 -0600
Subject: [PATCH] [HIP] Move HIP to the new driver by default
Summary:
This patch
jhuber6 wrote:
> > Surfaces and textures are being phased out of CUDA as far as I can tell, so
> > I wasn't sure how relevant it was (since we can use
> > `--no-offload-new-driver` as a workaround for now). CUDA clang doesn't even
> > handle surfaces, and as far as I can tell the old `cudaRegi
jhuber6 wrote:
> Breaking any existing HIP feature is a no-go in my opinion. Textures and
> surfaces are important to some developers.
Surfaces and textures are being phased out of CUDA as far as I can tell, so I
wasn't sure how relevant it was (since we can use `--no-offload-new-driver` as
a
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/123359
Summary:
This patch matches CUDA, moving the HIP compilation jobs to the new
driver by default. The old behavior will return with
`--no-offload-new-driver`. The main difference is that objects compiled
with the o
jhuber6 wrote:
> That would break rccl. We should use CUID's that work in general, including
> apps that compile the same file with different options.
Shouldn't be broken if the driver handles the CUID, I just mean that it would
work in `cc1` if not passed.
https://github.com/llvm/llvm-proj
https://github.com/jhuber6 commented:
Can we get a new test showing CUDA? CUDA uses the new driver by default so cuid
stuff will be missing there.
https://github.com/llvm/llvm-project/pull/122859
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
jhuber6 wrote:
> > > > I thought the new driver just got some entropy from the current source
> > > > file's `inode` entry? I'm not opposed, since I guess it would make
> > > > sense to give the user a way to override it.
> > >
> > >
> > > Sorry I did not quite get your question. Do you sugge
jhuber6 wrote:
> > I thought the new driver just got some entropy from the current source
> > file's `inode` entry? I'm not opposed, since I guess it would make sense to
> > give the user a way to override it.
>
> Sorry I did not quite get your question. Do you suggest that we need some
> opt
https://github.com/jhuber6 commented:
I thought the new driver just got some entropy from the current source file's
`inode` entry? I'm not opposed, since I guess it would make sense to give the
user a way to override it.
https://github.com/llvm/llvm-project/pull/122859
jhuber6 wrote:
> Sorry, I kind of got lost in the above discussion. Are additional changes
> required in Clang to parse builtins unsupported on the current target to make
> sure we don't break anything or is only changing the result of
> `__has_builtin` acceptable?
I believe the conclusion wa
jhuber6 wrote:
There's also the question of when done from CUDA, perhaps we should make this
match the aux triple if present.
https://github.com/llvm/llvm-project/pull/115248
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.o
https://github.com/jhuber6 approved this pull request.
Maybe one day we'll be able to get rid of the bundler.
https://github.com/llvm/llvm-project/pull/122627
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailma
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/122312
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
> One thing that's missing is the release note. It should have an entry about
> the change and a pointer to the details and instructions on how to revert to
> the new build and, possibly a set of instructions for common use cases. E.g.
> GPU-linking a library (i.e. linking RDC-c
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/122312
>From 533572c8e73c7330fe91d95428fd0189471073d8 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 9 Jan 2025 10:40:43 -0600
Subject: [PATCH 1/2] [CUDA] Move CUDA to new driver by default
Summary:
This patch
jhuber6 wrote:
> > All that said, there are two cases to consider wrt. the standard:
> >
> > 1. The initial device is the CPU and the code compiled here is just part of
> > a GPU library, or
> > 2. the initial device is the GPU and the code compiled here is just part of
> > the "host code".
>
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/122312
>From 533572c8e73c7330fe91d95428fd0189471073d8 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 9 Jan 2025 10:40:43 -0600
Subject: [PATCH] [CUDA] Move CUDA to new driver by default
Summary:
This patch upd
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/122149
>From 3329b7ae7dc6044f6563f218c65f6af7498290f0 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Wed, 8 Jan 2025 12:19:53 -0600
Subject: [PATCH 1/3] [OpenMP] Allow GPUs to be targeted directly via
`-fopenmp`.
jhuber6 wrote:
> Do we have a clear idea on if a construct can behave in a different manner if
> it is nested in a target region?
Unsure exactly, the target regions are just outlined, so it shouldn't affect
anything on a codegen level.
https://github.com/llvm/llvm-project/pull/122149
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/122149
>From 3329b7ae7dc6044f6563f218c65f6af7498290f0 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Wed, 8 Jan 2025 12:19:53 -0600
Subject: [PATCH 1/2] [OpenMP] Allow GPUs to be targeted directly via
`-fopenmp`.
https://github.com/jhuber6 commented:
I've never been a fan of this type of implicit behavior, since it will change
spuriously depending on what the user wants.
I also wonder if we couldn't do something similar with ELF compression so we
don't need to manually do all this stuff.
https://githu
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/122174
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
Seems to be failing for some unrelated OpenACC test.
https://github.com/llvm/llvm-project/pull/122174
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/122174
>From 47908c2aefc7009ccb62d4b9111fbd8d7e5ee7ad Mon Sep 17 00:00:00 2001
From: CatherineMoore
Date: Wed, 8 Jan 2025 16:33:01 -0500
Subject: [PATCH 1/3] Update OpenMPSupport.rst
---
clang/docs/OpenMPSupport.rst
jhuber6 wrote:
```Warning, treated as error:
/home/runner/work/llvm-project/llvm-project/clang-build/tools/clang/docs/OpenMPSupport.rst:398:Inline
interpreted text or phrase reference start-string without end-string.
ninja: build stopped: subcommand failed.
```
>From the CI
https://github.com/l
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/122174
>From 47908c2aefc7009ccb62d4b9111fbd8d7e5ee7ad Mon Sep 17 00:00:00 2001
From: CatherineMoore
Date: Wed, 8 Jan 2025 16:33:01 -0500
Subject: [PATCH 1/2] Update OpenMPSupport.rst
---
clang/docs/OpenMPSupport.rst
@@ -343,6 +343,124 @@ implementation.
| task | nowait clause on taskwait
| :part:`partial` | parsing/sema done: D131830, D141531
|
+--+---
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/122174
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
I guess I'll see how much I favor this approach depending on how much more
difficult it is to build the DeviceRTL without OpenMP. I think the only thing
we'd miss is the `#pragma omp assumes(...)` business, which might have another
way to be emitted in LLVM/Clang?
https://githu
jhuber6 wrote:
> Maybe just turn on OpenMPIsTargetDevice if `gpu target + -fopenmp` is
> specified?
Doesn't work, it causes all definitions to be stripped as they are not declared
on the device, which is not what we want.
https://github.com/llvm/llvm-project/pull/122149
__
jhuber6 wrote:
> I think that is a misuse of OpenMP semantics. We can't expect to have regular
> OpenMP code working in the same way as OpenMP offloading code when targeting
> a GPU meanwhile the code is not wrapped into `target` region or declare
> target. I understand to have variants and de
jhuber6 wrote:
> ~I don't think it should be GPU code generation path as there is no explicit
> `target` region used.~ Probably I missed something here. Do you expect
> regular OpenMP stuff such as `parallel` region to be emitted in the same way
> as offloading code?
Yes, the example in the d
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/122149
>From 3329b7ae7dc6044f6563f218c65f6af7498290f0 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Wed, 8 Jan 2025 12:19:53 -0600
Subject: [PATCH] [OpenMP] Allow GPUs to be targeted directly via `-fopenmp`.
Summa
jhuber6 wrote:
> I don't think it should be GPU code generation path as there is no explicit
> `target` region used.
it needs to be, otherwise the code generation for things like `#pragma omp
parallel` will be wrong. The way I see it, the DeviceRTL is `libomp.a` for the
GPU target, so we need
jhuber6 wrote:
> What code generation path would be used in this case? The GPU code generation
> or regular host OpenMP?
The GPU path, I'm treating that as the code generation path that created
correct runtime code for the GPU. I.e. you can link it with your OpenMP
offloading program and it'l
jhuber6 wrote:
> Maybe just turn on OpenMPIsTargetDevice if `gpu target + -fopenmp` is
> specified?
I'll give it a try.
https://github.com/llvm/llvm-project/pull/122149
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cg
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/122149
Summary:
Currently we prevent the following from working. However, it is
completely reasonable to be able to target the files individually.
```
$ clang --target=amdgcn-amd-amdhsa -fopenmp
```
This patch lifts th
@@ -1818,8 +1819,21 @@ void Preprocessor::ExpandBuiltinMacro(Token &Tok) {
// usual allocation and deallocation functions. Required by libc++
return 201802;
default:
+// We may get here because of aux builtins which may not be
+
@@ -1818,8 +1819,21 @@ void Preprocessor::ExpandBuiltinMacro(Token &Tok) {
// usual allocation and deallocation functions. Required by libc++
return 201802;
default:
+// We may get here because of aux builtins which may not be
+
@@ -0,0 +1,12 @@
+// REQUIRES: spirv-registered-target
+// REQUIRES: x86-registered-target
+
+// RUN: %clang_cc1 -fopenmp -triple=spirv64 -fopenmp-is-target-device \
+// RUN: -aux-triple x86_64-linux-unknown -E %s | FileCheck
-implicit-check-not=BAD %s
jhuber6 wr
@@ -0,0 +1,12 @@
+// REQUIRES: spirv-registered-target
+// REQUIRES: x86-registered-target
+
jhuber6 wrote:
These shouldn't be necessary, we're just emitting IR.
https://github.com/llvm/llvm-project/pull/121839
___
cfe
jhuber6 wrote:
> This is/was my concern. However, upon thinking further, as long as we
> RECOGNIZE/Parse/etc the builtins, it is OK I think if we report
> "!__has_builtin".
>
> That is:
>
> ```
> void foo() {
> #if __has_builtin(__builtin_x86_thing)
> __builtin_x86_thing();
> #else
> __builti
jhuber6 wrote:
> I am afraid this will break all existing CUDA/HIP programs since they expect
> to be able to parse the builtins for both host and device targets.
>
> In the spirit of single source, the compiler sees the entire code for all
> targets, including host target and all device targe
jhuber6 wrote:
> > I don't think it makes any sense for `__has_builtin` to return true when
> > the target does not in-fact have the builtin. Most of the time this is used
> > to guard target specific code, which will then be wrong if it's compiled on
> > the device. Realistically the solution
jhuber6 wrote:
I don't think it makes any sense for `__has_builtin` to return true when the
target does not in-fact have the builtin. Most of the time this is used to
guard target specific code, which will then be wrong if it's compiled on the
device. Realistically the solution that makes sens
jhuber6 wrote:
You can compile and run static C applications, I'm not sure what the threshold
is before we can start adding support to make it usable in `clang`.
https://github.com/llvm/llvm-project/pull/121123
___
cfe-commits mailing list
cfe-commits
jhuber6 wrote:
> `CodeGenHipStdPar/unsupported-builtins.cpp` is pretty interesting actually,
> it looks like it tests for some behavior in CodeGen that seems like it's
> trying to fix the exact same problem
>
> The other two tests seem to be actually unrelated breakages though.
Maybe @AlexVlx
jhuber6 wrote:
Ah, I see how it is. And it probably worked in the NVPTX / AMDGCN case because
we had valid code paths. This is definitely something that should be fixed,
because it makes no sense to say a builtin is available if you can't even use
it. Though offloading languages do tend to hat
https://github.com/jhuber6 commented:
Is it possible that we could just skip generating the builtin IDs at all for
the aux target? Or does that break something.
https://github.com/llvm/llvm-project/pull/121839
___
cfe-commits mailing list
cfe-commits@
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/120095
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
> I'm trying to understand this. Is the function being changed a generic util
> called by multiple builtins, and this change is just to make `one-as`
> exclusive to the OpenCL variant of those builtins ? Can an identical builtin
> have different behavior depending on the input l
jhuber6 wrote:
I discussed this with @t-tye, he said it's correct but wants @Pierre-vh to sign
off on it.
https://github.com/llvm/llvm-project/pull/120095
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/l
@@ -537,7 +537,11 @@ AMDGPUTargetCodeGenInfo::getLLVMSyncScopeID(const
LangOptions &LangOpts,
break;
}
- if (Ordering != llvm::AtomicOrdering::SequentiallyConsistent) {
+ // OpenCL assumes by default that atomic scopes are per-address space for
+ // non-sequentially
@@ -537,7 +537,11 @@ AMDGPUTargetCodeGenInfo::getLLVMSyncScopeID(const
LangOptions &LangOpts,
break;
}
- if (Ordering != llvm::AtomicOrdering::SequentiallyConsistent) {
+ // OpenCL assumes by default that atomic scopes are per-address space for
+ // non-sequentially
@@ -537,7 +537,11 @@ AMDGPUTargetCodeGenInfo::getLLVMSyncScopeID(const
LangOptions &LangOpts,
break;
}
- if (Ordering != llvm::AtomicOrdering::SequentiallyConsistent) {
+ // OpenCL assumes by default that atomic scopes are per-address space for
+ // non-sequentially
@@ -537,7 +537,11 @@ AMDGPUTargetCodeGenInfo::getLLVMSyncScopeID(const
LangOptions &LangOpts,
break;
}
- if (Ordering != llvm::AtomicOrdering::SequentiallyConsistent) {
+ // OpenCL assumes by default that atomic scopes are per-address space for
+ // non-sequentially
jhuber6 wrote:
Ping
https://github.com/llvm/llvm-project/pull/120095
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
> > Sure, what's left for this to work? I'm probably going to be messing around
> > with the OpenMP 'DeviceRTL' more, likely killing off the 'fatbinary' and
> > just using the per-target runtime dir stuff. I'm going to assume this
> > wouldn't work well with SPIR-V since they do
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/120145
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
> @jhuber6 Thanks, if you don't think we need any more reviews do you mind
> merging? I still don't have push (working on it). If not, could you please
> ping other reviewers? Thx
Sure, what's left for this to work? I'm probably going to be messing around
with the OpenMP 'Devic
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/120145
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/119091
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/119091
>From 767d34a0469aa67c2c47a35bc9bff29d20ae1222 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Sat, 7 Dec 2024 13:47:23 -0600
Subject: [PATCH 1/2] [OpenMP] Use generic IR for the OpenMP DeviceRTL
Summary:
We
jhuber6 wrote:
@ronlieb https://gist.github.com/jhuber6/26e3fc8473a750410d2ca1db4a65918d
https://github.com/llvm/llvm-project/pull/119091
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commit
jhuber6 wrote:
> @jhuber6, since I think this PR makes #119006 obsolete, should I merge that
> one while this one's still in the works, or close it?
I wouldn't say it's high priority. I would've landed this already if it weren't
for the downstream fork being so divergent this isn't an easy app
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/119091
>From 767d34a0469aa67c2c47a35bc9bff29d20ae1222 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Sat, 7 Dec 2024 13:47:23 -0600
Subject: [PATCH] [OpenMP] Use generic IR for the OpenMP DeviceRTL
Summary:
We prev
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/120632
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -788,16 +789,28 @@ class LLVM_LIBRARY_VISIBILITY ZOSTargetInfo : public
OSTargetInfo {
// UEFI target
template
class LLVM_LIBRARY_VISIBILITY UEFITargetInfo : public OSTargetInfo {
+ llvm::Triple Triple;
+
protected:
void getOSDefines(const LangOptions &Opts, const llv
@@ -35,6 +35,24 @@ UEFI::UEFI(const Driver &D, const llvm::Triple &Triple,
const ArgList &Args)
Tool *UEFI::buildLinker() const { return new tools::uefi::Linker(*this); }
+void UEFI::AddClangSystemIncludeArgs(const ArgList &DriverArgs,
+ A
jhuber6 wrote:
Didn't know this existed, but we have
https://github.com/llvm/llvm-project/pull/120632 tracking it now.
https://github.com/llvm/llvm-project/pull/111719
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-
@@ -820,43 +820,6 @@ class LLVM_LIBRARY_VISIBILITY X86_64TargetInfo : public
X86TargetInfo {
}
};
-// x86-64 UEFI target
-class LLVM_LIBRARY_VISIBILITY UEFIX86_64TargetInfo
-: public UEFITargetInfo {
-public:
- UEFIX86_64TargetInfo(const llvm::Triple &Triple, const Tar
@@ -820,43 +820,6 @@ class LLVM_LIBRARY_VISIBILITY X86_64TargetInfo : public
X86TargetInfo {
}
};
-// x86-64 UEFI target
-class LLVM_LIBRARY_VISIBILITY UEFIX86_64TargetInfo
-: public UEFITargetInfo {
-public:
- UEFIX86_64TargetInfo(const llvm::Triple &Triple, const Tar
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/120632
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 approved this pull request.
Seems reasonable if it passes all the tests.
https://github.com/llvm/llvm-project/pull/120632
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo
@@ -788,16 +789,28 @@ class LLVM_LIBRARY_VISIBILITY ZOSTargetInfo : public
OSTargetInfo {
// UEFI target
template
class LLVM_LIBRARY_VISIBILITY UEFITargetInfo : public OSTargetInfo {
+ llvm::Triple Triple;
protected:
void getOSDefines(const LangOptions &Opts, const llvm:
@@ -820,43 +820,6 @@ class LLVM_LIBRARY_VISIBILITY X86_64TargetInfo : public
X86TargetInfo {
}
};
-// x86-64 UEFI target
-class LLVM_LIBRARY_VISIBILITY UEFIX86_64TargetInfo
-: public UEFITargetInfo {
-public:
- UEFIX86_64TargetInfo(const llvm::Triple &Triple, const Tar
@@ -165,6 +165,9 @@ std::unique_ptr AllocateTarget(const
llvm::Triple &Triple,
case llvm::Triple::OpenBSD:
return std::make_unique>(Triple,
Opts);
+case llvm::Triple::UEFI:
+ return std::m
@@ -165,6 +165,9 @@ std::unique_ptr AllocateTarget(const
llvm::Triple &Triple,
case llvm::Triple::OpenBSD:
return std::make_unique>(Triple,
Opts);
+case llvm::Triple::UEFI:
+ return std::m
@@ -165,6 +165,9 @@ std::unique_ptr AllocateTarget(const
llvm::Triple &Triple,
case llvm::Triple::OpenBSD:
return std::make_unique>(Triple,
Opts);
+case llvm::Triple::UEFI:
+ return std::m
https://github.com/jhuber6 commented:
Should probably add something to `TargetOSMacros.def` while we're at it.
https://github.com/llvm/llvm-project/pull/120632
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailm
jhuber6 wrote:
> > Should we have an entry for `-fdefine-target-os-macros` as well?
>
> I think so, it wouldn't be a bad idea.
>
> > Also needs a test
>
> I might need some guidance on adding a test since I'm not fully familiar with
> the clang side of LLVM.
Check `./clang/test/Preprocessor
jhuber6 wrote:
Also needs a test
https://github.com/llvm/llvm-project/pull/120632
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/120632
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 commented:
Should we have an entry for `-fdefine_target_os_macros` as well?
https://github.com/llvm/llvm-project/pull/120632
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listi
@@ -790,7 +790,9 @@ template
class LLVM_LIBRARY_VISIBILITY UEFITargetInfo : public OSTargetInfo {
protected:
void getOSDefines(const LangOptions &Opts, const llvm::Triple &Triple,
-MacroBuilder &Builder) const override {}
+MacroBuilder
@@ -337,9 +337,12 @@ void AMDGPUTargetInfo::getTargetDefines(const LangOptions
&Opts,
if (hasFastFMA())
Builder.defineMacro("FP_FAST_FMA");
- Builder.defineMacro("__AMDGCN_WAVEFRONT_SIZE__", Twine(WavefrontSize));
- // ToDo: deprecate this macro for naming consistency
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/112849
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -337,9 +337,12 @@ void AMDGPUTargetInfo::getTargetDefines(const LangOptions
&Opts,
if (hasFastFMA())
Builder.defineMacro("FP_FAST_FMA");
- Builder.defineMacro("__AMDGCN_WAVEFRONT_SIZE__", Twine(WavefrontSize));
- // ToDo: deprecate this macro for naming consistency
@@ -337,9 +337,12 @@ void AMDGPUTargetInfo::getTargetDefines(const LangOptions
&Opts,
if (hasFastFMA())
Builder.defineMacro("FP_FAST_FMA");
- Builder.defineMacro("__AMDGCN_WAVEFRONT_SIZE__", Twine(WavefrontSize));
- // ToDo: deprecate this macro for naming consistency
https://github.com/jhuber6 commented:
I'm not sure, those enums might evaluate to zero but it makes it clearer and
correct if they ever change. Realistically, the chance of that happening is
pretty much zero, but still. I don't see this warning show up when I check with
my LSP (though I do se
@@ -537,7 +537,11 @@ AMDGPUTargetCodeGenInfo::getLLVMSyncScopeID(const
LangOptions &LangOpts,
break;
}
- if (Ordering != llvm::AtomicOrdering::SequentiallyConsistent) {
+ // OpenCL assumes by default that atomic scopes are per-address space for
+ // non-sequentially
@@ -2829,10 +2829,13 @@ void tools::addOpenMPDeviceRTL(const Driver &D,
LibraryPaths.emplace_back(LibPath);
OptSpecifier LibomptargetBCPathOpt =
- Triple.isAMDGCN() ? options::OPT_libomptarget_amdgpu_bc_path_EQ
-: options::OPT_libomptarget_nv
@@ -735,11 +736,15 @@ wrapDeviceImages(ArrayRef>
Buffers,
}
Expected>>
-bundleOpenMP(ArrayRef Images) {
+bundleOpenMP(SmallVectorImpl &Images) {
jhuber6 wrote:
But this function's job is to return a new list of binary files after
serializing the input, can'
1 - 100 of 1727 matches
Mail list logo
