Hi, 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, Thomas ** 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<http://www.graphcore.ai/privacy> ** 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191023/c56dd52d/attachment.html>
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. -Troy ________________________________ From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Thomas Preud'homme via llvm-dev <llvm-dev at lists.llvm.org> Sent: Tuesday, October 22, 2019 9:01 PM To: llvm-dev <llvm-dev at lists.llvm.org> Subject: [llvm-dev] FileCheck wishlist Hi, 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, Thomas ** 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<http://www.graphcore.ai/privacy> ** 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191023/cdfa5ad0/attachment.html>
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, Thomas ________________________________ From: Troy Johnson <troyj at cray.com> Sent: 23 October 2019 16:28 To: llvm-dev <llvm-dev at lists.llvm.org>; Thomas Preud'homme <thomasp at graphcore.ai> Subject: Re: FileCheck wishlist 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. -Troy ________________________________ From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Thomas Preud'homme via llvm-dev <llvm-dev at lists.llvm.org> Sent: Tuesday, October 22, 2019 9:01 PM To: llvm-dev <llvm-dev at lists.llvm.org> Subject: [llvm-dev] FileCheck wishlist Hi, 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, Thomas ** 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<http://www.graphcore.ai/privacy> ** 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. ** 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<http://www.graphcore.ai/privacy> ** 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191024/849dd7cf/attachment.html>
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.
2) 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,
Thomas
________________________________
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Thomas
Preud'homme via llvm-dev <llvm-dev at lists.llvm.org>
Sent: 23 October 2019 03:01
To: llvm-dev <llvm-dev at lists.llvm.org>
Subject: [llvm-dev] FileCheck wishlist
[This message was sent from somebody outside of your organisation]
Hi,
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,
Thomas
** 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<http://www.graphcore.ai/privacy> **
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191106/38ca2e0e/attachment.html>
Reasonably Related Threads
- [RFC][FileCheck] New option to negate check patterns
- [RFC][FileCheck] New option to negate check patterns
- FileCheck: using numeric variable defined on same line with caveats
- [RFC][FileCheck] New option to negate check patterns
- ICE in release/9.x when using LLVM_ENABLE_MODULES