similar to: Upper case vs lower case in printed and parsed MIR

After playing a bit with the newly introduced hardware loop framework I realize that the llvm.set.loop.iterations intrinsic takes as argument the number of iterations the loop will execute. In fact it goes all the way to, on IR, insert an addition of constant 1 to the number of taken backedges returned by SCEV. If the machine instruction realizing the loop is interested in the number of

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

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

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

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!

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'

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

Fedor, Yes that is what happens in my case that the loop is fully unrolled and hence ‘removed’. My objection though is that there is still IR that could be dumped (i.e. the function containing the loop that was removed or the entire module) and that is what I want to have dumped after each pass when I specify -print-after-all. Of course there may be certain implementation details that could make

Hi, After dead-mi-elimination I'm experiencing a machine verifier failure at this virtual subregister write: %5.sub1 = COPY undef %11 The machine verifier essentially complains that the rest of the register is undefined (a subregister write implies a "read" of the other parts). So the problem is that dead-mi-elimination has removed the previously existing defines of %5.sub0.

On Fri, 2019-08-30 at 10:03 -0700, Quentin Colombet wrote: > > On Aug 30, 2019, at 8:31 AM, Jesper Antonsson via llvm-dev < > > llvm-dev at lists.llvm.org> wrote: > > > > Hi, > > > > After dead-mi-elimination I'm experiencing a machine verifier > > failure > > at this virtual subregister write: > > > > %5.sub1 = COPY undef

I'm working on getting an out of tree target machine verifier clean. This has found some nasty bugs so I'd like to continue with it. One instance of bad machine code is "Using an undefined physical register". This arises whenever undef propagates to a machine instruction. Usually this means the input was meaningless - e.g. call an undefined address. Other times it's a

Hi all, The CodeGen library is a big bag of interdependent bits. This caused a circular dependency in the MIR serialization commit (r237954), which got reverted in r238007. I propose separating the machine IR out of CodeGen and into its own MIR library, living at lib/MIR. This touches every target but it's mostly a mechanical change that renames the header files, although a couple of

Dear LLVM developers, My goal is to write LLVM Machine IR (MIR) passes to analyze the assembly source code. But it seems I need to find a way to translate the handwritten assembly code into MIR format first. Is there any materials, or any modules in LLVM source code, that can help to translate assembly code into LLVM MIR for analysis? Or is there any easier ways to analyze assembly code in MIR

The Loop Strength Reduction pass appears to break debug information even for the most basic input. I believe this is a well known issue already (see https://bugs.llvm.org/show_bug.cgi?id=38815) but I also believe that it deserve some extra attention. Consider the following input compiled with 'clang -g -O3 foo.c -mllvm -print-after-all' --- void foo(unsigned char *p) { #pragma clang loop

Hi, My name is Puyan and I've been exploring ways to improve the state of instruction level diffing using llvm and MIR. Below is a proposal for a new llvm tool meant to address issues encountered when diffing at the machine level. I'm eager to hear the community's feedback. Thanks PL mir-canon: A new tool for canonicalizing MIR for cleaner diffing. Problem Statement and

Llvm-mctoll will raise a binary back to LLVM IR. Not exactly what you want but it might be something you can leverage. https://github.com/microsoft/llvm-mctoll On Mon, Nov 25, 2019 at 1:19 PM Nicolai Hähnle via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Thu, Nov 21, 2019 at 3:37 AM Lele Ma via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > My goal is to write

In light (pun not intended) of the announcement here https://wiki.ubuntu.com/MirSpec what does this mean for LightDM being a viable free desktop display manager. The diagram shows the system compositor as being launched by LightDM in much the same way X is, and the plan looks very much like what we would do for Wayland. Is MIR going to be a hard dependency? Is Wayland support going to be dropped

Thank You. I have replaced all the occurrences of unsigned with uint64_t in Lanemask.h and in all other related files like codegenregisters.cpp, codegenregisters.h, MIParser.cpp etc... Also i changed Log2_32 to Log2_64 and replaced 4 with 8 in codegenregisters.cpp, but still getting the same error: error:Ran out of lanemask bits to represent subregister

> On May 26, 2015, at 1:37 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > >> >> On 2015-May-26, at 09:46, Alex L <arphaman at gmail.com> wrote: >> >> Hi all, >> >> The CodeGen library is a big bag of interdependent bits. This caused >> a circular dependency in the MIR serialization commit (r237954), which got >>

Hi all, After a recent upstream merge into our downstream sources we are suddenly encountering the freeze instruction in LLVM IR for div/rem pairs. This seems to be related to [1]. Our downstream target is GlobalISel only and unfortunately GlobalISel doesn't support this instruction yet, so most of our internal test-suite is now breaking due to GlobalISel not being able to translate this