Page MenuHomePhabricator

ellis (Ellis Hoag)
User

Projects

User does not belong to any projects.

User Details

User Since
Jun 14 2018, 5:51 PM (157 w, 2 d)

Recent Activity

Fri, Jun 18

ellis added a comment to D104060: Machine IR Profile.

Neat -- so the value profile (target histogram) of a given callsite is 'distributed' into the callees -- aka each callee function allocating a fixed size buffer to track all incoming edge frequencies? For some small utility functions, they usually have thousands of callsites (incoming edges), thus this approach may significantly reduce the profile precision for them? The simple LRU eviction policy may be bad for some patterns like ping-pong effect.

Our current approach is to use a single global buffer for all callees and we store a value that identifies both a callsite address and the callee. We've considered other options like a buffer for each callee, but we settled with the global buffer approach to avoid locks, extra complexity, and runtime. Yeah there are cases where we oversample some edges. I'd say this patch is still the in the experimental stage so there is still work to be done.

Fri, Jun 18, 11:51 AM · Restricted Project
ellis added a comment to D104060: Machine IR Profile.

I probably sound like a broken record, but we've spent a lot of time making sure the map section can be extracted correctly and that the raw section has no excess info. This is a major feature of MIP, the profile data and the function info are separated so that only the necessary data remains in the binary. The question is whether we should extend an existing pgi to support this feature or if MIP deserves to be its own framework. I do see the value in extending one of the many existing pgi to reduce duplicate work. My thoughts are that it would be too invasive to do everything we need; add one or two new sections, create a new .profraw and .profmap format, add a few flags, and extend the tools. By keeping MIP separate, we can make design decisions that align with our code size goal that may not be so easy to do in existing frameworks.

Fri, Jun 18, 11:40 AM · Restricted Project
ellis added a comment to D104060: Machine IR Profile.

@ellis

The main challenge is storing the offset to the profile data without using dynamic relocations. This is complicated by the fact that we use comdat sections within the llvm_mipraw section and that ELF does not seem to directly support section relative addresses. The solution is to use PC relative relocations. start___llvm_mipraw-.Lref gives us the PC relative offset to the start of the raw section and _Z3foov$RAW-.Lref gives us the offset to the profile data for this function relative to the same PC. After we extract the map section, we can subtract these to get the value we want, the section relative raw profile data offset.

(_Z3foov$RAW-.Lref) - (start_llvm_mipraw-.Lref) = _Z3foov$RAW - start_llvm_mipraw

I am unclear about this. Why does the $MAP section needs to know its relative position?

The map section doesn't care about its relative position, but it is used to compute the value we want. Ideally we would do something simple like this to get the section relative address of the symbol.

_Z3foov$RAW-__start___llvm_mipraw

From my testing this doesn't work because these symbols are in different section in ELF (because we use comdat sections for the header). Also, IIRC there were other issues due to relocations getting resolved before the final executable was created and ending up with the wrong values. The solution in this patch was the only one that seems to work in all cases.

Note: if the $RAW symbol has a local linkage or has the hidden visibility, a label difference can indeed avoid a dynamic relative relocation.

# ELF: R_X86_64_PC64
.quad .L__profc_foo-.L__profd_foo

# Mach-O: a pair of X86_64_RELOC_UNSIGNED and X86_64_RELOC_SUBTRACTOR
.quad l___profc_foo-l___profd_foo

Unfortunately this may not be representable in COFF:

% clang -fprofile-generate a.c -c -target x86_64-windows -o d.o
error: Cannot represent this expression

I haven't tested COFF, but i think it might support section relative addresses which would make this format much simpler.

We can use the same trick to encode the function address, we just need to also add the address of the raw section which can be looked up in the binary. This is useful to lookup debug info and join it with our final profile data.

A __profd_$name variable has a similar field referencing the function. It is used by IPVK_IndirectCallTarget so that indirect call target profile can be translated to function names.

We can save the dynamic relocation with the following scheme:

; Note the sub constexpr
@__profd_main = private global { i64, i64, i64*, i64, i8*, i32, [2 x i16] } { i64 -2624081020897602054, i64 742261418966908927, i64* getelementptr inbounds ([1 x i64], [1 x i64]* @__profc_main, i32 0, i32 0), i64 sub (i64 ptrtoint (i32 ()* @alias_main to i64), i64 ptrtoint ({ i64, i64, i64*, i64, i8*, i32, [2 x i16] }* @__profd_main to i64)), i8* null, i32 1, [2 x i16] zeroinitializer }, section "__llvm_prf_data", comdat($__profc_main), align 8

