♟ vitalybuka

Revert "[NFC][StackSafety] Add index test"

[NFC][StackSafety] Add index test

[NFC][StackSafety] noinline in alias tests

[NFC][StackSafety] Fix statistics

Revert "[StackSafety] Skip ambiguous lifetime analysis"

[StackSafety,NFC] Add Stats counters

[StackSafety,NFC] Fix tests in debug

[StackSafety,NFC] Add more tests

[StackSafety,NFC] Sort llvm-lto2 resolutions in tests

[StackSafety,NFC] Add debug counters

[StackSafety,NFC] Use CHECK-EMPTY in tests

[LLParser,NFC] Simplify forward GV refs update

[StackSafety] Skip ambiguous lifetime analysis

[LTO,NFC] Skip generateParamAccessSummary when empty

remove if (!HasParamAccess)

In D85238#2201212, @tejohnson wrote:

That certainly looks cleaner, can't recall why I wrote it the original way. But why does this depend on D85182? I must be missing something.

remove commented text

[StackSafety,NFC] Add combined index test

In D81242#2188467, @tejohnson wrote:
In D81242#2188441, @vitalybuka wrote:
In D81242#2183383, @tejohnson wrote:

Is the stack safety analysis meant to be always on with ThinLTO?

During compilation most of the time it should be off.
However during linking I assume that most build FS->paramAccesses() is empty, so no hash lookup is expected. So I assume empty looks should be cheap:
for (auto &GVS : Index) {
    for (auto &GV : GVS.second.SummaryList) {
}}
As it paramAccesses suppose to be non-empty for MTE builds for now, so if it's not empty on internal build, then the bug it likely around why it's not empty there.
Can you send me email with internal build details?
Will do

[StackSafety, NFC] Don't insert empty objects into the map

In D81242#2183383, @tejohnson wrote:

Is the stack safety analysis meant to be always on with ThinLTO?

During compilation most of the time it should be off.
However during linking I assume that most build FS->paramAccesses() is empty, so no hash lookup is expected. So I assume empty looks should be cheep:

In D81242#2183383, @tejohnson wrote:

I just noticed that generateParamAccessSummary is taking a bit over 5% of the ThinLTO thin link step in an internal build (and will soon be more than 5% as I found another analysis that is hogging compile time that I'm going to work on fixing). This is currently the second hottest analysis in the thin link. Is the stack safety analysis meant to be always on with ThinLTO?

I have a theory on what is causing it to incur so much overhead, see below.

[NFC] Remove unused GetUnderlyingObject paramenter

[NFC] GetUnderlyingObject -> getUnderlyingObject

[ValueTracking] Remove AllocaForValue parameter

[NFC] Move findAllocaForValue into ValueTracking.h

LGTM as it fixes update_cc_test_checks.py

feel free to move suggested changes into a separate patch

Could you please move it one dir up with suggested changes?

BTW. Have anyone considered to change/configure arcanist to not to insert them in the first place?

LGTM with clang-format

[sanitizer,NFC] InternalAlloc cleanup

[sanitizer] Disable test on incompatible platforms

Corrected __libfuzzer_is_present symbol inclusion for MSVC x86 32-bit

[sanitizer] Another attempt to fix protoent test

[asan] Dedup MemToShadowSize

[msan] Fix strxfrm test

[lsan] Fix SyntaxWarning: "is" with a literal

[gwp-asan] Fix check-all with LIT_FILTER

[sanitizer] Fix protoent without network

[sanitizer] Revert accidentally committed file

[profile] Enabled test on windows

I've disabled the test https://reviews.llvm.org/rGb128f719a4c826e8f723eaa9b42b607c81f563a5
Please could you take a look and fix it or add comment explaining why it can't be done?

vitalybuka (Vitaly Buka)
User

Projects

User Details

Recent Activity
View All

Yesterday

Fri, Aug 7

Thu, Aug 6

Tue, Aug 4

Mon, Aug 3

Sun, Aug 2

Sat, Aug 1

Fri, Jul 31

Thu, Jul 30

Wed, Jul 29

Tue, Jul 28

Mon, Jul 27

Sun, Jul 26

Thu, Jul 23

Wed, Jul 22

Sat, Jul 18

Fri, Jul 17

Thu, Jul 16

vitalybuka (Vitaly Buka)User