bjope wrote:
Thanks. I see now that it did not work with older clang (at least not 19.1.0).
It did however work with our downstream fork before this patch. I haven't
figured out how we avoided the error in the past. I guess we must have
something downstream that avoided the error in the past,
bjope wrote:
This seems to break something with variadic args and the gcc hack with ## to
ignore the trailing comma error:
```
#include
#define debug_ok(format, ...) fprintf(stderr, format, ## __VA_ARGS__)
void foo() {
debug_ok("qwerty");
}
#define debug_nok(...) fprintf(stderr, "qwerty",
@@ -0,0 +1,31 @@
+//===--- DiagnosticIDs.inc --*- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apa
bjope wrote:
Ok. Thanks for quick feedback and clarification that regressions can be
expected when having different pointer sizes (or rather different index widths).
Btw, I also think the gep with "ptr null" is probably the result of
over-reducing the original program. I will need to continue
bjope wrote:
But isn't it still a bit weird that if I change the datalayout to set the same
pointer size for the two address spaces, then BasicAA is able to derive that
there is NoAlias (https://godbolt.org/z/vhcG4jx7a), and the same goes even if
using same address space for both accesses (htt
bjope wrote:
I'm investigating various regressions we've seen downstream after this patch.
I reduced one test down to this IR (also see https://godbolt.org/z/E4caeWcYd):
```
target datalayout = "p:16:8-p1:32:8"
define void @gazonk() {
entry:
%alloca = alloca i8, align 1
br label %loop
loop
bjope wrote:
Added some reviewers based on people that have touched code related to
"diagnostics" (but don't really know much about the fix, nor who might know
anything about this particular code in diagtool). Feel free to redirect to
someone else (or let me know if I should try to find other
https://github.com/bjope closed https://github.com/llvm/llvm-project/pull/120487
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/bjope created
https://github.com/llvm/llvm-project/pull/120487
Found assertion failures when using EXPENSIVE_CHECKS and running lit tests for
APINotes:
Assertion `left.first != right.first && "two entries for the same version"'
failed.
It seems like std::is_sorted is ver
bjope wrote:
Seeing same fault as @zeroomega .
I think problem is related to LLVM_ENABLE_PER_TARGET_RUNTIME_DIR. When that is
set to ON the install path is extended (in libunwind/CMakeLIsts.txt):
```
set(LIBUNWIND_TARGET_SUBDIR ${LLVM_DEFAULT_TARGET_TRIPLE})
if(LIBUNWIND_LIBDIR_SUBDIR)
@@ -489,13 +485,7 @@ static DiagnosticIDs::Level toLevel(diag::Severity SV) {
DiagnosticIDs::Level
DiagnosticIDs::getDiagnosticLevel(unsigned DiagID, SourceLocation Loc,
const DiagnosticsEngine &Diag) const {
- // Handle custom diagnostics, wh
bjope wrote:
> > Is that as expected? If so, how should snprintf be used to avoid the
> > warning?
>
> Yes, this is expected. According to the C++ Safe Buffers programming model,
> buffer pointers should be changed to std::span.
But this new warning is given also when compiling C code. As in
@@ -103,6 +103,13 @@ class TypeDescriptor {
/// representation is that of bitcasting the floating-point value to an
/// integer type.
TK_Float = 0x0001,
+/// An _BitInt(N) type. Lowest bit is 1 for a signed value, 0 for an
+/// unsigned value. Remaining bits
@@ -125,6 +137,25 @@ class TypeDescriptor {
return 1 << (TypeInfo >> 1);
}
+ const char *getBitIntBitCountPointer() const {
+DCHECK(isBitIntTy());
+DCHECK(isSignedBitIntTy());
+// Scan Name for zero and return the next address
+const char *p = getTypeNam
@@ -3298,22 +3315,40 @@ LValue CodeGenFunction::EmitPredefinedLValue(const
PredefinedExpr *E) {
/// { i16 TypeKind, i16 TypeInfo }
/// \endcode
///
-/// followed by an array of i8 containing the type name. TypeKind is 0 for an
-/// integer, 1 for a floating point value, and
https://github.com/bjope closed https://github.com/llvm/llvm-project/pull/90845
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/bjope updated https://github.com/llvm/llvm-project/pull/90845
From 15b41263850f4428c3a273f404c9c3543985e47d Mon Sep 17 00:00:00 2001
From: Bjorn Pettersson
Date: Thu, 2 May 2024 12:42:00 +0200
Subject: [PATCH] [clang][CodeGen] Fix in codegen for
__builtin_popcountg/ctzg/clzg
bjope wrote:
> Please add a testcase for i1/i2 (which are the only cases where this actually
> matters).
I added tests in a new file (builtins-bitint.c) to show that we get expected
results for a target that isn't treating a zero input to ctzg/clzg as poison.
https://github.com/llvm/llvm-proj
https://github.com/bjope updated https://github.com/llvm/llvm-project/pull/90845
From bab0da08c41ed13935ad607e633939b6870d4ffb Mon Sep 17 00:00:00 2001
From: Bjorn Pettersson
Date: Thu, 2 May 2024 12:42:00 +0200
Subject: [PATCH 1/2] [clang][CodeGen] Fix in codegen for
__builtin_popcountg/ctzg/c
@@ -3216,7 +3216,8 @@ RValue CodeGenFunction::EmitBuiltinExpr(const GlobalDecl
GD, unsigned BuiltinID,
case Builtin::BI__popcnt64:
case Builtin::BI__builtin_popcount:
case Builtin::BI__builtin_popcountl:
- case Builtin::BI__builtin_popcountll: {
+ case Builtin::BI__bui
https://github.com/bjope created https://github.com/llvm/llvm-project/pull/90845
Make sure that the result from the popcnt/ctlz/cttz intrinsics is unsigned
casted to int, rather than casted as a signed value, when expanding the
__builtin_popcountg/__builtin_ctzg/__builtin_clzg builtins.
An exa
https://github.com/bjope closed https://github.com/llvm/llvm-project/pull/88004
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -146,6 +146,15 @@ struct BinOpInfo {
return UnOp->getSubExpr()->getType()->isFixedPointType();
return false;
}
+
+ /// Check if the RHS has a signed integer representation.
bjope wrote:
This is a Doxygen style comment (like the ones for other f
bjope wrote:
ping
https://github.com/llvm/llvm-project/pull/88004
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/bjope created https://github.com/llvm/llvm-project/pull/88004
Commit 5f87957fefb21d454f2f (pull-requst #80515) corrected some codegen
problems related to _BitInt types being used as shift exponents. But it did not
fix it properly for the special case when the shift count oper
https://github.com/bjope approved this pull request.
https://github.com/llvm/llvm-project/pull/83573
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -101,17 +101,6 @@
/// ###
-/// Check that the warning is thrown when the libomptarget bitcode library is
not found.
-/// Libomptarget requires sm_52 or newer so an sm_52 bitcode library should
never
@@ -101,17 +101,6 @@
/// ###
-/// Check that the warning is thrown when the libomptarget bitcode library is
not found.
-/// Libomptarget requires sm_52 or newer so an sm_52 bitcode library should
never
bjope wrote:
Problem 1 can be solved by flipping the order.
But Problem 2 would remain as it doesn't depend on the order.
https://github.com/llvm/llvm-project/pull/83282
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi
bjope wrote:
Hi @jhuber6, @MaskRay
We are having some problems with this patch on a server where the file
/lib64/libomptarget-nvptx-sm_52.bc exists.
The test case that fails is clang/test/Driver/openmp-offload-gpu.c.
**Problem 1**
I think one problem is related to this check line
`// CHK-ENV-
https://github.com/bjope approved this pull request.
LG
https://github.com/llvm/llvm-project/pull/80515
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
bjope wrote:
@cor3ntin : I've verified that this would solve the problem that I noticed
downstream. Thanks!
https://github.com/llvm/llvm-project/pull/80652
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/
@@ -0,0 +1,25 @@
+// RUN: not %clang_cc1 -std=c++2c -ast-dump %s | FileCheck %s
+
+namespace InvalidPacksShouldNotCrash {
+
+struct NotAPack;
+template typename Tp>
+void not_pack() {
+int i = 0;
+i...[0]; // expected-error {{i does not refer to the name of a parameter
bjope wrote:
@cor3ntin , our downstream code is doing some extra semantic checks using code
like this in Sema::CheckVariableDeclarationType:
```
if (!T->isIncompleteType() && !isDependentOrGNUAutoType(T) &&
!T->isPlaceholderType()) {
uint64_t Size = Context.getTypeSizeInChars(T).getQuant
bjope wrote:
Seems like this didn't really solve the problem reported by @bevin-hansson (at
least not completely).
The new test case fails for us:
```
FAIL: Clang :: AST/ast-dump-pack-indexing-crash.cpp (401 of 78930)
TEST 'Clang :: AST/ast-dump-pack-indexing-crash.cpp'
FA
@@ -0,0 +1,36 @@
+// RUN: %clang_cc1 %s -O0 -fsanitize=shift-exponent -emit-llvm -o - |
FileCheck %s
+
+// Checking that the code generation is using the unextended/untruncated
+// exponent values and capping the values accordingly
+
+// CHECK-LABEL: define{{.*}} i32 @test_left_v
@@ -4121,6 +4121,13 @@ Value *ScalarExprEmitter::GetWidthMinusOneValue(Value*
LHS,Value* RHS) {
Ty = cast(VT->getElementType());
else
Ty = cast(LHS->getType());
+ // Testing with small _BitInt types has shown that Ty->getBitwidth() - 1
bjope wrote:
@@ -0,0 +1,36 @@
+// RUN: %clang_cc1 %s -O0 -fsanitize=shift-exponent -emit-llvm -o - |
FileCheck %s
bjope wrote:
I think you for example want to use `-std=c2x -triple=x86_64-unknown-linux`
here.
(Not sure exactly if you for example need the triple, but I fear
bjope wrote:
Make sure the commit message refers to fixing #80135.
(Github is a bit weird, so if you want to use the "squash an merge" support in
the web UI later, then I think you need to update the first comment in the
"Conversation", rather than updating the commits on this pull-request bra
bjope wrote:
I don't know much about this code, so I can't really judge if this is good and
wanted etc.
When I did opaque pointer cleanups myself earlier (removing some no-op bitcasts
and using PointerType::get etc) I did leave lots of things like this around on
purpose, as even if the types
bjope wrote:
> > Here is another thing that I noticed after this patch:
> > https://godbolt.org/z/1P7bnKGjh
> > So early instcombine is eliminating an `and` operation (in the foo
> > example), resulting in simplifycfg not being able to collapse the control
> > flow any longer.
>
> I don't thi
bjope wrote:
Here is another thing that I noticed after this patch:
https://godbolt.org/z/1P7bnKGjh
So early instcombine is eliminating an `and` operation (in the foo example),
resulting in simplifycfg not being able to collapse the control flow any longer.
Maybe I should file a separate issu
bjope wrote:
> @bjope It looks like the InstCombine changes enable IndVars to perform LFTR,
> which is unprofitable in this case. Though the `umax(1)` call is actually
> completely unnecessary here, but SCEV doesn't realize it. I've put up #75039
> to fix that. Does that improve things for you
bjope wrote:
Is the behavior seen in this example expected?
https://godbolt.org/z/f8eqEnsq6
The comments in InstCombineCompares kind of indicates that you try to avoid
changing a signed predicate to a unsigned. But isn't that what happens here. As
well as increasing the instruction count by
@@ -2282,6 +2282,15 @@ Instruction
*InstCombinerImpl::visitGetElementPtrInst(GetElementPtrInst &GEP) {
if (MadeChange)
return &GEP;
+ // Canonicalize constant GEPs to i8 type.
bjope wrote:
Right. So things can be expected to just work (given getTypeSt
@@ -2282,6 +2282,15 @@ Instruction
*InstCombinerImpl::visitGetElementPtrInst(GetElementPtrInst &GEP) {
if (MadeChange)
return &GEP;
+ // Canonicalize constant GEPs to i8 type.
bjope wrote:
FWIW, this is a bit interesting downstream with non-8-bit addr
bjope wrote:
Tracked down some miscompiles found downstream that points at this commit.
Also wrote a new issue here about it:
https://github.com/llvm/llvm-project/issues/73512
https://github.com/llvm/llvm-project/pull/70778
___
cfe-commits mailing lis
@@ -1262,6 +1262,18 @@ bool MachineLICMBase::IsProfitableToHoist(MachineInstr
&MI,
return false;
}
+ // If we have a COPY with other uses in the loop, hoist to allow the users to
bjope wrote:
It is a bit tricky of course, depending on the properties o
@@ -1262,6 +1262,18 @@ bool MachineLICMBase::IsProfitableToHoist(MachineInstr
&MI,
return false;
}
+ // If we have a COPY with other uses in the loop, hoist to allow the users to
bjope wrote:
For info: Downstream this caused regressions in some of our
https://github.com/bjope updated https://github.com/llvm/llvm-project/pull/71162
From 1fb659fa15568ec8256824339860de724853c6e3 Mon Sep 17 00:00:00 2001
From: Bjorn Pettersson
Date: Thu, 2 Nov 2023 22:00:52 +0100
Subject: [PATCH 1/2] [clangd] Check for valid source location in
ExtractionContext:
@@ -0,0 +1,11 @@
+// RUN: cp %s %t.c
bjope wrote:
Well, I forgot to add the [[]] thing around the call. Now I'm back on track
again :-)
https://github.com/llvm/llvm-project/pull/71162
___
cfe-commits mailing list
cfe-
@@ -0,0 +1,11 @@
+// RUN: cp %s %t.c
bjope wrote:
I've been trying to do that, but so far no luck. I hit this assertion in
TweakTesting.h:
` assert(!A.points().empty() || !A.ranges().empty());
`
https://github.com/llvm/llvm-project/pull/71162
https://github.com/bjope closed https://github.com/llvm/llvm-project/pull/71415
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,29 @@
+# RUN: clangd -lit-test < %s | FileCheck %s
bjope wrote:
Thanks. I'm not that familiar with the clangd test cases. But I've update the
pull-request with a unittest instead.
https://github.com/llvm/llvm-project/pull/71415
__
https://github.com/bjope updated https://github.com/llvm/llvm-project/pull/71415
From 2b1af2bff6432a50eb725adf86e6cfcc52cc020b Mon Sep 17 00:00:00 2001
From: Bjorn Pettersson
Date: Mon, 6 Nov 2023 17:27:28 +0100
Subject: [PATCH 1/2] [clangd] Allow hover over 128-bit variable without
crashing
W
https://github.com/bjope created https://github.com/llvm/llvm-project/pull/71415
When hovering over variables larger than 64 bits, with more than 64 active
bits, there were assertion failures since Hover is trying to print the value as
a 64-bit hex value.
There is already protection avoiding t
bjope wrote:
Hi reviewers. I don't know much about clangd so looking for feedback on this
patch to know if it is the correct thing to do.
Not sure exactly who knows this part of the code, so please let me know if
someone else should review this!
https://github.com/llvm/llvm-project/pull/71162
https://github.com/bjope created https://github.com/llvm/llvm-project/pull/71162
If the code has a call to an implicitly declared function, an expression could
end up referencing declarations without valid source locations. So when doing
the exprIsValidOutside check we could end up calling
Sou
@@ -12120,8 +12120,7 @@ static void DiagnoseBadShiftValues(Sema& S, ExprResult
&LHS, ExprResult &RHS,
auto FXSema = S.Context.getFixedPointSemantics(LHSExprType);
LeftSize = FXSema.getWidth() - (unsigned)FXSema.hasUnsignedPadding();
}
- llvm::APInt LeftBits(Right.ge
@@ -12120,8 +12120,7 @@ static void DiagnoseBadShiftValues(Sema& S, ExprResult
&LHS, ExprResult &RHS,
auto FXSema = S.Context.getFixedPointSemantics(LHSExprType);
LeftSize = FXSema.getWidth() - (unsigned)FXSema.hasUnsignedPadding();
}
- llvm::APInt LeftBits(Right.ge
bjope wrote:
> > I guess I don't know how pull requests and reviewing works in github. I
> > actually added 3 comments on this patch a several days (or weeks) ago. But
> > turns out that they were "pending" because I had only "started review" and
> > not found the place to "submit review".
>
@@ -3280,7 +3280,7 @@ class llvm::gvn::GVNLegacyPass : public FunctionPass {
if (skipFunction(F))
return false;
-auto *LIWP = getAnalysisIfAvailable();
+auto &LIWP = getAnalysis();
bjope wrote:
IIUC GVN doesn't depend on LoopInfo itself. It
@@ -935,7 +935,7 @@ bool
AArch64ConditionalCompares::runOnMachineFunction(MachineFunction &MF) {
SchedModel = MF.getSubtarget().getSchedModel();
MRI = &MF.getRegInfo();
DomTree = &getAnalysis();
- Loops = getAnalysisIfAvailable();
+ Loops = &getAnalysis();
https://github.com/bjope edited https://github.com/llvm/llvm-project/pull/65729
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -261,7 +261,7 @@ bool VirtRegRewriter::runOnMachineFunction(MachineFunction
&fn) {
Indexes = &getAnalysis();
LIS = &getAnalysis();
VRM = &getAnalysis();
- DebugVars = getAnalysisIfAvailable();
+ DebugVars = &getAnalysis();
bjope wrote:
Not sure how
https://github.com/bjope commented:
I guess I don't know how pull requests and reviewing works in github. I
actually added 3 comments on this patch a several days (or weeks) ago. But
turns out that they were "pending" because I had only "started review" and not
found the place to "submit revie
@@ -3280,7 +3280,7 @@ class llvm::gvn::GVNLegacyPass : public FunctionPass {
if (skipFunction(F))
return false;
-auto *LIWP = getAnalysisIfAvailable();
+auto &LIWP = getAnalysis();
bjope wrote:
IIUC GVN doesn't depend on LoopInfo itself. It
https://github.com/bjope edited https://github.com/llvm/llvm-project/pull/65729
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/bjope closed https://github.com/llvm/llvm-project/pull/68590
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/bjope updated https://github.com/llvm/llvm-project/pull/68590
From 8ef4560759280bbc14e0dc6c01efc036d0410dca Mon Sep 17 00:00:00 2001
From: Bjorn Pettersson
Date: Mon, 9 Oct 2023 16:13:39 +0200
Subject: [PATCH] [Sema] Handle large shift counts in GetExprRange
GetExprRange did
https://github.com/bjope updated https://github.com/llvm/llvm-project/pull/68590
From 44eedec9dae39e72d5474426a15a07d9be4144fc Mon Sep 17 00:00:00 2001
From: Bjorn Pettersson
Date: Mon, 9 Oct 2023 16:13:39 +0200
Subject: [PATCH 1/3] [Sema] Handle large shift counts in GetExprRange
GetExprRange
@@ -219,6 +219,10 @@ Bug Fixes in This Version
- Clang no longer considers the loss of ``__unaligned`` qualifier from objects
as
an invalid conversion during method function overload resolution.
+- Fixed an issue when a shift count larger than ``__INT64_MAX__``, in a right
bjope wrote:
> So the change itself looks right. The comment at the top of the test belongs
> in the commit message/github discussion, not in the test itself.
>
> Also, needs a release note.
Thanks. I pushed an update. It fixes the test case to just explain the purpose
of the tests. And I add
https://github.com/bjope updated https://github.com/llvm/llvm-project/pull/68590
From 44eedec9dae39e72d5474426a15a07d9be4144fc Mon Sep 17 00:00:00 2001
From: Bjorn Pettersson
Date: Mon, 9 Oct 2023 16:13:39 +0200
Subject: [PATCH 1/2] [Sema] Handle large shift counts in GetExprRange
GetExprRange
https://github.com/bjope created https://github.com/llvm/llvm-project/pull/68590
GetExprRange did not expect that very large shift counts when
narrowing the range based on logical right shifts. So with inputs
such as
*a >> 123456789012345678901uwb
it would hit assertions about trying to conve
@@ -1123,9 +1123,7 @@ void CodeGenFunction::StartFunction(GlobalDecl GD,
QualType RetTy,
if (!CurFnInfo->getReturnInfo().getIndirectByVal()) {
ReturnValuePointer =
CreateDefaultAlignTempAlloca(Int8PtrTy, "result.ptr");
- Builder.CreateStore(Builder.Cre
https://github.com/bjope edited https://github.com/llvm/llvm-project/pull/68091
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -331,6 +340,56 @@ static void SetInstallDir(SmallVectorImpl
&argv,
// path being a symlink.
SmallString<128> InstalledPath(argv[0]);
+#if defined(__linux__)
bjope wrote:
I was kind of thinking the same. And then started to wonder about why
SetInstall
https://github.com/bjope closed https://github.com/llvm/llvm-project/pull/65624
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/bjope updated https://github.com/llvm/llvm-project/pull/65624
From caa626ea4e813c7061b44f6b4336f31fce511f4b Mon Sep 17 00:00:00 2001
From: Bjorn Pettersson
Date: Thu, 7 Sep 2023 13:08:22 +0200
Subject: [PATCH] [clang][CodeGen] Simplify code based on opaque pointers
- Update C
bjope wrote:
I reverted this patch since buildbots have been complaining for almost an hour.
Here is the first failure mail I got:
```
The Buildbot has detected a failed build on builder clang-armv8-quick while
building clang.
Full details are available at:
https://lab.llvm.org/buildbot/#/
bjope wrote:
> > Ok, seems like the only problem is the MemProf unit test
> > compiler-rt/lib/memprof/tests/
> > So if I manually disable that I don't see any other failures with this
> > patch.
>
> I think any components that uses freshly built clang (stage1) could
> potentially run into thi
https://github.com/bjope resolved
https://github.com/llvm/llvm-project/pull/65624
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -51,14 +51,11 @@ struct CodeGenTypeCache {
llvm::IntegerType *PtrDiffTy;
};
- /// void* in address space 0
+ /// void*, void** in address space 0
union {
+llvm::PointerType *UnqualPtrTy;
bjope wrote:
Ok , thanks. Then I assume the name is fi
https://github.com/bjope updated
https://github.com/llvm/llvm-project/pull/65624:
From 6ccf70a6aa245b83667ef6547c869035dd06da6f Mon Sep 17 00:00:00 2001
From: Bjorn Pettersson
Date: Thu, 7 Sep 2023 13:08:22 +0200
Subject: [PATCH] [clang][CodeGen] Simplify code based on opaque pointers
- Update
@@ -51,14 +51,11 @@ struct CodeGenTypeCache {
llvm::IntegerType *PtrDiffTy;
};
- /// void* in address space 0
+ /// void*, void** in address space 0
union {
+llvm::PointerType *UnqualPtrTy;
bjope wrote:
Maybe `OpaquePtrTy` is a better name. But
https://github.com/bjope review_requested
https://github.com/llvm/llvm-project/pull/65624
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/bjope review_requested
https://github.com/llvm/llvm-project/pull/65624
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/bjope review_requested
https://github.com/llvm/llvm-project/pull/65624
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/bjope created
https://github.com/llvm/llvm-project/pull/65624:
- Update CodeGenTypeCache to use a single union for all pointers in
address space zero.
- Introduce a UnqualPtrTy in CodeGenTypeCache, and use that (for
example instead of llvm::PointerType::getUnqual) in some
90 matches
Mail list logo
