Page MenuHomePhabricator
Feed Advanced Search

Today

vsk added a comment to D69210: [Disassembler] Simplify MCInst predicates.

Hm, this patch is bugging me.

Sat, Oct 19, 11:02 AM

Yesterday

vsk created D69210: [Disassembler] Simplify MCInst predicates.
Fri, Oct 18, 6:06 PM
vsk committed rGb081220cfd46: [profile] Use -fPIC -shared in a test instead of -dynamiclib (authored by vsk).
[profile] Use -fPIC -shared in a test instead of -dynamiclib
Fri, Oct 18, 5:57 PM
vsk committed rGf6a46304174e: [profile] Disable instrprof-get-filename-merge-mode.c on Windows (authored by vsk).
[profile] Disable instrprof-get-filename-merge-mode.c on Windows
Fri, Oct 18, 5:47 PM
vsk committed rG937241b0d9e8: [profile] Do not cache __llvm_profile_get_filename result (authored by vsk).
[profile] Do not cache __llvm_profile_get_filename result
Fri, Oct 18, 4:33 PM
vsk closed D69137: [profile] Do not cache __llvm_profile_get_filename result.
Fri, Oct 18, 4:32 PM · Restricted Project, Restricted Project, Restricted Project
vsk added a comment to D69137: [profile] Do not cache __llvm_profile_get_filename result.

FTR, I'm a bit conflicted about the latest version of this patch. On one hand, hiding lprofCurFilename decouples all of the copies of the profiling runtime in a process. On the other, it may cause a regression for users who use the set-filename API with instrumented DSOs. A quick search shows that we have no internal adopters who rely on the behavior, so I'm inclined to go ahead with this.

Fri, Oct 18, 4:32 PM · Restricted Project, Restricted Project, Restricted Project
vsk updated the diff for D69137: [profile] Do not cache __llvm_profile_get_filename result.

Hide lprofCurFilename, per David's suggestion. This requires deleting 'instrprof-set-filename-shared.test'.

Fri, Oct 18, 4:14 PM · Restricted Project, Restricted Project, Restricted Project
vsk updated subscribers of D69178: [DebugInfo] Use DBG_VALUEs IsIndirect field for describing stack spills.

The high level approach makes sense to me. Restricting the meaning of DBG_VALUE's "IsIndirect" operand should reduce the complexity surrounding creating/updating debug instructions. And the ability to recognize loads-from-spills and propagate more DBG_VALUEs is a big plus.

Fri, Oct 18, 3:37 PM · Restricted Project
vsk committed rG32ce14e55e5a: Disable exit-on-SIGPIPE in lldb (authored by vsk).
Disable exit-on-SIGPIPE in lldb
Fri, Oct 18, 2:05 PM
vsk closed D69148: Disable exit-on-SIGPIPE in lldb.
Fri, Oct 18, 2:04 PM · Restricted Project, Restricted Project
vsk accepted D69028: [DebugInfo] Correctly place DW_OP_derefs for arguments passed on stack.

Thanks!

Fri, Oct 18, 10:58 AM · Restricted Project
vsk updated the diff for D69148: Disable exit-on-SIGPIPE in lldb.

Replace the death tests with a non-death test. I plan to commit this later in the day if there aren't any objections.

Fri, Oct 18, 10:30 AM · Restricted Project, Restricted Project
vsk planned changes to D69148: Disable exit-on-SIGPIPE in lldb.

The death tests are flaky. I've noticed two issues:

  1. When run under lit, the DisableExitOnSIGPIPE doesn't actually exit when it receives SIGPIPE. Dtrace suggests that the unit test process inherits an "ignore" sigaction from its parent.
  2. When run in parallel, exiting causes the unit test to run atexit destructors for other unit tests lumped into the SupportTests binary. One of these is a condition_variable destructor and it hangs. Also, gtest warns: Death tests use fork(), which is unsafe particularly in a threaded context. For this test, Google Test detected 21 threads.
Fri, Oct 18, 10:30 AM · Restricted Project, Restricted Project
vsk added a comment to D69069: [IPO] Convert LoopExtractor pass from LoopPass to ModulePass.

Thanks, this looks reasonable to me. Please wait for another +1, as I'm not terribly familiar with the loop pass machinery.

