| #
c1d26062 |
| 01-Jun-2017 |
Piotr Padlewski <[email protected]> |
Emit invariant.group.barrier when using union field
Summary: We need to emit barrier if the union field is CXXRecordDecl because it might have vptrs. The testcode was wrongly devirtualized. It also
Emit invariant.group.barrier when using union field
Summary: We need to emit barrier if the union field is CXXRecordDecl because it might have vptrs. The testcode was wrongly devirtualized. It also proves that having different groups for different dynamic types is not sufficient.
Reviewers: rjmccall, rsmith, mehdi_amini
Subscribers: amharc, cfe-commits
Differential Revision: https://reviews.llvm.org/D31830
llvm-svn: 304448
show more ...
|
|
Revision tags: llvmorg-4.0.1-rc2 |
|
| #
5960a57e |
| 25-May-2017 |
Krzysztof Parzyszek <[email protected]> |
[CodeGen] Pessimize aliasing for member unions (and may-alias) objects
Use the TBAA info of the omnipotent char for these objects.
Differential Revision: https://reviews.llvm.org/D33328
llvm-svn:
[CodeGen] Pessimize aliasing for member unions (and may-alias) objects
Use the TBAA info of the omnipotent char for these objects.
Differential Revision: https://reviews.llvm.org/D33328
llvm-svn: 303851
show more ...
|
| #
8f248234 |
| 18-May-2017 |
Krzysztof Parzyszek <[email protected]> |
[CodeGen] Propagate LValueBaseInfo instead of AlignmentSource
The functions creating LValues propagated information about alignment source. Extend the propagated data to also include information abo
[CodeGen] Propagate LValueBaseInfo instead of AlignmentSource
The functions creating LValues propagated information about alignment source. Extend the propagated data to also include information about possible unrestricted aliasing. A new class LValueBaseInfo will contain both AlignmentSource and MayAlias info.
This patch should not introduce any functional changes.
Differential Revision: https://reviews.llvm.org/D33284
llvm-svn: 303358
show more ...
|
| #
1d993270 |
| 09-May-2017 |
Serge Guelton <[email protected]> |
Suppress all uses of LLVM_END_WITH_NULL. NFC.
Use variadic templates instead of relying on <cstdarg> + sentinel.
This enforces better type checking and makes code more readable.
Differential revis
Suppress all uses of LLVM_END_WITH_NULL. NFC.
Use variadic templates instead of relying on <cstdarg> + sentinel.
This enforces better type checking and makes code more readable.
Differential revision: https://reviews.llvm.org/D32550
llvm-svn: 302572
show more ...
|
|
Revision tags: llvmorg-4.0.1-rc1 |
|
| #
6b22dda5 |
| 26-Apr-2017 |
Vedant Kumar <[email protected]> |
[ubsan] nullability-assign: Check assignments into C++ structs
Fix the nullability-assign check so that it can handle assignments into C++ structs. Previously, such assignments were not instrumented
[ubsan] nullability-assign: Check assignments into C++ structs
Fix the nullability-assign check so that it can handle assignments into C++ structs. Previously, such assignments were not instrumented.
Testing: check-clang, check-ubsan, enabling the existing test in ObjC++ mode, and building some Apple frameworks with -fsanitize=nullability.
llvm-svn: 301482
show more ...
|
| #
e859ebbd |
| 26-Apr-2017 |
Vedant Kumar <[email protected]> |
[ubsan] Skip alignment checks on allocas with known alignment
It's possible to determine the alignment of an alloca at compile-time. Use this information to skip emitting some runtime alignment chec
[ubsan] Skip alignment checks on allocas with known alignment
It's possible to determine the alignment of an alloca at compile-time. Use this information to skip emitting some runtime alignment checks.
Testing: check-clang, check-ubsan.
This significantly reduces the amount of alignment checks we emit when compiling X86ISelLowering.cpp. Here are the numbers from patched/unpatched clangs based on r301361.
------------------------------------------ | Setup | # of alignment checks | ------------------------------------------ | unpatched, -O0 | 47195 | | patched, -O0 | 30876 | (-34.6%) ------------------------------------------
llvm-svn: 301377
show more ...
|
| #
dbbdda4d |
| 17-Apr-2017 |
Vedant Kumar <[email protected]> |
[ubsan] Skip null checks if they are constant-folded away
The IR builder can constant-fold null checks if the pointer operand points to a constant. If the "is-non-null" check is folded away to "true
[ubsan] Skip null checks if they are constant-folded away
The IR builder can constant-fold null checks if the pointer operand points to a constant. If the "is-non-null" check is folded away to "true", don't emit the null check + branch.
Testing: check-clang, check-ubsan.
This slightly reduces the amount of null checks we emit when compiling X86ISelLowering.cpp. Here are the numbers from patched/unpatched clangs based on r300371.
------------------------------------- | Setup | # of null checks | ------------------------------------- | unpatched, -O0 | 25251 | | patched, -O0 | 23925 | (-5.3%) -------------------------------------
llvm-svn: 300509
show more ...
|
| #
379d9c1d |
| 17-Apr-2017 |
Vedant Kumar <[email protected]> |
[ubsan] Skip null checks on pointers to the start of an alloca
Pointers to the start of an alloca are non-null, so we don't need to emit runtime null checks for them.
Testing: check-clang, check-ub
[ubsan] Skip null checks on pointers to the start of an alloca
Pointers to the start of an alloca are non-null, so we don't need to emit runtime null checks for them.
Testing: check-clang, check-ubsan.
This significantly reduces the amount of null checks we emit when compiling X86ISelLowering.cpp. Here are the numbers from patched / unpatched clangs based on r300371.
------------------------------------- | Setup | # of null checks | ------------------------------------- | unpatched, -O0 | 45439 | | patched, -O0 | 25251 | (-44.4%) -------------------------------------
llvm-svn: 300508
show more ...
|
| #
116aebca |
| 14-Apr-2017 |
Vedant Kumar <[email protected]> |
[ubsan] Don't check alignment if the alignment is 1
If a pointer is 1-byte aligned, there's no use in checking its alignment. Somewhat surprisingly, ubsan can spend a significant amount of time doin
[ubsan] Don't check alignment if the alignment is 1
If a pointer is 1-byte aligned, there's no use in checking its alignment. Somewhat surprisingly, ubsan can spend a significant amount of time doing just that!
This loosely depends on D30283.
Testing: check-clang, check-ubsan, and a stage2 ubsan build.
Differential Revision: https://reviews.llvm.org/D30285
llvm-svn: 300371
show more ...
|
| #
ffd7c887 |
| 14-Apr-2017 |
Vedant Kumar <[email protected]> |
[ubsan] Reduce alignment checking of C++ object pointers
This patch teaches ubsan to insert an alignment check for the 'this' pointer at the start of each method/lambda. This allows clang to emit si
[ubsan] Reduce alignment checking of C++ object pointers
This patch teaches ubsan to insert an alignment check for the 'this' pointer at the start of each method/lambda. This allows clang to emit significantly fewer alignment checks overall, because if 'this' is aligned, so are its fields.
This is essentially the same thing r295515 does, but for the alignment check instead of the null check. One difference is that we keep the alignment checks on member expressions where the base is a DeclRefExpr. There's an opportunity to diagnose unaligned accesses in this situation (as pointed out by Eli, see PR32630).
Testing: check-clang, check-ubsan, and a stage2 ubsan build.
Along with the patch from D30285, this roughly halves the amount of alignment checks we emit when compiling X86FastISel.cpp. Here are the numbers from patched/unpatched clangs based on r298160.
------------------------------------------ | Setup | # of alignment checks | ------------------------------------------ | unpatched, -O0 | 24326 | | patched, -O0 | 12717 | (-47.7%) ------------------------------------------
Differential Revision: https://reviews.llvm.org/D30283
llvm-svn: 300370
show more ...
|
| #
502ad60c |
| 10-Apr-2017 |
Matt Arsenault <[email protected]> |
Update for AllocaInst construction changes
llvm-svn: 299889
|
| #
1a8030e7 |
| 07-Apr-2017 |
Evgeniy Stepanov <[email protected]> |
[cfi] Emit __cfi_check stub in the frontend.
Previously __cfi_check was created in LTO optimization pipeline, which means LLD has no way of knowing about the existence of this symbol without rescann
[cfi] Emit __cfi_check stub in the frontend.
Previously __cfi_check was created in LTO optimization pipeline, which means LLD has no way of knowing about the existence of this symbol without rescanning the LTO output object. As a result, LLD fails to export __cfi_check, even when given --export-dynamic-symbol flag.
llvm-svn: 299806
show more ...
|
| #
e7cdcdea |
| 04-Apr-2017 |
Jin-Gu Kang <[email protected]> |
Preserve vec3 type.
Summary: Preserve vec3 type with CodeGen option.
Reviewers: Anastasia, bruno
Reviewed By: Anastasia
Subscribers: bruno, ahatanak, cfe-commits
Differential Revision: https://r
Preserve vec3 type.
Summary: Preserve vec3 type with CodeGen option.
Reviewers: Anastasia, bruno
Reviewed By: Anastasia
Subscribers: bruno, ahatanak, cfe-commits
Differential Revision: https://reviews.llvm.org/D30810
llvm-svn: 299445
show more ...
|
| #
a63f9157 |
| 21-Mar-2017 |
George Burgess IV <[email protected]> |
Let llvm.objectsize be conservative with null pointers
D28494 adds another parameter to @llvm.objectsize. Clang needs to be sure to pass that third arg whenever applicable.
llvm-svn: 298431
|
| #
de86482c |
| 21-Mar-2017 |
Reid Kleckner <[email protected]> |
Update Clang for LLVM rename AttributeSet -> AttributeList
llvm-svn: 298394
|
| #
129edab1 |
| 09-Mar-2017 |
Vedant Kumar <[email protected]> |
Retry: [ubsan] Detect UB loads from bitfields
It's possible to load out-of-range values from bitfields backed by a boolean or an enum. Check for UB loads from bitfields.
This is the motivating exam
Retry: [ubsan] Detect UB loads from bitfields
It's possible to load out-of-range values from bitfields backed by a boolean or an enum. Check for UB loads from bitfields.
This is the motivating example:
struct S { BOOL b : 1; // Signed ObjC BOOL. };
S s; s.b = 1; // This is actually stored as -1. if (s.b == 1) // Evaluates to false, -1 != 1. ...
Changes since the original commit:
- Single-bit bools are a special case (see CGF::EmitFromMemory), and we can't avoid dealing with them when loading from a bitfield. Don't try to insert a check in this case.
Differential Revision: https://reviews.llvm.org/D30423
llvm-svn: 297389
show more ...
|
| #
3dea91fe |
| 09-Mar-2017 |
Vedant Kumar <[email protected]> |
Revert "[ubsan] Detect UB loads from bitfields"
This reverts commit r297298. It breaks the self-host on this bot:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/962/ste
Revert "[ubsan] Detect UB loads from bitfields"
This reverts commit r297298. It breaks the self-host on this bot:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/962/steps/build%20clang%2Fubsan/logs/stdio
llvm-svn: 297331
show more ...
|
| #
5c13623a |
| 08-Mar-2017 |
Vedant Kumar <[email protected]> |
[ubsan] Detect UB loads from bitfields
It's possible to load out-of-range values from bitfields backed by a boolean or an enum. Check for UB loads from bitfields.
This is the motivating example:
[ubsan] Detect UB loads from bitfields
It's possible to load out-of-range values from bitfields backed by a boolean or an enum. Check for UB loads from bitfields.
This is the motivating example:
struct S { BOOL b : 1; // Signed ObjC BOOL. };
S s; s.b = 1; // This is actually stored as -1. if (s.b == 1) // Evaluates to false, -1 != 1. ...
Differential Revision: https://reviews.llvm.org/D30423
llvm-svn: 297298
show more ...
|
|
Revision tags: llvmorg-4.0.0, llvmorg-4.0.0-rc4 |
|
| #
092d0652 |
| 06-Mar-2017 |
Reid Kleckner <[email protected]> |
Don't assume cleanup emission preserves dominance in expr evaluation
Summary: Because of the existence branches out of GNU statement expressions, it is possible that emitting cleanups for a full exp
Don't assume cleanup emission preserves dominance in expr evaluation
Summary: Because of the existence branches out of GNU statement expressions, it is possible that emitting cleanups for a full expression may cause the new insertion point to not be dominated by the result of the inner expression. Consider this example:
struct Foo { Foo(); ~Foo(); int x; }; int g(Foo, int); int f(bool cond) { int n = g(Foo(), ({ if (cond) return 0; 42; })); return n; }
Before this change, result of the call to 'g' did not dominate its use in the store to 'n'. The early return exit from the statement expression branches to a shared cleanup block, which ends in a switch between the fallthrough destination (the assignment to 'n') or the function exit block.
This change solves the problem by spilling and reloading expression evaluation results when any of the active cleanups have branches.
I audited the other call sites of enterFullExpression, and they don't appear to keep and Values live across the site of the cleanup, except in ARC code. I wasn't able to create a test case for ARC that exhibits this problem, though.
Reviewers: rjmccall, rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D30590
llvm-svn: 297084
show more ...
|
|
Revision tags: llvmorg-4.0.0-rc3 |
|
| #
5a972653 |
| 27-Feb-2017 |
Vedant Kumar <[email protected]> |
[ubsan] Factor out logic to emit a range check. NFC.
This is a readability improvement, but it will also help prep an upcoming patch to detect UB loads from bitfields.
llvm-svn: 296374
|
| #
e550d11d |
| 23-Feb-2017 |
Vedant Kumar <[email protected]> |
Rename a helper function, NFC.
llvm-svn: 295918
|
| #
34b1fd6a |
| 17-Feb-2017 |
Vedant Kumar <[email protected]> |
Retry^2: [ubsan] Reduce null checking of C++ object pointers (PR27581)
This patch teaches ubsan to insert exactly one null check for the 'this' pointer per method/lambda.
Previously, given a load o
Retry^2: [ubsan] Reduce null checking of C++ object pointers (PR27581)
This patch teaches ubsan to insert exactly one null check for the 'this' pointer per method/lambda.
Previously, given a load of a member variable from an instance method ('this->x'), ubsan would insert a null check for 'this', and another null check for '&this->x', before allowing the load to occur.
Similarly, given a call to a method from another method bound to the same instance ('this->foo()'), ubsan would a redundant null check for 'this'. There is also a redundant null check in the case where the object pointer is a reference ('Ref.foo()').
This patch teaches ubsan to remove the redundant null checks identified above.
Testing: check-clang, check-ubsan, and a stage2 ubsan build.
I also compiled X86FastISel.cpp with -fsanitize=null using patched/unpatched clangs based on r293572. Here are the number of null checks emitted:
------------------------------------- | Setup | # of null checks | ------------------------------------- | unpatched, -O0 | 21767 | | patched, -O0 | 10758 | -------------------------------------
Changes since the initial commit: - Don't introduce any unintentional object-size or alignment checks. - Don't rely on IRGen of C labels in the test.
Differential Revision: https://reviews.llvm.org/D29530
llvm-svn: 295515
show more ...
|
| #
18348ea9 |
| 17-Feb-2017 |
Vedant Kumar <[email protected]> |
[ubsan] Pass a set of checks to skip to EmitTypeCheck() (NFC)
CodeGenFunction::EmitTypeCheck accepts a bool flag which controls whether or not null checks are emitted. Make this a bit more flexible
[ubsan] Pass a set of checks to skip to EmitTypeCheck() (NFC)
CodeGenFunction::EmitTypeCheck accepts a bool flag which controls whether or not null checks are emitted. Make this a bit more flexible by changing the bool to a SanitizerSet.
Needed for an upcoming change which deals with a scenario in which we only want to emit null checks.
llvm-svn: 295514
show more ...
|
| #
29ba8d9b |
| 17-Feb-2017 |
Vedant Kumar <[email protected]> |
Revert "Retry: [ubsan] Reduce null checking of C++ object pointers (PR27581)"
This reverts commit r295401. It breaks the ubsan self-host. It inserts object size checks once per C++ method which fire
Revert "Retry: [ubsan] Reduce null checking of C++ object pointers (PR27581)"
This reverts commit r295401. It breaks the ubsan self-host. It inserts object size checks once per C++ method which fire when the structure is empty.
llvm-svn: 295494
show more ...
|
| #
55875b99 |
| 17-Feb-2017 |
Vedant Kumar <[email protected]> |
Retry: [ubsan] Reduce null checking of C++ object pointers (PR27581)
This patch teaches ubsan to insert exactly one null check for the 'this' pointer per method/lambda.
Previously, given a load of
Retry: [ubsan] Reduce null checking of C++ object pointers (PR27581)
This patch teaches ubsan to insert exactly one null check for the 'this' pointer per method/lambda.
Previously, given a load of a member variable from an instance method ('this->x'), ubsan would insert a null check for 'this', and another null check for '&this->x', before allowing the load to occur.
Similarly, given a call to a method from another method bound to the same instance ('this->foo()'), ubsan would a redundant null check for 'this'. There is also a redundant null check in the case where the object pointer is a reference ('Ref.foo()').
This patch teaches ubsan to remove the redundant null checks identified above.
Testing: check-clang and check-ubsan. I also compiled X86FastISel.cpp with -fsanitize=null using patched/unpatched clangs based on r293572. Here are the number of null checks emitted:
------------------------------------- | Setup | # of null checks | ------------------------------------- | unpatched, -O0 | 21767 | | patched, -O0 | 10758 | -------------------------------------
Changes since the initial commit: don't rely on IRGen of C labels in the test.
Differential Revision: https://reviews.llvm.org/D29530
llvm-svn: 295401
show more ...
|