@alias_main = private alias i32 (), i32 ()* @main

define i32 @main() #0 {
  ...

For other fields of __profd_$name, other than the generality and mandatory value profiling (even if you don't use it) issues I mentioned in https://reviews.llvm.org/D104060#2818268 ,
I think the $MAP format is the same.

The format is probably the same. I'm interested to see if we can do something similar to replace our encoded function address.

The $MAP format does not implement these things:

  • using private linkage as much as possible

I think we can use private linkage in more places if we need to.

  • ELF comdat any/noduplicates (this increases object file sizes but can enable --gc-sections for linked images)
  • function name compression

We don't care about the size of the map section since it is extracted out.

Fri, Jun 18, 11:22 AM · Restricted Project
ellis added a comment to D104060: Machine IR Profile.

@davidxl

davidxl: For the dynamic dispatching profiling, does it handle any number of indirect targets or only supports topN?

Our edge profiling patch (not included) was also designed with code size and runtime in mind. We allocate a buffer and sample return addresses, possibly overwriting old values when the buffer is full. Data for common callsites will overwrite data for rare callsites, so I guess it's more like top N, but the size of the buffer can be as large as needed.

davidxl: Basically the callsite context (counter) is passed to the caller so it can do the profiling. GCC does that too.

Our method does not need to touch the callsite code to work. In fact, most of the implementation is done in D104089 so we mostly only change the runtime code.

davidxl: For IRPGO, we plan to add dynamic type profiling at some point. Once that is ready, the problem of message passing style call profiling will be handled.
davidxl: Also if edge profiling is available, profiling direct calls will be a waste as the information can be deduced.

Fri, Jun 18, 10:50 AM · Restricted Project

Thu, Jun 17

ellis updated the diff for D104090: Add MIP tests to compiler-rt.

Add -fPIC -shared test

Thu, Jun 17, 4:34 PM · Restricted Project
ellis updated the diff for D104060: Machine IR Profile.

Raw symbols should have hidden visibility so that -fPIC -shared works

Thu, Jun 17, 4:33 PM · Restricted Project

Wed, Jun 16

ellis updated the diff for D104089: Add call count instrumentation for MIP.

Update API for getRawProfileSymbol()

Wed, Jun 16, 6:38 PM · Restricted Project, Restricted Project
ellis updated the diff for D104060: Machine IR Profile.

The __llvm_mipmap section should not have the SHF_ALLOC bit set.

Wed, Jun 16, 6:37 PM · Restricted Project
ellis added a comment to D104060: Machine IR Profile.

For the profile format, there is indeed a bit redundancy in -fprofile-generate/-fprofile-instr-generate.
Some fields are reserved even if value profiling is not used. I do not have a good idea how we can save the space for coverage usage.
Some fields are 64-bit for generality. As I mentioned, a 32-bit CFG signature makes it less robust when the number of functions exceed roughly 2**16.

Actually, the 32-bit CFG signature we use in MIP is not unique to functions. If two functions have the same basic block layout, they will have the same CFG signature and that is not a problem. The field is used to determine if a function has changed from when it was profiled. I'm not sure if this is different from the other profile formats.

The 32-bit Function PC Offset is probably sufficient for most usage but will not work with medium/large code model programs.

That is true, but we wanted to use 32 bit values to maintain consistency with armv7 targets. We could probably add a flag to support 64 bit values if we need to.

Wed, Jun 16, 6:17 PM · Restricted Project
ellis added a comment to D104060: Machine IR Profile.

I have been slowly trying to making -fprofile-generate/-fprofile-instr-generate object files/linkaged images smaller (e.g. D103372) since last year (I have much to learn..).
(I can test on Linux and Windows, so I'll try making both work. I don't have Mach-O but I am happy to report whatever issues I have found, though.)
I do plan to try PC-relative relocations (I made such improvement for XRay: D78082/D78590/D87977; the only portability issue is that we will require the integrated assembler for mips64)
and probably make the symbol in __llvm_prf_data local alias to avoid an R_*_RELATIVE dynamic relocation.
(I need to study more about llvm-profdata.)

I'm really happy to see this work! I also have much to learn so I'll try to keep an eye out for related diffs in the future.

Wed, Jun 16, 6:08 PM · Restricted Project
ellis added a comment to D104060: Machine IR Profile.

__llvm_mip_call_counts_caller is slow.
It is a function with a custom call convention using RAX as the argument on x86-64.
The impl detail function saves and restores many vector registers.
I haven't studied why __llvm_mip_call_counts_caller is needed.

Yes, __llvm_mip_call_counts_caller is not optimal, but we wanted to first have correctness. Since we are injecting calls to the runtime at the very beginning of functions, we save/restore the stack frame in __llvm_mip_call_counts_caller. In our return address instrumentation code, we also use this helper function to pass the return address register to the runtime.

__llvm_mipmap has these fields. I added an inline comment that -shared doesn't work.

Unfortunately, yes, it seems -shared does not work, but I don't know enough about it to have ideas for fixes at the moment.

        .section        __llvm_mipmap,"aw",@progbits
        .globl  _Z3fooPiS_$MAP
        .p2align        3
_Z3fooPiS_$MAP:
.Lref2:
  ### not sure why this is needed
        .long   __start___llvm_mipraw-.Lref2    # Raw Section Start PC Offset

  ##### this does not link in -fpic -shared mode
        .long   _Z3fooPiS_$RAW-.Lref2           # Raw Profile Symbol PC Offset

        .long   _Z3fooPiS_-.Lref2               # Function PC Offset
        .long   .Lmip_func_end0-_Z3fooPiS_      # Function Size
        .long   0x0                             # CFG Signature
        .long   0                               # Non-entry Block Count
        .long   10                              # Function Name Length
        .ascii  "_Z3fooPiS_"

In the previous comment I describe these fields in detail.

Now this patch series adds machine basic blocks instrumentation.
I wonder what it can do while the regular IR instrumentation cannot.

Machine basic block instrumentation has some awkward points.
Semantic information is lost. The loop optimization definitely cannot be applied.
If an IR basic block maps to multiple machine basic blocks, you need multiple increments for each MBB while with IR BB you may just need one (e.g. dominator).
Edge profiling is tricky. Edge profiling requires splitting critical edges - it is not clear how you can do this after the machine basic block layout is finalized.

The benefit of instrumenting machine basic blocks is we can easily mark MBBs that were not executed as candidates for outlining. We can definitely apply Kirchoff's cirtuit law optimization to reduce the number of stores.

Wed, Jun 16, 6:04 PM · Restricted Project
ellis added a comment to D104060: Machine IR Profile.
  1. Section Layout
Wed, Jun 16, 5:09 PM · Restricted Project
ellis added a comment to D104060: Machine IR Profile.

I've created a gist to help explain some of the unique implementation details and discuss reasons for adding a new framework instead of extending some existing pgi.

Wed, Jun 16, 4:16 PM · Restricted Project

Mon, Jun 14

ellis updated the diff for D104090: Add MIP tests to compiler-rt.

Disable macos test

Mon, Jun 14, 3:21 PM · Restricted Project
ellis updated the diff for D104088: Add clang frontend flags for MIP.

MIP does not support windows

Mon, Jun 14, 3:20 PM · Restricted Project, Restricted Project
ellis updated the diff for D104060: Machine IR Profile.

Fix build failures when using -DDBUILD_SHARED_LIBS=On. Thanks @MaskRay

Mon, Jun 14, 3:17 PM · Restricted Project
ellis added a comment to D104060: Machine IR Profile.

MIP has achieved great size reduction for instrumented binary. My
understanding the savings are mainly from the following:

  1. Smaller counter size (1 byte or 4 byte instead of 8 byte for IR PGO)
  2. extractable per function metadata (mipmap). Using this technique may

increase object file size more (due to extra relocations), but will reduce
executable size.

That is correct. For function coverage MIP inject only one movb instruction in x86 so that the total overhead for every function is 1 byte of global data + 7 bytes of text.

Mon, Jun 14, 11:28 AM · Restricted Project

Sun, Jun 13

ellis abandoned D104164: Remove __llvm_mipmap section in llvm-strip.
Sun, Jun 13, 7:22 PM · Restricted Project
ellis added a comment to D104164: Remove __llvm_mipmap section in llvm-strip.

__llvm_mipmap is not a debug section, so not suitable in isDebugSection.

--strip-debug/--strip-nonalloc/--strip-all-gnu cannot remove SHF_ALLOC sections. The proposed __llvm_mipmap has the SHF_ALLOC flag so not suitable.

Every SHF_ALLOC section is part of the program image. A tool like llvm-strip needs to be conservative and assumes removal of every such section can affect runtime behaviors and probably correctness.
(A self-introspection program can dump its own non-SHF_ALLOC section; this sentence does not discuss such programs.)
Sometimes there are indeed special SHF_ALLOC sections which are strippable, users can remove them with --remove-section. It is not strip's business to understand every such section.

Sun, Jun 13, 7:22 PM · Restricted Project
ellis added a comment to D104060: Machine IR Profile.

Thinking about MIP's use case a little, it seems that it actually matches
what xray does. Xray has very low runtime overhead and can be turned on
always : xra https://llvm.org/docs/XRay.htmly. Have you compare with xray
and consider using that?

Sun, Jun 13, 10:28 AM · Restricted Project

Sat, Jun 12

ellis added a comment to D104060: Machine IR Profile.

I've added text size data to https://gist.github.com/ellishg/92a68cf82bfdeccd10225154425edc69#gistcomment-3778109 and hopefully it is more clear. I randomly chose the test MultiSource/Benchmarks/FreeBench/fourinarow.test to show the size data. You can see the raw data in https://gist.github.com/ellishg/156639f24d728a88067f903cb53e1643

Sat, Jun 12, 4:55 PM · Restricted Project
ellis added a comment to D104164: Remove __llvm_mipmap section in llvm-strip.

I'm wondering if you can use llvm-objcopy --remove-section for these purposes instead?

Sat, Jun 12, 4:46 PM · Restricted Project

Fri, Jun 11

ellis updated the diff for D104060: Machine IR Profile.

MIP instrumentation pass should happen before branch relaxation

Fri, Jun 11, 8:12 PM · Restricted Project
ellis added a comment to D104060: Machine IR Profile.

@davidxl

Can you use the same set of benchmarks for comparison?

I'm not sure what you mean. In https://gist.github.com/ellishg/92a68cf82bfdeccd10225154425edc69 I used llvm-test-suite/MultiSource/Benchmarks/ for all tests.

Fri, Jun 11, 5:52 PM · Restricted Project
ellis requested review of D104164: Remove __llvm_mipmap section in llvm-strip.
Fri, Jun 11, 5:31 PM · Restricted Project
ellis updated the diff for D104088: Add clang frontend flags for MIP.

Move llvm-strip logic into its own commit

Fri, Jun 11, 5:30 PM · Restricted Project, Restricted Project
ellis updated the diff for D104086: Add compiler-rt MIP support.

Update comment style

Fri, Jun 11, 5:29 PM · Restricted Project
ellis updated the diff for D104060: Machine IR Profile.

Fix clang-tidy errors

Fri, Jun 11, 5:28 PM · Restricted Project
ellis added a comment to D104060: Machine IR Profile.

Do you have runtime number with -fcs-profile-generate -mllvm
-disable-vp=true

This will provide more data (BB count) than what MIP can do.

Besides, more options can be added to control the type of profile data
collected in IRPGO to further reduce overhead.

David

Fri, Jun 11, 4:40 PM · Restricted Project
ellis added a comment to D104060: Machine IR Profile.

I've collected some size and runtime metrics from llvm-test-suite. The steps and results can be found in this gist: https://gist.github.com/ellishg/92a68cf82bfdeccd10225154425edc69

Fri, Jun 11, 3:46 PM · Restricted Project

Thu, Jun 10

ellis added a comment to D104086: Add compiler-rt MIP support.

This is a new thing. Do you have an RFC on llvm-dev?

Yeah, the parent commit has more info.
https://reviews.llvm.org/D104060

Thu, Jun 10, 7:17 PM · Restricted Project
ellis added a comment to D104060: Machine IR Profile.

Can you compare the instrumentation overhead with -fcs-profile-generate? (as with -fprofile-generate). You may also want to disable value profiling (which can be expensive) in -fcs-profile-generate.

Thu, Jun 10, 7:05 PM · Restricted Project
ellis published D104083: Add documentation for MIP for review.
Thu, Jun 10, 6:38 PM · Restricted Project
ellis requested review of D104090: Add MIP tests to compiler-rt.
Thu, Jun 10, 6:29 PM · Restricted Project
ellis requested review of D104089: Add call count instrumentation for MIP.
Thu, Jun 10, 6:29 PM · Restricted Project, Restricted Project
ellis requested review of D104088: Add clang frontend flags for MIP.
Thu, Jun 10, 6:29 PM · Restricted Project, Restricted Project
ellis requested review of D104087: Add llvm-mipdata tool.
Thu, Jun 10, 6:29 PM · Restricted Project
ellis requested review of D104086: Add compiler-rt MIP support.
Thu, Jun 10, 6:28 PM · Restricted Project
ellis updated the diff for D104060: Machine IR Profile.

Fix small alignment bug in codegen

Thu, Jun 10, 6:27 PM · Restricted Project
ellis updated the summary of D104060: Machine IR Profile.
Thu, Jun 10, 6:25 PM · Restricted Project
ellis added a comment to D104060: Machine IR Profile.

In the MIP description, it mentions that the counter size is 1 byte. This is good enough for coverage testing, but not enough to track hotness.

Thu, Jun 10, 4:44 PM · Restricted Project
ellis added a comment to D104060: Machine IR Profile.

Very interesting work. A high level question, the CSFDO/CSPGO instruments the program after the inlining pass, so it can provide the same level of coverage for machine IR. What additional information do we expect from MIR profile that is not available in CSFDO?

Thu, Jun 10, 4:13 PM · Restricted Project
ellis updated subscribers of D104060: Machine IR Profile.
Thu, Jun 10, 3:38 PM · Restricted Project
ellis added a comment to D104060: Machine IR Profile.
  1. Machine IR Profile (MIP)
Thu, Jun 10, 3:11 PM · Restricted Project
ellis updated the summary of D104060: Machine IR Profile.
Thu, Jun 10, 3:03 PM · Restricted Project
ellis updated the summary of D104060: Machine IR Profile.
Thu, Jun 10, 2:19 PM · Restricted Project
ellis updated the summary of D104060: Machine IR Profile.
Thu, Jun 10, 2:17 PM · Restricted Project
ellis requested review of D104060: Machine IR Profile.
Thu, Jun 10, 2:15 PM · Restricted Project
ellis abandoned D88329: [objc] Consolidate ObjC name mangle code to AST.
Thu, Jun 10, 2:08 PM · Restricted Project

Mar 19 2021

ellis added a comment to D98982: Sync InstrProfData.inc between llvm and compiler-rt.

Thanks for accepting @davidxl
Would you mind landing this? I don't have commit access.

Mar 19 2021, 3:32 PM · Restricted Project
ellis updated the summary of D98982: Sync InstrProfData.inc between llvm and compiler-rt.
Mar 19 2021, 1:27 PM · Restricted Project
ellis requested review of D98982: Sync InstrProfData.inc between llvm and compiler-rt.
Mar 19 2021, 1:06 PM · Restricted Project

Sep 29 2020

ellis updated the diff for D88497: [objc] Fix memory leak in CGObjCMac.cpp.

Fix a comment to reference the correct method.

Sep 29 2020, 11:01 AM · Restricted Project, Restricted Project
ellis added a comment to D88497: [objc] Fix memory leak in CGObjCMac.cpp.

Yes please commit for me :)