Fri, Oct 18, 9:52 AM · Restricted Project
vsk added inline comments to D69148: Disable exit-on-SIGPIPE in lldb.
Fri, Oct 18, 8:20 AM · Restricted Project, Restricted Project

Thu, Oct 17

vsk added a comment to D69137: [profile] Do not cache __llvm_profile_get_filename result.

maybe we should make lprofCurFilename hidden?

Thu, Oct 17, 4:49 PM · Restricted Project, Restricted Project, Restricted Project
vsk updated the diff for D69148: Disable exit-on-SIGPIPE in lldb.
  • Allow setting a SIGPIPE handler.
Thu, Oct 17, 4:40 PM · Restricted Project, Restricted Project
vsk planned changes to D69148: Disable exit-on-SIGPIPE in lldb.
Thu, Oct 17, 4:30 PM · Restricted Project, Restricted Project
vsk added a comment to D69137: [profile] Do not cache __llvm_profile_get_filename result.

I see.

Even without the patch, I saw two different files are created with %m. How is the bug triggered?
Thu, Oct 17, 4:21 PM · Restricted Project, Restricted Project, Restricted Project
vsk created D69148: Disable exit-on-SIGPIPE in lldb.
Thu, Oct 17, 4:11 PM · Restricted Project, Restricted Project
vsk updated the diff for D69137: [profile] Do not cache __llvm_profile_get_filename result.

The test was not written clearly. I've added a clarifying comment. The test should exit with code 1 if the two filenames compare equal.

Thu, Oct 17, 3:06 PM · Restricted Project, Restricted Project, Restricted Project
vsk added a comment to D69028: [DebugInfo] Correctly place DW_OP_derefs for arguments passed on stack.

This looks great.

Thu, Oct 17, 2:37 PM · Restricted Project
vsk accepted D69109: [DebugInfo] Stop describing imms in TargetInstrInfo's describeLoadedValue() impl.

LGTM! Handling each instruction separately is indeed more safer! Too bad that we can't relay much on MI generic flags such as this one.

Thu, Oct 17, 2:09 PM · Restricted Project, debug-info
vsk created D69137: [profile] Do not cache __llvm_profile_get_filename result.
Thu, Oct 17, 2:00 PM · Restricted Project, Restricted Project, Restricted Project

Tue, Oct 15

vsk added a comment to D68209: [LiveDebugValues] Introduce entry values of unmodified params.

Hi @djtodoro, thanks for the patch as always. I'm curious about the DbgEntryValueMovement field. Could you explain it in a little more detail? At a high level, IIUC, it's used to mark copies of entry values for the purpose of simplifying location lists (i.e. keep an original AT_entry_value location description even if there are copies). Is that correct? Does the approach handle there being multiple copies of an entry value within a block?

Tue, Oct 15, 4:13 PM · Restricted Project, debug-info
vsk accepted D68206: [clang] Remove the DIFlagArgumentNotModified debug info flag.

Sgtm.

Tue, Oct 15, 1:37 PM · debug-info
vsk accepted D68207: [IR] Remove the DIFlagArgumentNotModified debug info flag.

+ 1

Tue, Oct 15, 1:37 PM · Restricted Project, debug-info
vsk added a comment to D68633: [utils] InlineFunction: fix for debug info affecting optimizations.

My suggested solution to that is to handle all allocas the same (not treating two allocas in a row differently from two allocas separated by any other instruction). This makes this part of the code less sensitive to the order of instructions in the input. As a side effect (of such an improvement) the debug invariance problem is expected to go away.

Tue, Oct 15, 1:19 PM · Restricted Project
vsk committed rGc7ec51a7c3ed: [llvm-profdata] Reinstate tools/llvm-profdata/malformed-ptr-to-counter-array. (authored by vsk).
[llvm-profdata] Reinstate tools/llvm-profdata/malformed-ptr-to-counter-array.
Tue, Oct 15, 10:58 AM
vsk committed rGe409f1213190: [llvm-profdata] Remove tools/llvm-profdata/malformed-ptr-to-counter-array.test (authored by vsk).
[llvm-profdata] Remove tools/llvm-profdata/malformed-ptr-to-counter-array.test
Tue, Oct 15, 10:11 AM
vsk requested changes to D68633: [utils] InlineFunction: fix for debug info affecting optimizations.
Tue, Oct 15, 10:01 AM · Restricted Project
vsk added a comment to D68633: [utils] InlineFunction: fix for debug info affecting optimizations.

