[llvm-dev] Advice on creating tests for > 64 bit mul on X86

[Riyaz Puthiyapurayil via llvm-dev]

Background:
In a 32-bit build of our software, we ran into the same issue reported in https://bugs.llvm.org/show_bug.cgi?id=20871/ __multi3 which is a 128 bit multiply has no definition in 32-bit in either compiler-rt or libgcc. The root cause of the above issue is that licm and indvars generated multiply instructions that got promoted to i128. But I don't if we want to introduce target dependent checks to disable these optimizations. See https://reviews.llvm.org/D38668 for a possible fix of this issue which activates existing code in the legalizer (SelectionDAG) to generate brute force multiplication code for wide integers.

Problem:
There are existing lit tests under X86 that currently generate __multi3 for 32-bit target (these would of course never link and run). The tests just check for assembly match (the checks are auto generated by utils/update_llc_test_checks.py). The problem is that these tests have 128, 256, 512 and 1024 bit multiplication instructions and now this results in a lot of X86 code. There is no way one can manually verify whether these auto generated checks are correct. I wrote a test program to generate random test vectors with results verified using the unix 'bc' utility. I loaded these vectors into arrays and then invoked the functions in the lit tests. With this, I have verified that the assembly generated is in fact correct. I can now safely update the tests with new checks. But... the next time, someone has to update these tests, they would have to go through the same process which I think is just too much work.

Any suggestions? In general, how does one check that update_llc_test_checks.py produces the correct checks if the generated code is significantly different as in the case above? The previous version of llc is of no help unless the diff is very simple that can be visually verified.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171013/37ae5b0c/attachment.html>