nathanchance wrote:
The latest version of this change causes test failures for me:
```
$ cmake \
-B build \
-G Ninja \
-S llvm \
--log-level=NOTICE \
-Wno-dev \
-DCMAKE_BUILD_TYPE=Release \
-DCMAKE_C_COMPILER=clang \
@@ -4022,8 +4169,36 @@ LValue CodeGenFunction::EmitArraySubscriptExpr(const
ArraySubscriptExpr *E,
ArrayLV = EmitArraySubscriptExpr(ASE, /*Accessed*/ true);
else
ArrayLV = EmitLValue(Array);
+
auto *Idx = EmitIdxAfterBase(/*Promote*/true);
+if
@@ -4022,8 +4169,36 @@ LValue CodeGenFunction::EmitArraySubscriptExpr(const
ArraySubscriptExpr *E,
ArrayLV = EmitArraySubscriptExpr(ASE, /*Accessed*/ true);
else
ArrayLV = EmitLValue(Array);
+
auto *Idx = EmitIdxAfterBase(/*Promote*/true);
+if
https://github.com/bwendling edited
https://github.com/llvm/llvm-project/pull/73730
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/bwendling edited
https://github.com/llvm/llvm-project/pull/73730
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/bwendling edited
https://github.com/llvm/llvm-project/pull/73730
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -4022,8 +4169,36 @@ LValue CodeGenFunction::EmitArraySubscriptExpr(const
ArraySubscriptExpr *E,
ArrayLV = EmitArraySubscriptExpr(ASE, /*Accessed*/ true);
else
ArrayLV = EmitLValue(Array);
+
auto *Idx = EmitIdxAfterBase(/*Promote*/true);
+if
@@ -4022,8 +4169,36 @@ LValue CodeGenFunction::EmitArraySubscriptExpr(const
ArraySubscriptExpr *E,
ArrayLV = EmitArraySubscriptExpr(ASE, /*Accessed*/ true);
else
ArrayLV = EmitLValue(Array);
+
auto *Idx = EmitIdxAfterBase(/*Promote*/true);
+if
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/73730
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -4022,8 +4169,36 @@ LValue CodeGenFunction::EmitArraySubscriptExpr(const
ArraySubscriptExpr *E,
ArrayLV = EmitArraySubscriptExpr(ASE, /*Accessed*/ true);
else
ArrayLV = EmitLValue(Array);
+
auto *Idx = EmitIdxAfterBase(/*Promote*/true);
+if
@@ -4022,8 +4169,36 @@ LValue CodeGenFunction::EmitArraySubscriptExpr(const
ArraySubscriptExpr *E,
ArrayLV = EmitArraySubscriptExpr(ASE, /*Accessed*/ true);
else
ArrayLV = EmitLValue(Array);
+
auto *Idx = EmitIdxAfterBase(/*Promote*/true);
+if
@@ -4022,8 +4169,36 @@ LValue CodeGenFunction::EmitArraySubscriptExpr(const
ArraySubscriptExpr *E,
ArrayLV = EmitArraySubscriptExpr(ASE, /*Accessed*/ true);
else
ArrayLV = EmitLValue(Array);
+
auto *Idx = EmitIdxAfterBase(/*Promote*/true);
+if
https://github.com/bwendling edited
https://github.com/llvm/llvm-project/pull/73730
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -4022,8 +4169,36 @@ LValue CodeGenFunction::EmitArraySubscriptExpr(const
ArraySubscriptExpr *E,
ArrayLV = EmitArraySubscriptExpr(ASE, /*Accessed*/ true);
else
ArrayLV = EmitLValue(Array);
+
auto *Idx = EmitIdxAfterBase(/*Promote*/true);
+if
@@ -4022,8 +4169,36 @@ LValue CodeGenFunction::EmitArraySubscriptExpr(const
ArraySubscriptExpr *E,
ArrayLV = EmitArraySubscriptExpr(ASE, /*Accessed*/ true);
else
ArrayLV = EmitLValue(Array);
+
auto *Idx = EmitIdxAfterBase(/*Promote*/true);
+if
@@ -4022,8 +4169,36 @@ LValue CodeGenFunction::EmitArraySubscriptExpr(const
ArraySubscriptExpr *E,
ArrayLV = EmitArraySubscriptExpr(ASE, /*Accessed*/ true);
else
ArrayLV = EmitLValue(Array);
+
auto *Idx = EmitIdxAfterBase(/*Promote*/true);
+if
@@ -994,31 +1010,55 @@ class MemberExprBaseVisitor
// }
Expr *Visit(Expr *E) {
-return StmtVisitor::Visit(E);
+return StmtVisitor::Visit(E);
}
- Expr *VisitCastExpr(CastExpr *E) {
-return IsExpectedRecordDecl(E) ? E : Visit(E->getSubExpr());
- }
-
@@ -4022,8 +4169,36 @@ LValue CodeGenFunction::EmitArraySubscriptExpr(const
ArraySubscriptExpr *E,
ArrayLV = EmitArraySubscriptExpr(ASE, /*Accessed*/ true);
else
ArrayLV = EmitLValue(Array);
+
auto *Idx = EmitIdxAfterBase(/*Promote*/true);
+if
@@ -994,31 +1010,55 @@ class MemberExprBaseVisitor
// }
Expr *Visit(Expr *E) {
-return StmtVisitor::Visit(E);
+return StmtVisitor::Visit(E);
}
- Expr *VisitCastExpr(CastExpr *E) {
-return IsExpectedRecordDecl(E) ? E : Visit(E->getSubExpr());
- }
-
@@ -994,31 +1010,55 @@ class MemberExprBaseVisitor
// }
Expr *Visit(Expr *E) {
-return StmtVisitor::Visit(E);
+return StmtVisitor::Visit(E);
}
- Expr *VisitCastExpr(CastExpr *E) {
-return IsExpectedRecordDecl(E) ? E : Visit(E->getSubExpr());
- }
-
@@ -4022,8 +4168,36 @@ LValue CodeGenFunction::EmitArraySubscriptExpr(const
ArraySubscriptExpr *E,
ArrayLV = EmitArraySubscriptExpr(ASE, /*Accessed*/ true);
else
ArrayLV = EmitLValue(Array);
+
auto *Idx = EmitIdxAfterBase(/*Promote*/true);
+if
@@ -3022,18 +3022,24 @@ class CodeGenFunction : public CodeGenTypeCache {
void EmitBoundsCheck(const Expr *E, const Expr *Base, llvm::Value *Index,
QualType IndexType, bool Accessed);
+ void EmitBoundsCheck(const Expr *E, llvm::Value *Bound,
@@ -994,31 +1010,55 @@ class MemberExprBaseVisitor
// }
Expr *Visit(Expr *E) {
-return StmtVisitor::Visit(E);
+return StmtVisitor::Visit(E);
}
- Expr *VisitCastExpr(CastExpr *E) {
-return IsExpectedRecordDecl(E) ? E : Visit(E->getSubExpr());
- }
-
@@ -3022,18 +3022,24 @@ class CodeGenFunction : public CodeGenTypeCache {
void EmitBoundsCheck(const Expr *E, const Expr *Base, llvm::Value *Index,
QualType IndexType, bool Accessed);
+ void EmitBoundsCheck(const Expr *E, llvm::Value *Bound,
https://github.com/nickdesaulniers commented:
This is looking good! We're close!
https://github.com/llvm/llvm-project/pull/73730
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -4022,8 +4168,36 @@ LValue CodeGenFunction::EmitArraySubscriptExpr(const
ArraySubscriptExpr *E,
ArrayLV = EmitArraySubscriptExpr(ASE, /*Accessed*/ true);
else
ArrayLV = EmitLValue(Array);
+
auto *Idx = EmitIdxAfterBase(/*Promote*/true);
+if
https://github.com/nickdesaulniers edited
https://github.com/llvm/llvm-project/pull/73730
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
bwendling wrote:
It's the __bdos cases that really benefit from the `ExprLValueMap`. The
`LocalDeclMap` will have any `allocas` or globals for local C decls. From that,
I'll be able to get enough information to generate the `count` lookup. The
`ExprLValueMap` improves this by allowing us to
bwendling wrote:
> I actually think bdos is more complicated: array bounds checking can handle
> arbitrary base expressions, so it doesn't need to examine the base expression
> at all. bdos can't do that, so more work is required to handle precisely the
> cases you want to handle.
Yup! The
efriedma-quic wrote:
I actually think bdos is more complicated: array bounds checking can handle
arbitrary base expressions, so it doesn't need to examine the base expression
at all. bdos can't do that, so more work is required to handle precisely the
cases you want to handle.
bwendling wrote:
Okay. I should have fixed that issue.
https://github.com/llvm/llvm-project/pull/73730
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
bwendling wrote:
Could you add the .c and .sh files? I'll try to recreate it on my end though.
https://github.com/llvm/llvm-project/pull/73730
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
nathanchance wrote:
For what it's worth, I see a new crash on the latest version of this PR, in
case it is not known.
```
$ make -skj"$(nproc)" ARCH=arm64 LLVM=1 mrproper allmodconfig
net/ipv4/udp_tunnel_nic.o
clang: /home/nathan/cbl/src/llvm-project/llvm/lib/IR/Instructions.cpp:3342:
static
bwendling wrote:
The `__bdos` stuff is only a subset of the bounds checking code so we should
focus on that.
It's still messier than that, since it's not always going to be a pointer
directly to the FAM (e.g. p->a.b.c.array[index]), but I'll give it a shot. I
don't think it's going to be any
efriedma-quic wrote:
Trying to discuss both __bdos and the array bounds sanitizer changes in the
same review is making things confusing to discuss. It seems like they have
significant differences.
For array bounds sanitizer, take your example:
```
struct s {
struct s *p;
int count;
bwendling wrote:
> I mean, the base case should be "return nullptr", and you should only
> explicitly list out expressions you know we need to handle. We shouldn't need
> to explicitly mention VisitUnaryPostDec etc.
The expression can be arbitrarily complex. For instance this:
```
struct s {
efriedma-quic wrote:
> > And ideally, the recursive visit should list those expressions explicitly,
> > instead aborting on ones we know are bad.
>
> I'm sorry, I don't understand what you're talking about here. The whole point
> of the recursive visit is to find a suitable base pointer. If
bwendling wrote:
> And ideally, the recursive visit should list those expressions explicitly,
> instead aborting on ones we know are bad.
I'm sorry, I don't understand what you're talking about here. The whole point
of the recursive visit is to find a suitable base pointer. If we run across
efriedma-quic wrote:
If you do need a map for something, I'd prefer to make it as narrow as
possible. For example, I can imagine you could need to specifically look up
the corresponding allocation for a CompoundLiteralExpr; that might make sense.
I don't think we should need to look up
bwendling wrote:
The problem with adding the code to `CodeGenFunction::EmitArraySubscriptExpr`
is that we need to emit the counted_by "count" for more than just an
`ArraySubscriptExpr`. Where `ExprLValueMap` is placed catches all of the
expressions we're interested in. We're doing something
efriedma-quic wrote:
I don't like the "ExprLValueMap" approach for array bounds checking; it's
fragile and doesn't handle cases we should be able to handle. In particular,
we should be able to handle arbitrary base expressions for array bounds
checking, I think; there should be a constant
@@ -1411,6 +1411,8 @@ class CodeGenFunction : public CodeGenTypeCache {
/// decls.
DeclMapTy LocalDeclMap;
+ llvm::SmallDenseMap ExprLValueMap;
bwendling wrote:
I do this only when the sanitizer is enabled to keep us from building it
unnecessarily.
@@ -1411,6 +1411,8 @@ class CodeGenFunction : public CodeGenTypeCache {
/// decls.
DeclMapTy LocalDeclMap;
+ llvm::SmallDenseMap ExprLValueMap;
bwendling wrote:
It will. I did a test to see how many Exprs are typically stored. For both
Linux and Clang,
@@ -1411,6 +1411,8 @@ class CodeGenFunction : public CodeGenTypeCache {
/// decls.
DeclMapTy LocalDeclMap;
+ llvm::SmallDenseMap ExprLValueMap;
nickdesaulniers wrote:
Wont this store all kinds of unrelated Exprs? Is there any way we can minimize
the
@@ -1411,6 +1411,8 @@ class CodeGenFunction : public CodeGenTypeCache {
/// decls.
DeclMapTy LocalDeclMap;
+ llvm::SmallDenseMap ExprLValueMap;
bwendling wrote:
Done.
https://github.com/llvm/llvm-project/pull/73730
@@ -994,31 +1010,55 @@ class MemberExprBaseVisitor
// }
Expr *Visit(Expr *E) {
-return StmtVisitor::Visit(E);
+return StmtVisitor::Visit(E);
}
- Expr *VisitCastExpr(CastExpr *E) {
-return IsExpectedRecordDecl(E) ? E : Visit(E->getSubExpr());
- }
-
@@ -1411,6 +1411,8 @@ class CodeGenFunction : public CodeGenTypeCache {
/// decls.
DeclMapTy LocalDeclMap;
+ llvm::SmallDenseMap ExprLValueMap;
nickdesaulniers wrote:
Perhaps a comment as to what this map is used for?
https://github.com/nickdesaulniers edited
https://github.com/llvm/llvm-project/pull/73730
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -994,31 +1010,55 @@ class MemberExprBaseVisitor
// }
Expr *Visit(Expr *E) {
-return StmtVisitor::Visit(E);
+return StmtVisitor::Visit(E);
}
- Expr *VisitCastExpr(CastExpr *E) {
-return IsExpectedRecordDecl(E) ? E : Visit(E->getSubExpr());
- }
-
https://github.com/nickdesaulniers commented:
linter is complaining about formatting
https://github.com/llvm/llvm-project/pull/73730
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
bwendling wrote:
Okay, this was tougher than I thought. I make sure that we're not causing any
new side-effects in the code. I try as much as possible to use previously
generated code when accessing the `counted_by` variable. I also corrected how
offsets were calculated.
There are some a few
kees wrote:
> ```
> int foo(struct s *p, int index) {
> return __builtin_dynamic_object_size((++p)->array[index], 1);
> }
> ```
>
> This _shouldn't_ increment `p`, but we need to get the array size of the
> element _after_ `p`. I suspect that this is probably a horrible security
> violation
bwendling wrote:
This is a PITA. There are two situations:
1. The expression was processed before getting to the `EmitBoundsCheck` call,
and is thus recorded in the `LocalDeclMap` for easy access. Grand!
2. Using a FAM in a `__builtin_dynamic_object_size` cannot have side effects.
Also, it
@@ -956,42 +958,112 @@ static llvm::Value
*getArrayIndexingBound(CodeGenFunction ,
return nullptr;
}
-const Expr *
-CodeGenFunction::BuildCountedByFieldExpr(const Expr *Base,
- const ValueDecl *CountedByVD) {
+namespace {
+
+/// \p
@@ -956,42 +958,112 @@ static llvm::Value
*getArrayIndexingBound(CodeGenFunction ,
return nullptr;
}
-const Expr *
-CodeGenFunction::BuildCountedByFieldExpr(const Expr *Base,
- const ValueDecl *CountedByVD) {
+namespace {
+
+/// \p
@@ -956,42 +958,112 @@ static llvm::Value
*getArrayIndexingBound(CodeGenFunction ,
return nullptr;
}
-const Expr *
-CodeGenFunction::BuildCountedByFieldExpr(const Expr *Base,
- const ValueDecl *CountedByVD) {
+namespace {
+
+/// \p
@@ -956,42 +958,112 @@ static llvm::Value
*getArrayIndexingBound(CodeGenFunction ,
return nullptr;
}
-const Expr *
-CodeGenFunction::BuildCountedByFieldExpr(const Expr *Base,
- const ValueDecl *CountedByVD) {
+namespace {
+
+/// \p
bwendling wrote:
Okay. With the latest commit, I handle some of the weird accesses. As it turns
out, looking at `isArrow()` for a `MemberExpr` isn't going to work, because
it'll happen with ordinary accesses:
```
ImplicitCastExpr 0x564fa8c3fd48 'int *'
`-MemberExpr 0x564fa8c3fcf8 'int[]'
bwendling wrote:
> I agree users probably shouldn't be doing that... but given it compiles your
> code should handle it gracefully. (It should just be a matter of making sure
> you don't recurse too deeply through the "base".)
*nods* However, the code it generates might not be what they
efriedma-quic wrote:
I agree users probably shouldn't be doing that... but given it compiles your
code should handle it gracefully. (It should just be a matter of making sure
you don't recurse too deeply through the "base".)
https://github.com/llvm/llvm-project/pull/73730
efriedma-quic wrote:
Some examples to consider:
```
// Crazy array indexing... but strictly speaking, legal.
struct S { int count; int arr[] __attribute((counted_by(count))); };
int f1(int c, struct S *var) {
return var[10].arr[10];
}
// Double dereferenced variable.
int f2(int c, struct S
bwendling wrote:
> I'd like to see a few tests involving multiple arrows in the same expression.
> (If my understanding is correct, you want to cut the recursion when you see
> an arrow member.)
Correct. I'll add the code and some testcases.
> Looking at the code again, I guess
efriedma-quic wrote:
I'd like to see a few tests involving multiple arrows in the same expression.
(If my understanding is correct, you want to cut the recursion when you see an
arrow member.)
Looking at the code again, I guess FindCountedByField doesn't explicitly
compute the base
bwendling wrote:
> CodeGenFunction::FindCountedByField finds a field with a corresponding base
> expression. Currently, it throws away the base expression. And the code
> you've just written tries to recompute the base. Instead of doing this dance,
> can we just make
efriedma-quic wrote:
CodeGenFunction::FindCountedByField finds a field with a corresponding base
expression. Currently, it throws away the base expression. And the code
you've just written tries to recompute the base. Instead of doing this dance,
can we just make
bwendling wrote:
This should be ready for a final review now.
https://github.com/llvm/llvm-project/pull/73730
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -956,42 +956,70 @@ static llvm::Value *getArrayIndexingBound(CodeGenFunction
,
return nullptr;
}
-const Expr *
+namespace {
+
+struct MemberExprBaseVisitor
+: public StmtVisitor {
+ MemberExprBaseVisitor() = default;
+
+
@@ -956,42 +956,72 @@ static llvm::Value *getArrayIndexingBound(CodeGenFunction
,
return nullptr;
}
-const Expr *
+namespace {
+
+struct MemberExprBaseVisitor
+: public StmtVisitor {
+ MemberExprBaseVisitor() = default;
+
+
https://github.com/bwendling updated
https://github.com/llvm/llvm-project/pull/73730
>From 3e500c2a7c6b7895ebe292a1ed50e04409ba149c Mon Sep 17 00:00:00 2001
From: Bill Wendling
Date: Tue, 28 Nov 2023 17:17:54 -0800
Subject: [PATCH 1/7] [Clang] Generate the GEP instead of adding AST nodes
---
@@ -956,42 +956,72 @@ static llvm::Value *getArrayIndexingBound(CodeGenFunction
,
return nullptr;
}
-const Expr *
+namespace {
+
+struct MemberExprBaseVisitor
+: public StmtVisitor {
+ MemberExprBaseVisitor() = default;
+
+
@@ -956,42 +956,72 @@ static llvm::Value *getArrayIndexingBound(CodeGenFunction
,
return nullptr;
}
-const Expr *
+namespace {
+
+struct MemberExprBaseVisitor
+: public StmtVisitor {
+ MemberExprBaseVisitor() = default;
+
+
bwendling wrote:
> > @AaronBallman It's not letting me comment on your comment. While a compound
> > literal doesn't have a DRE, it's also not a flexible array, so it's not
> > supposed to get this far. Note that this method should only be executed if
> > the flexible array member exists and
@@ -956,42 +956,72 @@ static llvm::Value *getArrayIndexingBound(CodeGenFunction
,
return nullptr;
}
-const Expr *
+namespace {
+
+struct MemberExprBaseVisitor
+: public StmtVisitor {
+ MemberExprBaseVisitor() = default;
+
+
https://github.com/bwendling updated
https://github.com/llvm/llvm-project/pull/73730
>From 3e500c2a7c6b7895ebe292a1ed50e04409ba149c Mon Sep 17 00:00:00 2001
From: Bill Wendling
Date: Tue, 28 Nov 2023 17:17:54 -0800
Subject: [PATCH 1/6] [Clang] Generate the GEP instead of adding AST nodes
---
AaronBallman wrote:
> @AaronBallman It's not letting me comment on your comment. While a compound
> literal doesn't have a DRE, it's also not a flexible array, so it's not
> supposed to get this far. Note that this method should only be executed if
> the flexible array member exists and has
@@ -956,42 +956,72 @@ static llvm::Value *getArrayIndexingBound(CodeGenFunction
,
return nullptr;
}
-const Expr *
+namespace {
+
+struct MemberExprBaseVisitor
+: public StmtVisitor {
+ MemberExprBaseVisitor() = default;
+
+
https://github.com/bwendling updated
https://github.com/llvm/llvm-project/pull/73730
>From 3e500c2a7c6b7895ebe292a1ed50e04409ba149c Mon Sep 17 00:00:00 2001
From: Bill Wendling
Date: Tue, 28 Nov 2023 17:17:54 -0800
Subject: [PATCH 1/5] [Clang] Generate the GEP instead of adding AST nodes
---
bwendling wrote:
@AaronBallman It's not letting me comment on your comment. While a compound
literal doesn't have a DRE, it's also not a flexible array, so it's not
supposed to get this far.
https://github.com/llvm/llvm-project/pull/73730
___
@@ -956,42 +956,72 @@ static llvm::Value *getArrayIndexingBound(CodeGenFunction
,
return nullptr;
}
-const Expr *
+namespace {
+
+struct MemberExprBaseVisitor
+: public StmtVisitor {
+ MemberExprBaseVisitor() = default;
+
+
@@ -956,42 +956,70 @@ static llvm::Value *getArrayIndexingBound(CodeGenFunction
,
return nullptr;
}
-const Expr *
+namespace {
+
+struct MemberExprBaseVisitor
+: public StmtVisitor {
+ MemberExprBaseVisitor() = default;
+
+
https://github.com/AaronBallman commented:
I added the codegen code owners for opinions, but personally, I prefer the
direction this patch is heading over the one in
https://github.com/llvm/llvm-project/pull/73465
https://github.com/llvm/llvm-project/pull/73730
@@ -956,42 +956,72 @@ static llvm::Value *getArrayIndexingBound(CodeGenFunction
,
return nullptr;
}
-const Expr *
+namespace {
+
+struct MemberExprBaseVisitor
+: public StmtVisitor {
+ MemberExprBaseVisitor() = default;
+
+
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/73730
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/bwendling updated
https://github.com/llvm/llvm-project/pull/73730
>From 3e500c2a7c6b7895ebe292a1ed50e04409ba149c Mon Sep 17 00:00:00 2001
From: Bill Wendling
Date: Tue, 28 Nov 2023 17:17:54 -0800
Subject: [PATCH 1/4] [Clang] Generate the GEP instead of adding AST nodes
---
https://github.com/bwendling updated
https://github.com/llvm/llvm-project/pull/73730
>From 3e500c2a7c6b7895ebe292a1ed50e04409ba149c Mon Sep 17 00:00:00 2001
From: Bill Wendling
Date: Tue, 28 Nov 2023 17:17:54 -0800
Subject: [PATCH 1/3] [Clang] Generate the GEP instead of adding AST nodes
---
bwendling wrote:
> Hey, that looks pretty good! I'm surprised it wasn't too much more work to
> convert to generating the GEP directly. Nice job!
>
> Does this change result in codegen differences in IR? (was expecting test
> changes that used "fork" loads and "bork" GEPs)
Thanks. There will
@@ -956,42 +956,70 @@ static llvm::Value *getArrayIndexingBound(CodeGenFunction
,
return nullptr;
}
-const Expr *
+namespace {
+
+struct MemberExprBaseVisitor
+: public StmtVisitor {
+ MemberExprBaseVisitor() = default;
+
+
@@ -956,42 +956,70 @@ static llvm::Value *getArrayIndexingBound(CodeGenFunction
,
return nullptr;
}
-const Expr *
+namespace {
+
+struct MemberExprBaseVisitor
+: public StmtVisitor {
+ MemberExprBaseVisitor() = default;
+
+
@@ -956,42 +956,70 @@ static llvm::Value *getArrayIndexingBound(CodeGenFunction
,
return nullptr;
}
-const Expr *
+namespace {
+
+struct MemberExprBaseVisitor
+: public StmtVisitor {
+ MemberExprBaseVisitor() = default;
+
+
@@ -956,42 +956,70 @@ static llvm::Value *getArrayIndexingBound(CodeGenFunction
,
return nullptr;
}
-const Expr *
+namespace {
+
+struct MemberExprBaseVisitor
+: public StmtVisitor {
+ MemberExprBaseVisitor() = default;
+
+
@@ -956,42 +956,70 @@ static llvm::Value *getArrayIndexingBound(CodeGenFunction
,
return nullptr;
}
-const Expr *
+namespace {
+
+struct MemberExprBaseVisitor
+: public StmtVisitor {
+ MemberExprBaseVisitor() = default;
+
+
https://github.com/nickdesaulniers commented:
Hey, that looks pretty good! I'm surprised it wasn't too much more work to
convert to generating the GEP directly. Nice job!
Does this change result in codegen differences in IR? (was expecting test
changes that used "fork" loads and "bork" GEPs)
https://github.com/nickdesaulniers edited
https://github.com/llvm/llvm-project/pull/73730
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -956,42 +956,70 @@ static llvm::Value *getArrayIndexingBound(CodeGenFunction
,
return nullptr;
}
-const Expr *
+namespace {
+
+struct MemberExprBaseVisitor
+: public StmtVisitor {
+ MemberExprBaseVisitor() = default;
+
+
https://github.com/bwendling updated
https://github.com/llvm/llvm-project/pull/73730
>From 3e500c2a7c6b7895ebe292a1ed50e04409ba149c Mon Sep 17 00:00:00 2001
From: Bill Wendling
Date: Tue, 28 Nov 2023 17:17:54 -0800
Subject: [PATCH 1/2] [Clang] Generate the GEP instead of adding AST nodes
---
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 4eb421192479dbecae2621b868e55aaf6d945b02
3e500c2a7c6b7895ebe292a1ed50e04409ba149c --
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Bill Wendling (bwendling)
Changes
This is an alternative to https://github.com/llvm/llvm-project/pull/73465. It
generates the GEP directly. It's not tested well, but it might be a nicer
solution rather than adding AST nodes.
PTAL
---
https://github.com/bwendling created
https://github.com/llvm/llvm-project/pull/73730
This is an alternative to https://github.com/llvm/llvm-project/pull/73465. It
generates the GEP directly. It's not tested well, but it might be a nicer
solution rather than adding AST nodes.
PTAL
>From
98 matches
Mail list logo