Sep 29 2020, 9:59 AM · Restricted Project, Restricted Project
ellis added a comment to rG98ef7e29b0fe: This reduces code duplication between CGObjCMac.cpp and Mangle.cpp.

This introduced a memory leak that should be fixed in https://reviews.llvm.org/D88497

Sep 29 2020, 8:44 AM
ellis added a comment to D88329: [objc] Consolidate ObjC name mangle code to AST.

https://reviews.llvm.org/D88497 will fix the leak

Sep 29 2020, 8:42 AM · Restricted Project
ellis requested review of D88497: [objc] Fix memory leak in CGObjCMac.cpp.
Sep 29 2020, 8:40 AM · Restricted Project, Restricted Project
ellis added a comment to D88329: [objc] Consolidate ObjC name mangle code to AST.

Oops, I meant to create a new commit rather than amend to this one

Sep 29 2020, 8:17 AM · Restricted Project
ellis updated the diff for D88329: [objc] Consolidate ObjC name mangle code to AST.

[objc] Fix memory leak in CGObjCMac.cpp

Sep 29 2020, 8:16 AM · Restricted Project

Sep 26 2020

ellis added a comment to D88329: [objc] Consolidate ObjC name mangle code to AST.

Thanks for accepting @rjmccall. Could you land this? I don't have commit access yet.