Hey @yechunliang, thanks for working on this.

Tue, Oct 15, 10:01 AM · Restricted Project

Mon, Oct 14

vsk committed rGeef612bf91b6: [llvm-profdata] Weaken "malformed-ptr-to-counter-array.test" to appease arm bots (authored by vsk).
[llvm-profdata] Weaken "malformed-ptr-to-counter-array.test" to appease arm bots
Mon, Oct 14, 10:25 AM

Fri, Oct 11

vsk committed rG852e3b207651: [llvm-profdata] Make "malformed-ptr-to-counter-array.test" textual (authored by vsk).
[llvm-profdata] Make "malformed-ptr-to-counter-array.test" textual
Fri, Oct 11, 5:28 PM
vsk closed D68718: [llvm-profdata] Make "malformed-ptr-to-counter-array.test" textual.
Fri, Oct 11, 5:28 PM · Restricted Project
vsk added a comment to D52199: [profile] Install headers for custom runtime maintainers.

Friendly ping

Fri, Oct 11, 2:22 PM · Restricted Project

Wed, Oct 9

vsk updated the diff for D68718: [llvm-profdata] Make "malformed-ptr-to-counter-array.test" textual.

Thanks for the correction -- the revised version (hopefully) makes more sense.

Wed, Oct 9, 4:40 PM · Restricted Project
vsk accepted D68733: Use -fdebug-compilation-dir to form absolute paths in coverage mappings.

In PR43614 I mentioned adding an extra argument to llvm-cov to specify the base directory. On second thought, the existing -path-equivalence option should make that unnecessary.

Wed, Oct 9, 4:40 PM · Restricted Project
vsk committed rGc7cfa7c34e3e: [test] Skip entry value test when clang < 10.0.0 (authored by vsk).
[test] Skip entry value test when clang < 10.0.0
Wed, Oct 9, 1:22 PM
vsk added a comment to D66979: [InstrProf] Tighten a check for malformed data records in raw profiles.

Hi @vsk can you provide a description/script on how to recreate the malformed-ptr-to-counter-array.profraw file when someone is changing the profile layout (for example by adding new value profiling kinds).
I'm thinking something like llvm/test/tools/llvm-profdata/raw-two-profiles.test would be nice
Thanks.

Wed, Oct 9, 11:26 AM · Restricted Project
vsk created D68718: [llvm-profdata] Make "malformed-ptr-to-counter-array.test" textual.
Wed, Oct 9, 11:26 AM · Restricted Project

Tue, Oct 8

vsk updated subscribers of D51018: [sancov] Accommodate sancov and coverage report server for use under Windows.

@Dor1s - any chance you know more folks actively working on sancov who have the bandwidth to review?

Tue, Oct 8, 1:56 PM · Restricted Project, Restricted Project
vsk committed rG4805c817c3fa: StopInfo/Mach: Delete PPC support (authored by vsk).
StopInfo/Mach: Delete PPC support
Tue, Oct 8, 1:47 PM
vsk closed D68661: StopInfo/Mach: Delete PPC support.
Tue, Oct 8, 1:47 PM · Restricted Project
vsk created D68661: StopInfo/Mach: Delete PPC support.
Tue, Oct 8, 12:50 PM · Restricted Project
vsk committed rG07c5f2a9b0ad: StopInfo/Mach: Use early-exits, reflow messy comments, NFCI (authored by vsk).
StopInfo/Mach: Use early-exits, reflow messy comments, NFCI
Tue, Oct 8, 12:41 PM
vsk committed rG9852699dcb18: [CodeExtractor] Factor out and reuse shrinkwrap analysis (authored by vsk).
[CodeExtractor] Factor out and reuse shrinkwrap analysis
Tue, Oct 8, 10:17 AM
vsk closed D68616: [CodeExtractor] Factor out and reuse shrinkwrap analysis.
Tue, Oct 8, 10:17 AM · Restricted Project

Mon, Oct 7

