Hello.
In order to detect a problem in the initial selection DAG creation that I have in my back end I need to output detailed debug info from the SelectionDAG.cpp module with all the TableGen records that are being processed, and compare between a working back end and my buggy back end.
I can debug by adding myself DEBUG() statements in the visit*() methods of the SelectionDAG.cpp module or by using GDB on this module.
Did anybody try a better way for debugging the selection DAG creation within the SelectionDAG.cpp module?
Thank you,
Alex
I think the “initial selection DAG” building process should be target independent. After that, there is DAG combining, legalization, instruction selection and scheduling all of which are at least partially target-dependent.
As far as TableGen records, the ones from your target should really only be consulted as part of instruction selection and scheduling as far as I’m aware. And the DAG instruction selector will actually output information about which record it is using for the match and if it does not match, it mentions the index where the match failed.
N
Hello.
Thank you for your comments.
I just realized that I wrote in the previous email SelectionDAG.cpp instead of SelectionDAGBuilder.cpp .
I managed to solve this issue by simply adding about 20 DEBUG() statements in the sensitive parts of SelectionDAGBuilder.cpp .
It turned out that the SelectionDAGBuilder class, responsible for creating the initial selection DAG, uses the TargetLoweringInfo class, which contains target dependent info like number and size of registers, parameter passing conventions, etc, resulting in eventual splitting of constant vectors to accommodate the width of the SIMD unit, etc.
Cardoso Lopes and Auler's "Getting started with LLVM core libraries" book talks in Chapter 6, (for example, page 150) about this.
Best regards,
Alex