Sep 26 2020, 8:23 AM · Restricted Project
ellis updated the diff for D88329: [objc] Consolidate ObjC name mangle code to AST.

Update call sites

Sep 26 2020, 7:56 AM · Restricted Project

Sep 25 2020

ellis updated the diff for D88329: [objc] Consolidate ObjC name mangle code to AST.

Rename mangleObjCMethodName

Sep 25 2020, 5:14 PM · Restricted Project
ellis updated the diff for D88329: [objc] Consolidate ObjC name mangle code to AST.

Fix variable name

Sep 25 2020, 12:11 PM · Restricted Project
ellis requested review of D88329: [objc] Consolidate ObjC name mangle code to AST.
Sep 25 2020, 12:08 PM · Restricted Project

Aug 10 2020

ellis added a comment to D85569: [NVPTX] Fix typo in lit test.

It looks like the tests pass now. @hiraditya could you land this?

Aug 10 2020, 6:53 PM · Restricted Project
ellis updated the diff for D85569: [NVPTX] Fix typo in lit test.

Sorry, I keep missing mismatched labels

Aug 10 2020, 10:54 AM · Restricted Project
ellis updated the diff for D85569: [NVPTX] Fix typo in lit test.

Fix more labels

Aug 10 2020, 10:38 AM · Restricted Project
ellis updated the diff for D85569: [NVPTX] Fix typo in lit test.

