[llvm-dev] MIR YAML deserialisation failure

Thu Mar 22 02:15:17 PDT 2018

In our fork of LLVM we often need to reduce a crash testcase for a
specific assertion. After writing lots of "only give me this specific
assertion" scripts like the above I decided to write a script that
automates all this for me:
<https://github.com/CTSRD-CHERI/clang/blob/master/utils/creduce_crash_testcase.py>.
(It's called creduce_crash_test.py but it will actually use bugpoint
-compile-custom if it detects that it is not a clang frontend crash).
If you point the script at a clang crash reproducer .sh file it will
infer the assertion message/llvm_unreachable/infinite loop (if it
takes longer than x seconds it treats it as an infinite loop) and then
try to produce a reduced test case for that issue. If you point it at
a non.sh file it will parse that file for RUN: lines and try to reduce
the crashes it finds there. It currently handles RUN: lines containing
llc or %clang/%clang_cc1 and our custom lit substitutions.

If people are interested in this I'm very happy to try and submit this upstream.

On 20 March 2018 at 16:52, Nemanja Ivanovic via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> I'm not sure if this helps, but here it is in case it does.
>
> I typically use bugpoint in a way as to keep the actual failure that I'm
> after. For example, with the test case you've pasted, I was looking for a
> specific assert. So I used bugpoint this way:
>
> $ cat reduceme.sh
> #!/bin/bash
> llc -filetype=obj $1 2>&1 | grep 'Cannot lower calls with arbitrary operand
> bundles'
> RC=$?
> if [[ $RC -eq 0 ]]
> then
>   exit 1
> fi
> exit 0
>
> $ bugpoint -compile-custom -compile-command=$PWD/reduceme.sh input.ll
>
> That will ensure that bugpoint retains the specific desired failure
> behaviour as it is reducing the test case.
>
> Hope that helps,
> Nemanja
>
> P.S. It is not that I am specifically interested in that assert - just that
> that's how the original test case was failing so that's what I wanted to
> preserve as an illustration.
>
> On Tue, Mar 20, 2018 at 11:14 AM, Valentin Churavy <v.churavy at gmail.com>
> wrote:
>>
>> Thank you both!
>>
>> I was running into the issue that bugpoint was reducing my test-case into
>> other failures and I hadn't managed yet to find the right point in the Julia
>> pass pipeline to insert the module to reproduce the issue reliably from llc
>> and that's why I started looking at using the MIR.
>>
>> I will go back at looking at the pass pipeline and the IR and get a
>> reproducer that way!
>>
>> Thanks,
>> Valentin
>>
>> On Tue, 20 Mar 2018 at 07:51 Nemanja Ivanovic <nemanja.i.ibm at gmail.com>
>> wrote:
>>>
>>> Valentin,
>>> in terms of limitations as Sean pointed out, an important one is that
>>> .mir doesn't have MachineFunctionInfo which may result in failure on
>>> accesses to global variables due to use of register X2. The verifier
>>> considers it an undefined register.
>>> Also, it's probably easier to reduce test cases using bugpoint starting
>>> from an IR test case. With the code you provided, I get a different crash
>>> than what you apparently get. Here are the test case and the backtrace.
>>>
>>> Test case: https://pastebin.com/fxjRtJD0
>>> Backtrace: https://pastebin.com/FsXMvbGK
>>>
>>> Nemanja
>>>
>>> On Mon, Mar 19, 2018 at 11:51 PM, Sean Fertile via llvm-dev
>>> <llvm-dev at lists.llvm.org> wrote:
>>>>
>>>> Hello Valentin,
>>>>
>>>> To generate a mir test case i think the process is to first create an IR
>>>> file by passing '-S -emit-llvm' to clang, then you can feed that file into
>>>> llc and use stop-before to get the mir just before the if-converter pass,
>>>> eg: `llc -stop-before=if-converter  -simplify-mir -o test.mir test.ll`.
>>>>
>>>> Also there is a MIR language reference:
>>>> https://llvm.org/docs/MIRLangRef.html which has some of the limitations
>>>> documented, as well as tips for further simplifying the generated mir if
>>>> need be.
>>>>
>>>> Regards,
>>>> Sean
>>>>
>>>> On Mon, Mar 19, 2018 at 7:53 PM, Valentin Churavy via llvm-dev
>>>> <llvm-dev at lists.llvm.org> wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> I am trying to isolate an assertion failure in if-converter (on PPC)
>>>>> and I generated a textual debuglog with:
>>>>>
>>>>> ```
>>>>> LLVM_ARGS=-print-before-all -print-module-scope
>>>>> -filter-print-funcs=japi1__require_7687
>>>>> ```
>>>>>
>>>>> and after splicing out the the MIR before the if-converter pass
>>>>> I would like to run `llc -march=ppc64le -run-pass=if-converter
>>>>> input.mir` so that I can start minimising the MIR.
>>>>>
>>>>> This steps fails for me with a:
>>>>> ```
>>>>> error: YAML:188:20: Unrecognized character while tokenizing.
>>>>> Function Live Ins: %x4
>>>>>                    ^
>>>>>
>>>>> error: YAML:188:1: Map value must not be empty
>>>>> Function Live Ins: %x4
>>>>> ^~~~~~~~~~~~~~~~~
>>>>> ```
>>>>>
>>>>> Should I expect this to work, or is some part of my workflow wrong?
>>>>>
>>>>> I put the full log and just the extracted MIR file online:
>>>>> https://drive.google.com/open?id=1Br0s9Qvr4tzPv8nqbnV_nWezpEH5Ci7B and
>>>>> would appreciate any guidance whether I should file this as a deserialiser
>>>>> bug.
>>>>>
>>>>> Best,
>>>>> Valentin
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> LLVM Developers mailing list
>>>>> llvm-dev at lists.llvm.org
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>
>>>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>