FileCheck wishlist


I’m looking for some feedback on pain points people have with FileCheck in terms of missing features to help people interested in working on FileCheck to prioritize the work accordingly. I am personally interested in improving FileCheck on 2 issues whenever time permits it:

  • being able to test for consecutive lines in arbitrary order, i.e. something akin to CHECK-DAG blocks where all lines matched are consecutive

  • DAG regions to be able to look for sequences of code that can be interleaved, which would be useful to check for register dependencies accross several operands, e.g. allowing all valid interleaving of instructions in the following sequence:

    load rA, [rT]
    load rB, [rX]
    load rC, [rY]
    load rD, [rZ]
    mul rF, rA, rB
    mul rG, rC, rD
    add rH, rF, rG

I would therefore like to be able to define two sequences each composed of 2 loads in any order (thus using the solution for the first issue) followed by a mul that can be interleaved between each other which are followed by an add.

Do people have any other wishlist item? I propose to compile a list of all suggestions and do a poll to get an idea of what features seems to be the most wanted. This can then be used by whoever is interested in contributed to FileCheck to maximize the impact of their contribution, myself included.

Best regards,


** We have updated our privacy policy, which contains important information about how we collect and process your personal data. To read the policy, please click here **

This email and its attachments are intended solely for the addressed recipients and may contain confidential or legally privileged information.
If you are not the intended recipient you must not copy, distribute or disseminate this email in any way; to do so may be unlawful.

Any personal data/special category personal data herein are processed in accordance with UK data protection legislation.
All associated feasible security measures are in place. Further details are available from the Privacy Notice on the website and/or from the Company.

Graphcore Limited (registered in England and Wales with registration number 10185006) is registered at 107 Cheapside, London, UK, EC2V 6DN.
This message was scanned for viruses upon transmission. However Graphcore accepts no liability for any such transmission.

Maybe this already exists and I just don’t know about it, but I find it tedious to repeat the same regex throughout a test and across multiple tests. Case in point something like [[REG0:%[a-z0-9]+]], [[REG1:%[a-z0-9]+]], etc. when matching larger patterns. So I’ve wished that FileCheck regex had something predefined for situations like that, like a normal regex has \w, or had a config file somewhere to allow defining new ones.


Interesting, I did think about something similar at some point but for numeric variable to be able to search for a subset of numerical values (e.g. 0-15 for a target with 16 registers for instance).

Thanks for the suggestion. Best regards,


I’ve remembered another two other features I wished for recently.

  1. The first one is forward variable reference. This would allow to match loops, e.g.

CHECK: [[LOOPLABEL:.[[:alpha:]][[:alnum:]]*]]
(…) // CHECK-NEXT for instructions in the loop

CHECK: bne $r0 [[LOOPLABEL]]

This would require variable names to not be redefinable which I think would be a good default at least within a CHECK-LABEL block to make test clearer and unambiguous.

  1. The second feature is the ability to use variables in regular expressions. This allows to check for instructions that could either take an immediate or reuse a register that has the right value when both are acceptable approaches:

CHECK: add r0, {{(18|[[REG]])}}

The problem is how to encode this in the syntax since that would deviate from the posix regex syntax. That would probably mean using a different syntax than {{}} to indicate the use of that extended regex syntax.

A potential follow-up which I’ve never needed personally but I can see the use for is optional CHECK which would allow to write:

CHECK-OPT: mov [[REG:r[0-9]+]], 18
CHECK: add r0, {{(18|[[REG]])}}

to allow to check for an addition with a constant which is either loaded into a register or encoded in an immediate field. This could be useful if the add with immediate is a bigger encoding than the register version in which case the immediate makes sense in case of single use of the value and the register is better in case of multiple use. As I said, this optional CHECK is not a feature I’ve personally needed, so it’s not on my wishlist.

Best regards,