When modifying IR for the purpose of a unit test (e.g., in https://github.com/llvm/llvm-project/tree/main/llvm/test/Transforms/SROA), the IR generated by OPT may have metadata that’s not used by the tested pass.
Are there some general suggestions on how to strip metadata? Is this mostly empirical by analyzing how the metadata takes effect in the e2e compiling process (i.e., outside of one pass)? Any form of pointers / related threads in the past would be enlightening!
From this perspective stripping unused metadata manually could be error prone (e.g., for a more complex IR, or a test IR consisting of 10+ functions).
Thanks for the pointer!
I’m a little confused how the custom script (specified by –test arg) tells llvm-reduce if something is interesting in the IR.
Is it a common practice to wrap “llvm-lit ” into a shell script to simplify IR for a unit test?
Yes, it is expected that you write your own "interesting-ness" script.
However I don't think you can use llvm-lit (which requires a `RUN:`
command comment in the file that llvm-reduce does not emit). Instead,
take the command that llvm-lit would execute (Execute with -v flag)
and instead of the test file (%s in the `RUN: ` command), pass $1 to
the opt/llc executable within your script. Check whether it has failed
I usually end up writing a short bash script which runs
path/to/opt $@ -foo |& grep 'the error/assert message' and use that as the interestingness test
Got the points that wrapping “path/to/opt” or other commands in a shell works.
In the first few attempts I already get empty IR output (when
llvm-lit test.ll passed).
Now I think it’s intended possibly because
llvm-reduce helps to reduce code size and highlight code blocks when IR doesn’t work as intended (e.g…crashes).
So I should define what’s interesting (important instructions) for a IR that passes the unit test.