https://github.com/AlexVlx created
https://github.com/llvm/llvm-project/pull/88182
At the moment, Clang is rather liberal in assuming that 0 (and by extension
unqualified) is always a safe default. This does not work for targets that
actually use a different value for the default / generic AS
llvmbot wrote:
@llvm/pr-subscribers-clang-codegen
Author: Alex Voicu (AlexVlx)
Changes
At the moment, Clang is rather liberal in assuming that 0 (and by extension
unqualified) is always a safe default. This does not work for targets that
actually use a different value for the default /
github-actions[bot] wrote:
: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 8795822f6ae2e82e23f7fd87a84d6d273e6c04ac
453e96aafd02bd19f44c0383acb74b930d2767c9 --
jrtc27 wrote:
> querying a modules global AS from the target, rather than from the data
> layout (some DL's are incomplete, e.g. SPIRV's)
That is a bug in those DataLayouts
https://github.com/llvm/llvm-project/pull/88182
___
cfe-commits mailing list
jrtc27 wrote:
> querying a modules default AS from the target, rather than assuming it's 0
I do think this should likely be part of the DataLayout. We have defaults for
globals, alloca and functions, but no generic "give me the address space for
`void *`"-like thing in LLVM itself.
https://gi
https://github.com/AlexVlx updated
https://github.com/llvm/llvm-project/pull/88182
>From 426e74cabb003eb5dc83adf347a5800d49bc87b7 Mon Sep 17 00:00:00 2001
From: Alex Voicu
Date: Mon, 18 Mar 2024 11:49:12 +
Subject: [PATCH 1/5] Start migrating away from the embedded assumption that
the defa
https://github.com/AlexVlx updated
https://github.com/llvm/llvm-project/pull/88182
>From 426e74cabb003eb5dc83adf347a5800d49bc87b7 Mon Sep 17 00:00:00 2001
From: Alex Voicu
Date: Mon, 18 Mar 2024 11:49:12 +
Subject: [PATCH 1/6] Start migrating away from the embedded assumption that
the defa
efriedma-quic wrote:
Why can't we just declare that the "generic" address-space must always be 0?
The specific numbers we use for address-spaces are completely arbitrary anyway.
https://github.com/llvm/llvm-project/pull/88182
___
cfe-commits mailing
@@ -4551,6 +4554,7 @@ llvm::Constant *CodeGenModule::GetOrCreateLLVMFunction(
llvm::Function *F =
llvm::Function::Create(FTy, llvm::Function::ExternalLinkage,
+ getDataLayout().getProgramAddressSpace(),
efriedma-quic wrote:
@@ -3581,8 +3582,10 @@ ConstantAddress
CodeGenModule::GetAddrOfTemplateParamObject(
isExternallyVisible(TPO->getLinkageAndVisibility().getLinkage())
? llvm::GlobalValue::LinkOnceODRLinkage
: llvm::GlobalValue::InternalLinkage;
- auto *GV = new llvm::
jrtc27 wrote:
> Why can't we just declare that the "generic" address-space must always be 0?
> The specific numbers we use for address-spaces are completely arbitrary
> anyway.
https://github.com/CTSRD-CHERI/llvm-project/issues/621 is what I wrote up for
CHERI LLVM, but is a bit terse if you
rjmccall wrote:
It's very uncommon for LLVM to need to come up with an address space on its
own, as opposed to just propagating the original address space of some memory /
operation as chosen by the frontend. LLVM occasionally creates new storage
allocations, but usually they're (non-escaping
https://github.com/AlexVlx commented:
> Why can't we just declare that the "generic" address-space must always be 0?
> The specific numbers we use for address-spaces are completely arbitrary
> anyway.
If we were to do this, some targets would need to change to accomodate it; it
would also p
https://github.com/AlexVlx edited
https://github.com/llvm/llvm-project/pull/88182
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AlexVlx commented:
> It's very uncommon for LLVM to need to come up with an address space on its
> own, as opposed to just propagating the original address space of some memory
> / operation as chosen by the frontend. LLVM occasionally creates new storage
> allocations, but
https://github.com/AlexVlx edited
https://github.com/llvm/llvm-project/pull/88182
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rjmccall wrote:
> Why can't we just declare that the "generic" address-space must always be 0?
> The specific numbers we use for address-spaces are completely arbitrary
> anyway.
I don't think this works; there's nothing that LLVM could possibly do with a
generic AS that would justify it bein
https://github.com/AlexVlx edited
https://github.com/llvm/llvm-project/pull/88182
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AlexVlx commented:
> > querying a modules global AS from the target, rather than from the data
> > layout (some DL's are incomplete, e.g. SPIRV's)
That is a bug in those DataLayouts
Do we spell out the requirement somewhere? I am only asking because, for
example, [neither
rjmccall wrote:
> I'm not quite sure how to parse this comment, could you explain what you have
> in mind here? The problem is precisely that the FE assumes 0 is fine / picks
> it by default, which ends up into dangerzones when e.g. a target happened to
> use 0 to point to private (stack). I f
jrtc27 wrote:
> > I'm not quite sure how to parse this comment, could you explain what you
> > have in mind here? The problem is precisely that the FE assumes 0 is fine /
> > picks it by default, which ends up into dangerzones when e.g. a target
> > happened to use 0 to point to private (stack
efriedma-quic wrote:
> > > querying a modules global AS from the target, rather than from the data
> > > layout (some DL's are incomplete, e.g. SPIRV's)
>
> That is a bug in those DataLayouts
>
> Do we spell out the requirement somewhere? I am only asking because, for
> example, [neither SPIR
rjmccall wrote:
> Libcall emission needs to know what AS to use for pointer arguments to things
> like __sync/__atomic implementations and various string-y mem*/str*
> functions. That's the main one that comes to mind from our experience in
> CHERI LLVM, and current LLVM just assumes that's AS
AlexVlx wrote:
> > I'm not quite sure how to parse this comment, could you explain what you
> > have in mind here? The problem is precisely that the FE assumes 0 is fine /
> > picks it by default, which ends up into dangerzones when e.g. a target
> > happened to use 0 to point to private (stac
AlexVlx wrote:
> > I'm not quite sure how to parse this comment, could you explain what you
> > have in mind here? The problem is precisely that the FE assumes 0 is fine /
> > picks it by default, which ends up into dangerzones when e.g. a target
> > happened to use 0 to point to private (stac
https://github.com/AlexVlx updated
https://github.com/llvm/llvm-project/pull/88182
>From 426e74cabb003eb5dc83adf347a5800d49bc87b7 Mon Sep 17 00:00:00 2001
From: Alex Voicu
Date: Mon, 18 Mar 2024 11:49:12 +
Subject: [PATCH 1/7] Start migrating away from the embedded assumption that
the defa
@@ -4551,6 +4554,7 @@ llvm::Constant *CodeGenModule::GetOrCreateLLVMFunction(
llvm::Function *F =
llvm::Function::Create(FTy, llvm::Function::ExternalLinkage,
+ getDataLayout().getProgramAddressSpace(),
AlexVlx wrote:
Whoop
@@ -2216,7 +2216,7 @@ static llvm::Value *EmitTypeidFromVTable(CodeGenFunction
&CGF, const Expr *E,
}
llvm::Value *CodeGenFunction::EmitCXXTypeidExpr(const CXXTypeidExpr *E) {
- llvm::Type *PtrTy = llvm::PointerType::getUnqual(getLLVMContext());
+ llvm::Type *PtrTy = Int8Pt
@@ -2216,7 +2216,7 @@ static llvm::Value *EmitTypeidFromVTable(CodeGenFunction
&CGF, const Expr *E,
}
llvm::Value *CodeGenFunction::EmitCXXTypeidExpr(const CXXTypeidExpr *E) {
- llvm::Type *PtrTy = llvm::PointerType::getUnqual(getLLVMContext());
+ llvm::Type *PtrTy = Int8Pt
@@ -3581,8 +3582,10 @@ ConstantAddress
CodeGenModule::GetAddrOfTemplateParamObject(
isExternallyVisible(TPO->getLinkageAndVisibility().getLinkage())
? llvm::GlobalValue::LinkOnceODRLinkage
: llvm::GlobalValue::InternalLinkage;
- auto *GV = new llvm::
@@ -3581,8 +3582,10 @@ ConstantAddress
CodeGenModule::GetAddrOfTemplateParamObject(
isExternallyVisible(TPO->getLinkageAndVisibility().getLinkage())
? llvm::GlobalValue::LinkOnceODRLinkage
: llvm::GlobalValue::InternalLinkage;
- auto *GV = new llvm::
@@ -3581,8 +3582,10 @@ ConstantAddress
CodeGenModule::GetAddrOfTemplateParamObject(
isExternallyVisible(TPO->getLinkageAndVisibility().getLinkage())
? llvm::GlobalValue::LinkOnceODRLinkage
: llvm::GlobalValue::InternalLinkage;
- auto *GV = new llvm::
https://github.com/AlexVlx updated
https://github.com/llvm/llvm-project/pull/88182
>From 426e74cabb003eb5dc83adf347a5800d49bc87b7 Mon Sep 17 00:00:00 2001
From: Alex Voicu
Date: Mon, 18 Mar 2024 11:49:12 +
Subject: [PATCH 01/10] Start migrating away from the embedded assumption that
the de
https://github.com/AlexVlx commented:
> This adds a third copy of the same test, can we just merge them add add three
> RUN lines with different CHECK prefixes?
I've merged the address-space related ones, but I've left the basic one in
place.
https://github.com/llvm/llvm-project/pull/88182
_
https://github.com/AlexVlx edited
https://github.com/llvm/llvm-project/pull/88182
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 %s -triple spirv64-unknown-unknown -fsycl-is-device
-emit-llvm -fcxx-exceptions -fexceptions -std=c++11 -o - | FileCheck %s
arichardson wrote:
Instead of duplicating all these files, could you add one additional RUN: line
to
https://github.com/AlexVlx updated
https://github.com/llvm/llvm-project/pull/88182
>From 426e74cabb003eb5dc83adf347a5800d49bc87b7 Mon Sep 17 00:00:00 2001
From: Alex Voicu
Date: Mon, 18 Mar 2024 11:49:12 +
Subject: [PATCH 1/7] Start migrating away from the embedded assumption that
the defa
https://github.com/AlexVlx updated
https://github.com/llvm/llvm-project/pull/88182
>From 426e74cabb003eb5dc83adf347a5800d49bc87b7 Mon Sep 17 00:00:00 2001
From: Alex Voicu
Date: Mon, 18 Mar 2024 11:49:12 +
Subject: [PATCH 1/8] Start migrating away from the embedded assumption that
the defa
@@ -3581,8 +3582,10 @@ ConstantAddress
CodeGenModule::GetAddrOfTemplateParamObject(
isExternallyVisible(TPO->getLinkageAndVisibility().getLinkage())
? llvm::GlobalValue::LinkOnceODRLinkage
: llvm::GlobalValue::InternalLinkage;
- auto *GV = new llvm::
https://github.com/AlexVlx updated
https://github.com/llvm/llvm-project/pull/88182
>From 426e74cabb003eb5dc83adf347a5800d49bc87b7 Mon Sep 17 00:00:00 2001
From: Alex Voicu
Date: Mon, 18 Mar 2024 11:49:12 +
Subject: [PATCH 1/8] Start migrating away from the embedded assumption that
the defa
@@ -2216,7 +2216,7 @@ static llvm::Value *EmitTypeidFromVTable(CodeGenFunction
&CGF, const Expr *E,
}
llvm::Value *CodeGenFunction::EmitCXXTypeidExpr(const CXXTypeidExpr *E) {
- llvm::Type *PtrTy = llvm::PointerType::getUnqual(getLLVMContext());
+ llvm::Type *PtrTy = Int8Pt
https://github.com/arichardson requested changes to this pull request.
The code change itself looks good to me and will be helpful for e.g. the CHERI
fork.
However, I don't think copy-pasting tests is a good strategy it would be much
cleaner to just add a new RUN line to the existing tests.
h
https://github.com/arichardson edited
https://github.com/llvm/llvm-project/pull/88182
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,24 @@
+// RUN: %clang_cc1 -I%S %s -triple spirv64-unknown-unknown -fsycl-is-device
-emit-llvm -fcxx-exceptions -fexceptions -o - | FileCheck %s
+struct A { virtual void f(); };
+struct B : A { };
+
+// CHECK: {{define.*@_Z1fP1A}}
+// CHECK-SAME: personality ptr @__gxx
@@ -0,0 +1,32 @@
+// RUN: %clang_cc1 -triple spirv64-unknown-unknown -fsycl-is-device -std=c++20
%s -emit-llvm -o - | FileCheck %s
+
+struct S { char buf[32]; };
arichardson wrote:
Same here, and I can see that the two copies are out-of sync. Would be good to
m
@@ -0,0 +1,24 @@
+// RUN: %clang_cc1 -I%S %s -triple spirv64-unknown-unknown -fsycl-is-device
-emit-llvm -fcxx-exceptions -fexceptions -o - | FileCheck %s
arichardson wrote:
Could you use update_cc_test_checks --check-globals here to just check the
whole functi
@@ -366,7 +366,8 @@ CodeGenModule::CodeGenModule(ASTContext &C,
IntTy = llvm::IntegerType::get(LLVMContext, C.getTargetInfo().getIntWidth());
IntPtrTy = llvm::IntegerType::get(LLVMContext,
C.getTargetInfo().getMaxPointerWidth());
- Int8PtrTy = llvm::PointerType::get(LL
https://github.com/arichardson edited
https://github.com/llvm/llvm-project/pull/88182
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AlexVlx updated
https://github.com/llvm/llvm-project/pull/88182
>From 426e74cabb003eb5dc83adf347a5800d49bc87b7 Mon Sep 17 00:00:00 2001
From: Alex Voicu
Date: Mon, 18 Mar 2024 11:49:12 +
Subject: [PATCH 1/8] Start migrating away from the embedded assumption that
the defa
https://github.com/AlexVlx updated
https://github.com/llvm/llvm-project/pull/88182
>From 426e74cabb003eb5dc83adf347a5800d49bc87b7 Mon Sep 17 00:00:00 2001
From: Alex Voicu
Date: Mon, 18 Mar 2024 11:49:12 +
Subject: [PATCH 1/8] Start migrating away from the embedded assumption that
the defa
https://github.com/AlexVlx updated
https://github.com/llvm/llvm-project/pull/88182
>From 426e74cabb003eb5dc83adf347a5800d49bc87b7 Mon Sep 17 00:00:00 2001
From: Alex Voicu
Date: Mon, 18 Mar 2024 11:49:12 +
Subject: [PATCH 1/9] Start migrating away from the embedded assumption that
the defa
@@ -2216,7 +2216,7 @@ static llvm::Value *EmitTypeidFromVTable(CodeGenFunction
&CGF, const Expr *E,
}
llvm::Value *CodeGenFunction::EmitCXXTypeidExpr(const CXXTypeidExpr *E) {
- llvm::Type *PtrTy = llvm::PointerType::getUnqual(getLLVMContext());
+ llvm::Type *PtrTy = Int8Pt
52 matches
Mail list logo
