llvm dev - Oct 2017 - Advice on creating tests for > 64 bit mul on X86

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>