vsk committed rG40a1853c497d: [DWARFASTParserClang] Factor out structure-like type parsing, NFC (authored by vsk).
[DWARFASTParserClang] Factor out structure-like type parsing, NFC
Mon, Oct 7, 10:16 PM
vsk committed rGfccfe2c04abf: [DWARFASTParserClang] Delete commented-out typedef, NFC (authored by vsk).
[DWARFASTParserClang] Delete commented-out typedef, NFC
Mon, Oct 7, 10:16 PM
vsk updated the diff for D68616: [CodeExtractor] Factor out and reuse shrinkwrap analysis.
  • Add some documentation.
Mon, Oct 7, 6:06 PM · Restricted Project
vsk created D68616: [CodeExtractor] Factor out and reuse shrinkwrap analysis.
Mon, Oct 7, 5:53 PM · Restricted Project

Fri, Oct 4

vsk updated the diff for D68422: [DWARFASTParserClang] Factor out structure-like type parsing, NFC.
  • Remove the log parameter from ParseTypeFromDWARF.
Fri, Oct 4, 6:53 PM · Restricted Project
vsk added a comment to D68422: [DWARFASTParserClang] Factor out structure-like type parsing, NFC.

Looks good to me. Thanks for doing this. Personally, I'd just remove the Log argument from the function argument list, and let the function re-fetch it if needed. I know we sometimes pass around a Log* variable, but most of the time we don't...

Fri, Oct 4, 6:43 PM · Restricted Project

Thu, Oct 3

vsk added a comment to D68351: [profile] Add a mode to continuously sync counter updates to a file.

+petr who has similar needs for Fuchia platform

Thank you for including me, we have exactly the same use case in Fuchsia and this is the solution I've initially considered and been experimenting with locally based on the discussion with @davidxl. However, after internal discussion we've decided against this solution for two reasons:

  1. This requires the ability to mmap the output file over the (portion of) binary which is something we don't allow in Fuchsia for security reasons; once all modules have been mapped in by the dynamic linker, we don't allow any further changes to their mapping and using this solution would require special dynamic linker which is possible but highly undesirable.
  2. It introduces bloat to both the binary and the output file. It also complicates the runtime implementation due to alignment and padding requirements.

    The alternative solution we've came up and that I've now been implementing is to change the instrumentation to allow extra level of indirection. Concretely, the instrumentation conceptually does the following: c = __profc_foo[idx]; c++; __profc_foo[idx] = c. We'd like to change this c = *(&__profc[idx] + *bias); c++; *(&__profc[idx] + *bias) = c where bias is a global variable set by the runtime to be the offset between the __llvm_prf_cnts section and the corresponding location in the file that's mmapped in. Initially, that offset would be 0 which would result in exactly the same behavior as today, but the runtime can mmap the output file into address space and then change the offset to make the counters be continuously updated.

    The advantage of this solution is that there are no changes needed to the profile format. It also doesn't require mmapping the output file over the binary, the output file can be mmapped anywhere in the address space. The disadvantage is extra overhead since instrumentation is going to be slightly more complicated, although we don't have any numbers yet to quantify how much slower it's going to be. The implementation should be fairly minimal and my tentative plan was to gate it on compiler switch, so it wouldn't affect existing in any way (modulo introducing one new variable in the runtime to hold the bias). I'm hoping to have the prototype ready and uploaded for review within the next few days. What's your opinion on this idea? Would this be something that you'd be interested in as an alternative approach?
Thu, Oct 3, 4:17 PM · Restricted Project
vsk added a comment to D68422: [DWARFASTParserClang] Factor out structure-like type parsing, NFC.

