[llvm-dev] In LLVM IR, how can I determine if a switch statement had an explicit default case?

[don hinton via llvm-dev]

Hi Tim:

Actually, after thinking about it a bit more, I really can't exclude the
default case even if it is implicit.  If the block after the switch is
never covered, and doesn't have an unreachable instruction, I should really
try to cover it as well.

As always, explaining the problem helped.

thanks again...
don

On Tue, Nov 15, 2016 at 8:35 AM, don hinton <hintonda at gmail.com> wrote:

> Hi Tim:
>
> That's essentially what I came up with too, but was hoping there might be
> an existing analysis pass that could be helpful.
>
> I'm writing a tool that can inject faults at runtime to increase code
> coverage, e.g, based on gcov results.  It supports branch (if only) and
> switch instructions, but currently ignores branches associated with loops,
> though I hope to add some support for non-range based loops at some point.
>
> If I could determine that the default case is implicit, I could ignore it
> at compile time.  Otherwise, it's included in the list of candidates and
> only gets excluded at runtime based on coverage.  Also, determining the
> correct fault value to inject for the default case must be calculated,
> which isn't as easy as using ICmpInst::makeConstantRange for if branches.
>
> thanks...
> don
>
>
>
>
>
> On Tue, Nov 15, 2016 at 7:35 AM, Tim Northover <t.p.northover at gmail.com>
> wrote:
>
>> Hi Don,
>>
>> On 14 November 2016 at 19:00, don hinton via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>> > Since a SwitchInst always has a default case even if no default case
>> > appeared in the code, what's the best way to determine if it's explicit
>> or
>> > implicit?
>>
>> You'd have to examine Clang's AST for that information, it's not
>> present once the LLVM IR has been emitted.
>>
>> What are you actually trying to do that makes you think you need that
>> information? There might be an alternative approach.
>>
>> Cheers.
>>
>> Tim.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161115/be712167/attachment.html>