Author: efriedma
Date: Wed Sep 27 16:29:37 2017
New Revision: 314364
URL: http://llvm.org/viewvc/llvm-project?rev=314364&view=rev
Log:
[Preprocessor] Preserve #pragma clang assume_nonnull in preprocessed output
Patch by Zbigniew Sarbinowski!
Differential Revision: https://reviews.llvm.org/D37861
Author: efriedma
Date: Fri Aug 24 12:31:52 2018
New Revision: 340640
URL: http://llvm.org/viewvc/llvm-project?rev=340640&view=rev
Log:
[LTO] Fix -save-temps with LTO and unnamed globals.
If all LLVM passes are disabled, we can't emit a summary because there
could be unnamed globals in the IR.
Di
Author: efriedma
Date: Fri Aug 24 13:18:34 2018
New Revision: 340644
URL: http://llvm.org/viewvc/llvm-project?rev=340644&view=rev
Log:
Add REQUIRES: x86-registered-target to test.
(This isn't really x86-specific, but we have to pick some non-Apple
triple to exercise the right codepath.)
Modifie
Author: efriedma
Date: Fri Aug 3 15:09:44 2018
New Revision: 338931
URL: http://llvm.org/viewvc/llvm-project?rev=338931&view=rev
Log:
Diagnose invalid cv-qualifiers for friend decls.
Differential Revision: https://reviews.llvm.org/D45712
Modified:
cfe/trunk/lib/Sema/SemaDeclCXX.cpp
cfe
Author: efriedma
Date: Mon Dec 18 17:54:09 2017
New Revision: 321052
URL: http://llvm.org/viewvc/llvm-project?rev=321052&view=rev
Log:
[Coverage] Fix use-after free in coverage emission
Fixes regression from r320533.
This fixes the undefined behavior, but I'm not sure it's really right...
I thin
Author: efriedma
Date: Wed Oct 17 14:07:11 2018
New Revision: 344710
URL: http://llvm.org/viewvc/llvm-project?rev=344710&view=rev
Log:
[AArch64] Define __ELF__ for aarch64-none-elf and other similar triples.
"aarch64-none-elf" is commonly used for AArch64 baremetal toolchains.
Differential Revis
Author: efriedma
Date: Thu Oct 25 18:31:57 2018
New Revision: 345354
URL: http://llvm.org/viewvc/llvm-project?rev=345354&view=rev
Log:
[AArch64] Support Windows stack probe command-line arguments.
Adds support for -mno-stack-arg-probe and -mstack-probe-size.
(Not really happy copy-pasting code,
Author: efriedma
Date: Tue Jan 15 16:50:44 2019
New Revision: 351284
URL: http://llvm.org/viewvc/llvm-project?rev=351284&view=rev
Log:
[EH] Rename llvm.x86.seh.recoverfp intrinsic to llvm.eh.recoverfp
This is the clang counterpart to D56747.
Patch by Mandeep Singh Grang.
Differential Revision:
Author: efriedma
Date: Mon Jan 21 16:11:17 2019
New Revision: 351766
URL: http://llvm.org/viewvc/llvm-project?rev=351766&view=rev
Log:
[CodeGen] Always use string computed in Sema for PredefinedExpr
We can't use any other string, anyway, because its type wouldn't
match the type of the PredefinedE
Author: efriedma
Date: Wed Oct 31 14:31:09 2018
New Revision: 345779
URL: http://llvm.org/viewvc/llvm-project?rev=345779&view=rev
Log:
[ARM64] [Windows] Implement _InterlockedExchangeAdd*_* builtins.
These apparently need to be proper builtins to handle the Windows
SDK.
Differential Revision: ht
Author: efriedma
Date: Wed Oct 31 14:39:41 2018
New Revision: 345781
URL: http://llvm.org/viewvc/llvm-project?rev=345781&view=rev
Log:
[AArch64] [Windows] Emit unwind tables by default.
Unwind tables are necessary even in code that doesn't support
exceptions. The tables are used for setjmp(), an
Author: efriedma
Date: Thu Mar 14 12:46:51 2019
New Revision: 356196
URL: http://llvm.org/viewvc/llvm-project?rev=356196&view=rev
Log:
[CodeGen] Consider tied operands when adjusting inline asm operands.
The constraint "0" in the following asm did not consider the its
relationship with "=y" when
(Comments inline.)
> -Original Message-
> From: cfe-commits On Behalf Of
> Doerfert, Johannes Rudolf via cfe-commits
> Sent: Tuesday, January 22, 2019 9:29 AM
> To: Chandler Carruth
> Cc: cfe-commits cfe
> Subject: Re: r351629 - Emit !callback metadata and introduce the callback
> attri
What sort of outputs, specifically? Memory outputs are easy; I think the LLVM
IR patch actually supports them already. Register outputs are complicated... I
guess they're also possible, but we would need to come up with some frontend
rule that allows sane code generation. Consider the case wh
Author: efriedma
Date: Thu Feb 7 17:17:49 2019
New Revision: 353493
URL: http://llvm.org/viewvc/llvm-project?rev=353493&view=rev
Log:
[COFF, ARM64] Fix types for _ReadStatusReg, _WriteStatusReg
r344765 added those intrinsics, but used the wrong types.
Patch by Mike Hommey
Differential Revision
Author: efriedma
Date: Fri Feb 8 13:18:46 2019
New Revision: 353569
URL: http://llvm.org/viewvc/llvm-project?rev=353569&view=rev
Log:
[Sema] Make string literal init an rvalue.
This allows substantially simplifying the expression evaluation code,
because we don't have to special-case lvalues whi
Author: efriedma
Date: Fri Feb 8 13:36:04 2019
New Revision: 353571
URL: http://llvm.org/viewvc/llvm-project?rev=353571&view=rev
Log:
[CodeGen][NFC] Update comments in CGExprConstant.cpp.
Modified:
cfe/trunk/lib/CodeGen/CGExprConstant.cpp
Modified: cfe/trunk/lib/CodeGen/CGExprConstant.cpp
t;, line 147, in main
> subprocess.check_output(args, stderr=subprocess.STDOUT).decode()
> File "/usr/lib/python2.7/subprocess.py", line 223, in check_output
> raise CalledProcessError(retcode, cmd, output=output)
> subprocess.CalledProcessError: Command '['
Author: efriedma
Date: Fri Feb 8 18:22:17 2019
New Revision: 353598
URL: http://llvm.org/viewvc/llvm-project?rev=353598&view=rev
Log:
Fix buildbot failure from r353569.
I assumed lvalue-to-rvalue conversions of array type would never
happen, but apparently clang-tidy tries in some cases.
Modif
Fixed in r353598.
-Eli
> -Original Message-
> From: cfe-commits On Behalf Of Eli
> Friedman via cfe-commits
> Sent: Friday, February 8, 2019 6:06 PM
> To: douglas.y...@sony.com
> Cc: cfe-commits@lists.llvm.org
> Subject: [EXT] RE: r353569 - [Sema] Make string l
Author: efriedma
Date: Mon Feb 11 14:54:27 2019
New Revision: 353762
URL: http://llvm.org/viewvc/llvm-project?rev=353762&view=rev
Log:
[Sema] Mark GNU compound literal array init as an rvalue.
Basically the same issue as string init, except it didn't really have
any visible consequences before I
Usually the cfe-dev mailing list is better for questions like this.
The type “int” is ASTContext::IntTy. You can use QualType::withConst to add a
“const” qualifier, and ASTContext::getPointerType to construct a pointer type.
Putting that together, you can construct a “const int*” with somethin
Author: efriedma
Date: Tue Sep 17 14:43:19 2019
New Revision: 372187
URL: http://llvm.org/viewvc/llvm-project?rev=372187&view=rev
Log:
[ARM] Update clang for removal of vfp2d16 and vfp2d16sp
Matching fix for https://reviews.llvm.org/D67375 (r372186).
Differential Revision: https://reviews.llvm.o
-Original Message-
From: cfe-commits On Behalf Of Evgeny
Mankov via cfe-commits
Sent: Tuesday, August 27, 2019 3:16 PM
To: cfe-commits@lists.llvm.org
Subject: [EXT] r370123 - [preprocessor] Add an opportunity to retain excluded
conditional blocks
Added: cfe/trunk/test/Index/retain-exclu
Author: efriedma
Date: Thu Apr 12 15:21:36 2018
New Revision: 329965
URL: http://llvm.org/viewvc/llvm-project?rev=329965&view=rev
Log:
Remove -cc1 option "-backend-option".
It means the same thing as -mllvm; there isn't any reason to have two
options which do the same thing.
Differential Revisio
Author: efriedma
Date: Thu Apr 12 15:50:50 2018
New Revision: 329968
URL: http://llvm.org/viewvc/llvm-project?rev=329968&view=rev
Log:
Fix test failure caused by r329965.
"-mllvm" options get parsed slightly earlier, and -arm-restrict-it is
only available if the ARM target is compiled in. Invoke
Author: efriedma
Date: Mon Apr 16 15:00:14 2018
New Revision: 330162
URL: http://llvm.org/viewvc/llvm-project?rev=330162&view=rev
Log:
[libc++abi] Replace __sync_* functions with __libcpp_atomic_* functions.
This is basically part 2 of r313694.
It's a little unfortunate that I had to copy-paste
Author: efriedma
Date: Mon Apr 16 16:52:58 2018
New Revision: 330169
URL: http://llvm.org/viewvc/llvm-project?rev=330169&view=rev
Log:
[ARM] Compute a target feature which corresponds to the ARM version.
Currently, the interaction between the triple, the CPU, and the
supported features is a mess:
Author: efriedma
Date: Wed Apr 25 12:14:05 2018
New Revision: 330861
URL: http://llvm.org/viewvc/llvm-project?rev=330861&view=rev
Log:
[TargetInfo] Sort target features before passing them to the backend
Passing the features in random order will lead to unpredictable results
when some of the feat
Author: efriedma
Date: Fri May 4 17:09:51 2018
New Revision: 331570
URL: http://llvm.org/viewvc/llvm-project?rev=331570&view=rev
Log:
Add warning flag -Wordered-compare-function-pointers.
The C standard doesn't allow comparisons like "f1 < f2" (where f1 and f2
are function pointers), but we allo
Author: efriedma
Date: Thu Oct 10 11:45:34 2019
New Revision: 374419
URL: http://llvm.org/viewvc/llvm-project?rev=374419&view=rev
Log:
[ARM] Fix arm_neon.h with -flax-vector-conversions=none, part 2.
Just running -fsyntax-only over arm_neon.h doesn't cover some intrinsics
which are defined using
Author: efriedma
Date: Mon Oct 14 15:44:42 2019
New Revision: 374836
URL: http://llvm.org/viewvc/llvm-project?rev=374836&view=rev
Log:
[test] Fix test failure
The version mismatch symbol is version 9 on 32 bit android. Since
this test isn't actually testing any android specific functionality,
we
Author: efriedma
Date: Thu Oct 17 14:57:28 2019
New Revision: 375179
URL: http://llvm.org/viewvc/llvm-project?rev=375179&view=rev
Log:
[ARM] Fix arm_neon.h with -flax-vector-conversions=none, part 3
It's completely impossible to check that I've actually found all the
issues, due to the use of mac
Author: Eli Friedman
Date: 2020-05-23T15:46:28-07:00
New Revision: 9292ece9956c98acf0cfa6e188316243ffbf4bed
URL:
https://github.com/llvm/llvm-project/commit/9292ece9956c98acf0cfa6e188316243ffbf4bed
DIFF:
https://github.com/llvm/llvm-project/commit/9292ece9956c98acf0cfa6e188316243ffbf4bed.diff
Author: Eli Friedman
Date: 2020-04-03T18:00:33-07:00
New Revision: 83fa811e5bf5b291eafd900f3072b961f64f039c
URL:
https://github.com/llvm/llvm-project/commit/83fa811e5bf5b291eafd900f3072b961f64f039c
DIFF:
https://github.com/llvm/llvm-project/commit/83fa811e5bf5b291eafd900f3072b961f64f039c.diff
Author: Eli Friedman
Date: 2020-04-03T18:00:33-07:00
New Revision: b11decc221a65d2c7290b93a4662a607a63b6d86
URL:
https://github.com/llvm/llvm-project/commit/b11decc221a65d2c7290b93a4662a607a63b6d86
DIFF:
https://github.com/llvm/llvm-project/commit/b11decc221a65d2c7290b93a4662a607a63b6d86.diff
Author: Eli Friedman
Date: 2020-04-06T17:03:49-07:00
New Revision: 68b03aee1a15678ab5b518148d5e75c9dc0436fd
URL:
https://github.com/llvm/llvm-project/commit/68b03aee1a15678ab5b518148d5e75c9dc0436fd
DIFF:
https://github.com/llvm/llvm-project/commit/68b03aee1a15678ab5b518148d5e75c9dc0436fd.diff
Author: Eli Friedman
Date: 2020-04-13T13:43:14-07:00
New Revision: 89e0662dee5fa541f284e6be0af9e36e7f39f947
URL:
https://github.com/llvm/llvm-project/commit/89e0662dee5fa541f284e6be0af9e36e7f39f947
DIFF:
https://github.com/llvm/llvm-project/commit/89e0662dee5fa541f284e6be0af9e36e7f39f947.diff
Author: Benson Chu
Date: 2020-06-19T17:01:03-07:00
New Revision: c310bf8256f83f365921562cebc5e4c9aec8e87e
URL:
https://github.com/llvm/llvm-project/commit/c310bf8256f83f365921562cebc5e4c9aec8e87e
DIFF:
https://github.com/llvm/llvm-project/commit/c310bf8256f83f365921562cebc5e4c9aec8e87e.diff
LO
Author: Eli Friedman
Date: 2020-06-23T17:16:17-07:00
New Revision: bf8b63ed296c1ecad03c83b798ffbfa039cbceb4
URL:
https://github.com/llvm/llvm-project/commit/bf8b63ed296c1ecad03c83b798ffbfa039cbceb4
DIFF:
https://github.com/llvm/llvm-project/commit/bf8b63ed296c1ecad03c83b798ffbfa039cbceb4.diff
Author: Eli Friedman
Date: 2020-07-30T15:41:54-07:00
New Revision: 8dfb5d767e70dd862096c8872fd3e3bead99741d
URL:
https://github.com/llvm/llvm-project/commit/8dfb5d767e70dd862096c8872fd3e3bead99741d
DIFF:
https://github.com/llvm/llvm-project/commit/8dfb5d767e70dd862096c8872fd3e3bead99741d.diff
Committed dca23ed; should be fixed now.
-Eli
From: Azhar Mohammed
Sent: Monday, August 3, 2020 11:01 AM
To: Eli Friedman ; Eli
Friedman via Phabricator ; Eli Friedman
Cc: sander.desma...@arm.com; sjoerd.mei...@arm.com; t.p.northo...@gmail.com;
cameron.mcina...@nyu.edu; blitzrak...@gmail.com;
Author: Eli Friedman
Date: 2020-08-18T12:51:16-07:00
New Revision: 673dbe1b5eef09db39783c828a84f1213a47bad0
URL:
https://github.com/llvm/llvm-project/commit/673dbe1b5eef09db39783c828a84f1213a47bad0
DIFF:
https://github.com/llvm/llvm-project/commit/673dbe1b5eef09db39783c828a84f1213a47bad0.diff
Author: Eli Friedman
Date: 2020-05-14T14:10:51-07:00
New Revision: 428d0b6f77986efd944df01bb4ae7888c6262c2f
URL:
https://github.com/llvm/llvm-project/commit/428d0b6f77986efd944df01bb4ae7888c6262c2f
DIFF:
https://github.com/llvm/llvm-project/commit/428d0b6f77986efd944df01bb4ae7888c6262c2f.diff
Author: efriedma
Date: Tue Dec 12 16:14:17 2017
New Revision: 320533
URL: http://llvm.org/viewvc/llvm-project?rev=320533&view=rev
Log:
[Coverage] Always emit unused coverage mappings in the same order.
Non-determinism is confusing at best.
Differential Revision: https://reviews.llvm.org/D41140
@@ -1741,6 +1742,69 @@ void AArch64DAGToDAGISel::SelectCVTIntrinsic(SDNode *N,
unsigned NumVecs,
CurDAG->RemoveDeadNode(N);
}
+void AArch64DAGToDAGISel::SelectSMELdrStrZA(SDNode *N, bool IsLoad) {
+ // Lower an SME LDR/STR ZA intrinsic to LDR_ZA_PSEUDO or STR_ZA.
+ // If
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/70171
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/71706
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/efriedma-quic commented:
Added reviewers from https://reviews.llvm.org/D127812, for the AArch64 side.
https://github.com/llvm/llvm-project/pull/71706
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-
@@ -4098,8 +4098,26 @@ void CodeGenModule::emitMultiVersionFunctions() {
}
llvm::Constant *ResolverConstant = GetOrCreateMultiVersionResolver(GD);
-if (auto *IFunc = dyn_cast(ResolverConstant))
+if (auto *IFunc = dyn_cast(ResolverConstant)) {
ResolverCon
efriedma-quic wrote:
The C equivalent to the C++11 rule is in 6.8.5, which says "An iteration
statement may be assumed by the implementation to terminate if [...]". There's
no general rule that a program has to make progress if there isn't a loop
involved.
https://github.com/llvm/llvm-projec
@@ -1482,6 +1477,11 @@ void CodeGenFunction::GenerateCode(GlobalDecl GD,
llvm::Function *Fn,
} else
llvm_unreachable("no definition for emitted function");
+ // This is checked after emitting the function body so we know if there
+ // are any permitted infinite loops.
@@ -1482,6 +1477,11 @@ void CodeGenFunction::GenerateCode(GlobalDecl GD,
llvm::Function *Fn,
} else
llvm_unreachable("no definition for emitted function");
+ // This is checked after emitting the function body so we know if there
+ // are any permitted infinite loops.
@@ -1482,6 +1477,11 @@ void CodeGenFunction::GenerateCode(GlobalDecl GD,
llvm::Function *Fn,
} else
llvm_unreachable("no definition for emitted function");
+ // This is checked after emitting the function body so we know if there
+ // are any permitted infinite loops.
@@ -359,6 +359,13 @@ class LLVM_LIBRARY_VISIBILITY PPCTargetInfo : public
TargetInfo {
bool isSPRegName(StringRef RegName) const override {
return RegName.equals("r1") || RegName.equals("x1");
}
+
+ // We support __builtin_cpu_supports/__builtin_cpu_is on targets that
efriedma-quic wrote:
Why are we creating a comdat here in the first place? Creating a comdat
associated with an internal symbol doesn't do anything useful: an internal
symbol can't be defined in any other translation unit, so the comdat will never
be discarded.
If we allow creating a comdat
efriedma-quic wrote:
> Why are we creating a comdat here in the first place?
I guess that's b2615aa4... but I'm pretty sure we fixed -fdata-sections so the
backend automatically generates comdats. So maybe we should just revert that.
> If we allow creating a comdat associated with an interna
efriedma-quic wrote:
> That seems reasonable, however, there are other QOI reasons for attempting to
> generate globally unique names for lambdas
Sure. But we wouldn't want to special-case vftables for that.
> I think our strategy to ensure internal lambdas like this are globally unique
> is
@@ -1482,6 +1477,11 @@ void CodeGenFunction::GenerateCode(GlobalDecl GD,
llvm::Function *Fn,
} else
llvm_unreachable("no definition for emitted function");
+ // This is checked after emitting the function body so we know if there
+ // are any permitted infinite loops.
@@ -1244,29 +1244,28 @@ static void emitStoresForConstant(CodeGenModule &CGM,
const VarDecl &D,
// If the initializer is small, use a handful of stores.
if (shouldSplitConstantStore(CGM, ConstantSize)) {
if (auto *STy = dyn_cast(Ty)) {
- // FIXME: handle the case
@@ -1244,29 +1244,28 @@ static void emitStoresForConstant(CodeGenModule &CGM,
const VarDecl &D,
// If the initializer is small, use a handful of stores.
if (shouldSplitConstantStore(CGM, ConstantSize)) {
if (auto *STy = dyn_cast(Ty)) {
- // FIXME: handle the case
@@ -1244,29 +1244,28 @@ static void emitStoresForConstant(CodeGenModule &CGM,
const VarDecl &D,
// If the initializer is small, use a handful of stores.
if (shouldSplitConstantStore(CGM, ConstantSize)) {
if (auto *STy = dyn_cast(Ty)) {
- // FIXME: handle the case
@@ -1506,8 +1497,16 @@ TEST_CUSTOM(unmatchedreverse, unmatchedreverse, { .c =
42 });
// CHECK-O0:call void @llvm.memcpy
// CHECK-NOT: !annotation
// CHECK-O0:call void @{{.*}}used{{.*}}%custom)
-// PATTERN-O1: store i32 -1431655894, ptr {{.*}}, align 4
-// ZERO-O1:
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/71452
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -4098,8 +4098,26 @@ void CodeGenModule::emitMultiVersionFunctions() {
}
llvm::Constant *ResolverConstant = GetOrCreateMultiVersionResolver(GD);
-if (auto *IFunc = dyn_cast(ResolverConstant))
+if (auto *IFunc = dyn_cast(ResolverConstant)) {
ResolverCon
efriedma-quic wrote:
The C notion of "compatibility" with regard to enums is a bit weird... clang
and gcc disagree whether `enum e : int; enum e2: int; enum e x; int x; enum e2
x;` is valid because 6.2.7 doesn't actually define what's supposed to happen.
Probably this should be illegal, but t
efriedma-quic wrote:
I'm a little surprised we don't need any LLVM backend changes, but I guess in
soft-float mode we basically treat floats as ints anyway, so maybe things just
work. I'd like to see appropriate regression tests, though (if they don't
already exist).
https://github.com/llvm/
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 off
efriedma-quic wrote:
Making Sema pull the TBAA info out of clang/lib/CodeGen is a layering violation
(and probably breaks if we aren't actually generating code). If we need some
notion of "aliasing" in Sema, we should pull the relevant code into
clang/lib/AST.
I don't have any experience wit
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 arbit
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 we
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;
int
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.
https://github
@@ -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());
- }
- E
@@ -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 (SanOp
@@ -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 (SanOp
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/72343
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/efriedma-quic closed
https://github.com/llvm/llvm-project/pull/72343
___
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 (SanOp
https://github.com/efriedma-quic created
https://github.com/llvm/llvm-project/pull/74790
The flag -fms-volatile has existed as a -cc1 flag for a while. It also
technically existed as a driver flag, but didn't do anything because it wasn't
wired up to anything in the driver.
This patch adds -
efriedma-quic wrote:
I got a request for this feature from a user that ran into issues porting code
from cl to clang for a baremetal target. I expect scenarios like that to
continue to be relevant for a while.
I don't expect anyone would want to use this for new code because current
practice
https://github.com/efriedma-quic approved this pull request.
I see unrelated changes on the branch? Otherwise LGTM
https://github.com/llvm/llvm-project/pull/71748
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/m
efriedma-quic wrote:
The simplest thing to do is rebase and force-push. You can alternatively try
to use a merge commit, but I'm not completely sure how github would react to
that.
https://github.com/llvm/llvm-project/pull/71748
___
cfe-commits mail
efriedma-quic wrote:
Looks fine now. (You might want to change the title before merging.)
https://github.com/llvm/llvm-project/pull/71748
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commi
efriedma-quic wrote:
This patch appears to do two things:
- Add a "default align" attribute, which instructions the backend to use some
unspecified "default" alignment for the function in question.
- Tells the frontend to apply this attribute specifically to "cold" functions.
This is basically
efriedma-quic wrote:
The proper fix here is probably to just delete the `return
ABIArgInfo::getDirect(llvm::Type::getInt8Ty(getVMContext()));` from the empty
struct codepath on aarch64.
Alignment shouldn't affect whether a class is empty. The issue here is just
that according to aarch64 AAPC
efriedma-quic wrote:
I'd prefer not to call setGVProperties() twice on the same variable; under what
conditions is the first call not sufficient?
https://github.com/llvm/llvm-project/pull/72452
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
h
@@ -80,6 +94,139 @@ class Address {
return Alignment;
}
+ /// Return address with different element type, but same pointer and
+ /// alignment.
+ RawAddress withElementType(llvm::Type *ElemTy) const {
+return RawAddress(getPointer(), ElemTy, getAlignment(), isKnow
@@ -395,27 +395,27 @@ namespace {
void CodeGenFunction::EmitAnyExprToExn(const Expr *e, Address addr) {
// Make sure the exception object is cleaned up if there's an
// exception during initialization.
- pushFullExprCleanup(EHCleanup, addr.getPointer());
- EHScopeStack::s
@@ -232,19 +232,19 @@ static Value *MakeBinaryAtomicValue(
static Value *EmitNontemporalStore(CodeGenFunction &CGF, const CallExpr *E) {
Value *Val = CGF.EmitScalarExpr(E->getArg(0));
- Value *Address = CGF.EmitScalarExpr(E->getArg(1));
+ Address Addr = CGF.EmitPointerWith
efriedma-quic wrote:
I'm a little wary of adding these without actually going through any sort of
standardization process; if other vendors don't support the same interface, we
just have more variations. (See also
https://clang.llvm.org/get_involved.html#criteria )
How consistent are the var
efriedma-quic wrote:
> I figured we can just treat these as clang extensions for the time being. We
> already have two variants that are more or less redundant for specific
> use-cases, (OpenCL and HIP), which should be able to be removed after this.
I'm not sure what you mean here. If you me
efriedma-quic wrote:
Can you not test this by checking an `__attribute__((swiftcall))` function
works in C?
https://github.com/llvm/llvm-project/pull/72298
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/
efriedma-quic wrote:
See also #71986
https://github.com/llvm/llvm-project/pull/72298
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
> The underlying implementation is a string literal in the LLVM syncscope
> argument, but the problem is that this isn't standardized at all and varies
> between backends potentially
We don't have to use the same set of strings as syncscope if that doesn't make
sense.
ht
efriedma-quic wrote:
I mean, looking at the code, as far as I can tell, we always call GetAddrOfVTT
immediately before EmitVTTDefinition, so setGVProperties() has already run, so
running it again shouldn't do anything... unless somehow EmitVTTDefinition is
overwriting the visibility, or setGVP
https://github.com/efriedma-quic approved this pull request.
LGTM
The questions that I came up with while reviewing:
- Does this affect other targets?
It looks like it affects Lanai, but that difference seems fine. It looks like
it doesn't affect anything else in-tree; in particular, the ove
efriedma-quic wrote:
> Is clang aware of the target's default function alignment?
No? On x86, the "default" is set by the line
`setPrefFunctionAlignment(Align(16));`. Which, as the name suggests, is
supposed to be a preference, not a mandatory minimum. And it's subject to
change in the fut
efriedma-quic wrote:
We're already assigning names to the different scopes; we're just doing it in
the __MEMORY_SCOPE_* preprocessor macros. Replacing `_MEMORY_SCOPE_SYSTEM` in
the code with `"system"` doesn't really change the nature of how we assign
names to scopes.
If these are supposed t
efriedma-quic wrote:
Okay. Please add a comment to the code briefly explaining that.
Otherwise looks fine.
https://github.com/llvm/llvm-project/pull/72452
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/
1 - 100 of 1669 matches
Mail list logo