Thank you. I've just realized that Phab's "Raw Diff" mode (https://reviews.llvm.org/F10156020) renders the diff in a much clearer way. I suspect reviewing the raw diff will be much easier than reviewing what Phab has rendered here.

Thu, Oct 3, 3:50 PM · Restricted Project
vsk created D68422: [DWARFASTParserClang] Factor out structure-like type parsing, NFC.
Thu, Oct 3, 2:13 PM · Restricted Project
vsk added a comment to D68351: [profile] Add a mode to continuously sync counter updates to a file.

@vsk Vedant, sorry I'm a bit swamped right now and may not be able to review this promptly. Please let me know If my feedback is important here, I'll try to make up some time in that case. Sorry!

Thu, Oct 3, 10:45 AM · Restricted Project

Wed, Oct 2

vsk added inline comments to D68351: [profile] Add a mode to continuously sync counter updates to a file.
Wed, Oct 2, 4:55 PM · Restricted Project
vsk accepted D67941: Invalidate assumption cache before outlining..

Thanks, lgtm with some minor test updates.

Wed, Oct 2, 2:09 PM · Restricted Project
vsk added a comment to D68192: Fix PR40710: Outlined Function has token parameter but isn't an intrinsic.

One of the reasons why verification of input parameters could be a separate function and not called from isEligible here. The clients can make sanity checks before calling the extractCodeRegion. In general, any optimization pass, would have analysis phase and a transformation phase. IMHO This function should just extract the region and not do anything else. But there's already some check in place here which isn't ideal. The goal of this diff was to fix the ICE. I'm totally fine with repairing CodeExtractor in a separate patch.

Wed, Oct 2, 2:04 PM · Restricted Project
vsk added a comment to D68351: [profile] Add a mode to continuously sync counter updates to a file.
In D68351#1691969, @vsk wrote:
In D68351#1691915, @vsk wrote:

Not sure it belongs in this CL specifically, but would it be possible to later add a mode that defers the initialization of the mmap'd file until specifically requested by the process?

This sounds tricky to me, as the initialization requires some work to be done in each copy of the profile runtime linked into the process.

Could you clarify whether you're referring to processes which use the profiling runtime's static initializer, or not? My understanding is that for processes which do use the runtime's static initializer, it's always desirable to set up the mmap'd file in that initializer. If that's not true, I'd appreciate a counterexample. For processes that don't use the runtime's static initializer, the situation (at Apple, at least) is typically that it's a kernel extension or bare-metal piece of firmware, and the continuous mode isn't really applicable anyway.

We do use the static initializer, but in our use case the process doesn't necessarily know where to write coverage data until some other application-specific code has run.

I see, thanks for explaining.

Ideally, I would like to be able to have the instrumented process receive a shared memory buffer from another process, do continuous profile sync into that memory region, and not care whether it is file-backed or anonymous mapping. So it would be great if application code could give the runtime some sort of handle to that object [1] and tell the runtime to use that space for profiling.

I see. Is the lack of support for value profiling a concern, or would this just be for code coverage?

This would just be for code coverage.

Regardless, I think it's possible to achieve this. If __llvm_profile_set_file_object is called in every copy of the profile runtime in a process, only minor changes to this patch would be required [1]. Judging by how setProfileFile is implemented, I suspect this is the case. If not, a much more invasive change would be needed.

How does one get multiple copies of the runtime in the same process? Does that happen when you load a shared object file that was built with instrumentation?

Wed, Oct 2, 1:52 PM · Restricted Project
vsk added a comment to D68351: [profile] Add a mode to continuously sync counter updates to a file.
In D68351#1691915, @vsk wrote:

Not sure it belongs in this CL specifically, but would it be possible to later add a mode that defers the initialization of the mmap'd file until specifically requested by the process?

This sounds tricky to me, as the initialization requires some work to be done in each copy of the profile runtime linked into the process.

Could you clarify whether you're referring to processes which use the profiling runtime's static initializer, or not? My understanding is that for processes which do use the runtime's static initializer, it's always desirable to set up the mmap'd file in that initializer. If that's not true, I'd appreciate a counterexample. For processes that don't use the runtime's static initializer, the situation (at Apple, at least) is typically that it's a kernel extension or bare-metal piece of firmware, and the continuous mode isn't really applicable anyway.

We do use the static initializer, but in our use case the process doesn't necessarily know where to write coverage data until some other application-specific code has run.

Wed, Oct 2, 1:30 PM · Restricted Project
vsk added a comment to D68351: [profile] Add a mode to continuously sync counter updates to a file.

Not sure it belongs in this CL specifically, but would it be possible to later add a mode that defers the initialization of the mmap'd file until specifically requested by the process?

Wed, Oct 2, 12:53 PM · Restricted Project
vsk added reviewers for D68351: [profile] Add a mode to continuously sync counter updates to a file: Dor1s, sajjadm.
Wed, Oct 2, 11:40 AM · Restricted Project
vsk created D68351: [profile] Add a mode to continuously sync counter updates to a file.
Wed, Oct 2, 11:39 AM · Restricted Project

Tue, Oct 1

vsk added inline comments to D68192: Fix PR40710: Outlined Function has token parameter but isn't an intrinsic.
Tue, Oct 1, 2:27 PM · Restricted Project
vsk accepted D68095: Add a unittest to verify for assumption cache.

Looks great, thanks!

Tue, Oct 1, 1:25 PM · Restricted Project
vsk added inline comments to D67941: Invalidate assumption cache before outlining..
Tue, Oct 1, 1:14 PM · Restricted Project
vsk accepted D68282: [JSON] Use LLVM's library for decoding JSON in StructuredData.
Tue, Oct 1, 10:37 AM · Restricted Project, Restricted Project
vsk committed rGa1e7efaaa8ac: [ReleaseProcess] Document requirement to set MACOSX_DEPLOYMENT_TARGET (authored by vsk).
[ReleaseProcess] Document requirement to set MACOSX_DEPLOYMENT_TARGET
Tue, Oct 1, 10:11 AM

Mon, Sep 30

vsk accepted D68248: [JSON] Use LLVM's library for encoding JSON.

Sweet! Does this 'automatically' fix the 'llvm-argdumper has issues escaping JSON-ified input' issue we discussed in person?

Mon, Sep 30, 5:22 PM · Restricted Project, Restricted Project
vsk added inline comments to D68192: Fix PR40710: Outlined Function has token parameter but isn't an intrinsic.
Mon, Sep 30, 5:18 PM · Restricted Project
vsk committed rGc03c2e886ee0: [StackFrameList][DFS] Turn a few raw pointers into references, NFC (authored by vsk).
[StackFrameList][DFS] Turn a few raw pointers into references, NFC
Mon, Sep 30, 2:23 PM
vsk added inline comments to D68095: Add a unittest to verify for assumption cache.
Mon, Sep 30, 1:09 PM · Restricted Project
vsk added a comment to D67941: Invalidate assumption cache before outlining..

I see, this looks good to me with a small test update.

Mon, Sep 30, 1:03 PM · Restricted Project
vsk requested changes to D68192: Fix PR40710: Outlined Function has token parameter but isn't an intrinsic.

Thanks for working on this!

Mon, Sep 30, 1:00 PM · Restricted Project
vsk committed rGb5a1cf9bf88d: [test] Make TestBasicEntryValuesX86_64 run on Linux as well as Darwin (authored by vsk).
[test] Make TestBasicEntryValuesX86_64 run on Linux as well as Darwin
Mon, Sep 30, 10:13 AM

Fri, Sep 27

vsk committed rG84ca5c8cbf9e: Revert "[profile] Add a test dependency on cxx-headers" (authored by vsk).
Revert "[profile] Add a test dependency on cxx-headers"
Fri, Sep 27, 1:25 PM
vsk committed rG20daf91af204: [profile] Add a test dependency on cxx-headers (authored by vsk).
[profile] Add a test dependency on cxx-headers
Fri, Sep 27, 1:14 PM
vsk committed rG9639f3572aa9: [profile] Mark instrprof-gcov-fork.test UNSUPPORTED on Darwin as well (authored by vsk).
[profile] Mark instrprof-gcov-fork.test UNSUPPORTED on Darwin as well
Fri, Sep 27, 1:14 PM
vsk added inline comments to D52199: [profile] Install headers for custom runtime maintainers.
Fri, Sep 27, 11:09 AM · Restricted Project
vsk updated subscribers of D68130: [lldb] Don't emit artificial constructor declarations as global functions.

Great find. The changes in this patch makes sense to me locally, but I'm having trouble picking up on the context necessary to confidently 'lgtm'. + @JDevlieghere & @labath to get some more experienced people.

Fri, Sep 27, 10:43 AM · Restricted Project
vsk added a comment to D66526: [utils] Add the llvm-locstats tool.

This is checking for the existence of llvm-locstats before running the test? Seems reasonable to me, please go ahead and feel free to fix forwards. Thanks!

Fri, Sep 27, 10:27 AM · Restricted Project, debug-info

Thu, Sep 26

vsk added inline comments to D52199: [profile] Install headers for custom runtime maintainers.
Thu, Sep 26, 1:04 PM · Restricted Project

Wed, Sep 25

vsk added inline comments to D67941: Invalidate assumption cache before outlining..
Wed, Sep 25, 3:01 PM · Restricted Project
vsk committed rGf6bc251274f3: [Mangle] Add flag to asm labels to disable '\01' prefixing (authored by vsk).
[Mangle] Add flag to asm labels to disable '\01' prefixing
Wed, Sep 25, 11:00 AM
vsk updated the diff for D67774: [Mangle] Add flag to asm labels to disable '\01' prefixing.
  • Add a comment describing where non-literal labels are used.
Wed, Sep 25, 10:16 AM · Restricted Project

Tue, Sep 24

vsk updated the diff for D52199: [profile] Install headers for custom runtime maintainers.
  • Drop an extraneous lldb change.
Tue, Sep 24, 6:16 PM · Restricted Project
vsk updated the diff for D52199: [profile] Install headers for custom runtime maintainers.

@delcypher apologies for the massive delay, and thanks for pointing out that issue. This just came up again internally -- PTAL :)?

