llvm dev - Mar 2016 - Ignoring coverage for noreturn decls

Hi all,

Recently I’ve noticed in coverage profiles that llvm_unreachable and the like
are considered uncovered because there’s no special behavior in instrumentation
to ‘ignore’ noreturn paths.

While I don’t necessarily think it’s ideal to ignore all noreturn decls, I think
there’s definitely room for some heuristics around ignoring things like
llvm_unreachable (perhaps opt-in?). I’m investigating emitting a zero region for
all noreturn decls whilst codegenning, as a start.

Anyone have any input as to a) if this is a good idea, or b) how best to
implement and expose it?

Thanks,
Harlan

+ cfe-dev
> On Mar 28, 2016, at 1:23 PM, Harlan Haskins via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Hi all,
> 
> Recently I’ve noticed in coverage profiles that llvm_unreachable and the
like are considered uncovered because there’s no special behavior in
instrumentation to ‘ignore’ noreturn paths.
FWIW, Daniel Dunbar and a few others have brought up the lack of a flexible
"suppress coverage" mechanism as a pain-point.

There are two separate but related solutions:

  - We should automatically emit zero mappings for code regions dominated by a
call to a noreturn function.

  - We should offer some general way to 'turn off' coverage for
arbitrary chunks of code.

> While I don’t necessarily think it’s ideal to ignore all noreturn decls, I
think there’s definitely room for some heuristics around ignoring things like
llvm_unreachable (perhaps opt-in?).
I think it's actually useful to have coverage for noreturn functions.
Googletest lets you write death tests for this sort of thing.

Maybe it makes sense to emit zero regions at the _callsites_ of noreturn
functions instead. Wdyt?

> I’m investigating emitting a zero region for all noreturn decls whilst
codegenning, as a start.
> 
> Anyone have any input as to a) if this is a good idea, or b) how best to
implement and expose it?
It might be interesting to try this and see if the coverage reports really are
much nicer.

thanks
vedant

> On Mar 28, 2016, at 8:31 PM, Vedant Kumar <vsk at apple.com> wrote:
> 
> + cfe-dev
> 
>> On Mar 28, 2016, at 1:23 PM, Harlan Haskins via llvm-dev <llvm-dev
at lists.llvm.org> wrote:
>> 
>> Hi all,
>> 
>> Recently I’ve noticed in coverage profiles that llvm_unreachable and
the like are considered uncovered because there’s no special behavior in
instrumentation to ‘ignore’ noreturn paths.
> 
> FWIW, Daniel Dunbar and a few others have brought up the lack of a flexible
"suppress coverage" mechanism as a pain-point.
> 
> There are two separate but related solutions:
> 
>  - We should automatically emit zero mappings for code regions dominated by
a call to a noreturn function.
> 
>  - We should offer some general way to 'turn off' coverage for
arbitrary chunks of code.
> 
> 
>> While I don’t necessarily think it’s ideal to ignore all noreturn
decls, I think there’s definitely room for some heuristics around ignoring
things like llvm_unreachable (perhaps opt-in?).
> 
> I think it's actually useful to have coverage for noreturn functions.
Googletest lets you write death tests for this sort of thing.
> 
> Maybe it makes sense to emit zero regions at the _callsites_ of noreturn
functions instead. Wdyt?
Yep, this is actually what I meant. I definitely think you’re right that we need
to inspect the CFG surrounding a noreturn path as well, because code that’s
guarded by an llvm_unreachable shouldn’t be counted either.

There doesn’t seem to be a warning for statements after noreturn either:

$ cat noreturn.c
#include <stdio.h>

int main() {
    __builtin_unreachable();
    while (1) puts("Hello, world.");
    return 0;
}

$ clang -Wall -Wpedantic noreturn.c -o noreturn
$ ./a.out
'./a.out' terminated by signal SIGBUS (Misaligned address error)

>> I’m investigating emitting a zero region for all noreturn decls whilst
codegenning, as a start.
>> 
>> Anyone have any input as to a) if this is a good idea, or b) how best
to implement and expose it?
> 
> It might be interesting to try this and see if the coverage reports really
are much nicer.
> 
> thanks
> vedant
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160329/aab2ddfd/attachment.html>