Fix label

Aug 10 2020, 9:45 AM · Restricted Project
ellis updated the diff for D85569: [NVPTX] Fix typo in lit test.

Fix function name

Aug 10 2020, 9:43 AM · Restricted Project

Aug 7 2020

ellis added a comment to D85569: [NVPTX] Fix typo in lit test.

@hiraditya would you mind landing this? I don't have commit access yet.

Aug 7 2020, 5:13 PM · Restricted Project
ellis updated the diff for D85569: [NVPTX] Fix typo in lit test.

LABEL: => CHECK-LABEL:

Aug 7 2020, 4:59 PM · Restricted Project
ellis added inline comments to D85569: [NVPTX] Fix typo in lit test.
Aug 7 2020, 4:42 PM · Restricted Project
ellis requested review of D85569: [NVPTX] Fix typo in lit test.
Aug 7 2020, 4:38 PM · Restricted Project

Jul 7 2020

ellis added inline comments to D82904: [clang-tidy] Warn pointer captured in async block.
Jul 7 2020, 10:52 AM · Restricted Project, Restricted Project
ellis added a comment to D82904: [clang-tidy] Warn pointer captured in async block.

Hey @aaron.ballman, thanks for accepting my diff! Would you mind landing my diff since I don't have commit access yet?

Jul 7 2020, 10:23 AM · Restricted Project, Restricted Project
ellis updated the diff for D82904: [clang-tidy] Warn pointer captured in async block.

