History log of /llvm-project-15.0.7/clang/lib/CodeGen/CGExpr.cpp (Results 301 – 325 of 1262)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 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 ...


1...<<11121314151617181920>>...51