Tue, Sep 24, 6:15 PM · Restricted Project
vsk updated the diff for D67774: [Mangle] Add flag to asm labels to disable '\01' prefixing.
  • Address latest round of comments.
Tue, Sep 24, 6:05 PM · Restricted Project
vsk added inline comments to D67774: [Mangle] Add flag to asm labels to disable '\01' prefixing.
Tue, Sep 24, 3:56 PM · Restricted Project
vsk added a comment to D67941: Invalidate assumption cache before outlining..

Ah, could you add a test for this that asserts with D67936 applied?

Tue, Sep 24, 2:30 PM · Restricted Project
vsk added a comment to D67941: Invalidate assumption cache before outlining..

Is there a test case for the assertion failure? (I'm assuming that the test attached to D67936 does _not_, is that right?)

Tue, Sep 24, 1:53 PM · Restricted Project

Mon, Sep 23

vsk updated the diff for D67774: [Mangle] Add flag to asm labels to disable '\01' prefixing.
  • Address latest review feedback.
Mon, Sep 23, 12:43 PM · Restricted Project
vsk accepted D67770: [Debuginfo] dbg.value points to undef value after Induction Variable Simplification..

Thanks, lgtm!

Mon, Sep 23, 8:58 AM · debug-info, Restricted Project

Fri, Sep 20

vsk accepted D67398: [DebugInfo] LiveDebugValues: Move DBG_VALUE creation into VarLoc class.

Really nice!

Fri, Sep 20, 1:25 PM · Restricted Project
vsk accepted D67393: [DebugInfo] LiveDebugValues: Defer all DBG_VALUE creation during analysis.

First, DBG_VALUEs aren't necessarily source-level assignments *before* LiveDebugValues either, they update the SSA value that a (fragment) of a source-level variable can be found in, but that SSA value could have been created by the compiler and has not necessarily any relation to a source-level assignment (think about salvageDebugInfo, for example).

(Unfortunately I'm not known for operating the English language effectively). My meaning in the wording was about the placement of a dbg.value/DBG_VALUE within a block, ignoring its operand. AFAIUI, for any LLVM-IR instruction i in a function, and a (fragment of) variable, to determine the variables location at i one has to do an entire dominance-frontier analysis to work out which dbg.value/DBG_VALUE dominates i (potentially none of them). This method of recording the _position_ where variable locations _change_, closely matches the original source program: if you had five assignments to a variable in a program, you'd have five dbg.values, regardless of their operands.

The fact that the DBG_VALUE has no effect outside of the current basic block just falls out of DbgEntityHistoryCalculator not doing a LiveDebugVariable-style data flow analysis, but IMO that isn't a change in semantics, it would be *legal* for it to perform one, it just would be pointless after LiveDebugValues has propagated DBG_VALUEs across basic blocks and reached a fixed point.

All true; this is where a question of "what is the design" de-jure and de-facto comes in. Because DbgEntityHistoryCalculator currently relies on LiveDebugValues having run its analysis, does that not _make_ it a semantic change? At the very least, because that's what I saw when trying to document these things, that's what I wrote.

Alternately, we could document the change in interpretation as being an optimisation that DbgEntityHistoryCalculator performs/relies on, rather than being a change in semantics. (I think these are both sides of the same coin when it comes to explaining internal state).

Fri, Sep 20, 1:08 PM · Restricted Project
vsk added a comment to D66526: [utils] Add the llvm-locstats tool.

Yes, please go for it :)

Fri, Sep 20, 12:14 PM · Restricted Project, debug-info