Update commit message

Jul 7 2020, 10:11 AM · Restricted Project, Restricted Project
ellis updated the diff for D82904: [clang-tidy] Warn pointer captured in async block.

Add RUN line to test in C

Jul 7 2020, 9:09 AM · Restricted Project, Restricted Project

Jul 6 2020

ellis added inline comments to D82904: [clang-tidy] Warn pointer captured in async block.
Jul 6 2020, 2:06 PM · Restricted Project, Restricted Project
ellis updated the diff for D82904: [clang-tidy] Warn pointer captured in async block.

Use LangOpts.Blocks instead of LangOpts.ObjC and add FIXME about grabbing the use location of a CapturedVar.

Jul 6 2020, 2:02 PM · Restricted Project, Restricted Project
ellis added inline comments to D82904: [clang-tidy] Warn pointer captured in async block.
Jul 6 2020, 12:03 PM · Restricted Project, Restricted Project

Jul 1 2020

ellis updated the diff for D82904: [clang-tidy] Warn pointer captured in async block.

Add isLanguageVersionSupported for Objective-C

Jul 1 2020, 9:47 AM · Restricted Project, Restricted Project

Jun 30 2020

ellis added inline comments to D82904: [clang-tidy] Warn pointer captured in async block.
Jun 30 2020, 4:50 PM · Restricted Project, Restricted Project
ellis updated the diff for D82904: [clang-tidy] Warn pointer captured in async block.

Add double backtick to doc

Jun 30 2020, 3:13 PM · Restricted Project, Restricted Project
ellis updated the diff for D82904: [clang-tidy] Warn pointer captured in async block.

Applied changes suggested in comments

Jun 30 2020, 2:41 PM · Restricted Project, Restricted Project
ellis added a reviewer for D82904: [clang-tidy] Warn pointer captured in async block: Restricted Project.
Jun 30 2020, 12:29 PM · Restricted Project, Restricted Project
ellis created D82904: [clang-tidy] Warn pointer captured in async block.
Jun 30 2020, 12:29 PM · Restricted Project, Restricted Project