[PATCH] D29678: [Tablegen/DAG Debug] - Instrumenting table gen DAGGenISelDAG to allow printing selected patterns(and their sources) during ISEL
Aditya Nandakumar via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Feb 10 13:35:30 PST 2017
aditya_nandakumar marked 16 inline comments as done.
aditya_nandakumar added a comment.
Will post the updated diff shortly.
================
Comment at: CMakeLists.txt:174
+option(DAG_PRINT_USED_ISEL_PATTERNS "Debug: Prints tablegen patterns that were used for selecting" OFF)
+if(DAG_PRINT_USED_ISEL_PATTERNS)
----------------
dsanders wrote:
> ab wrote:
> > I'd still prefix the name with 'LLVM_ENABLE_': it makes it easier to figure out where individual options come from in ccmake or CMakeCache.txt.
> >
> > Maybe LLVM_ENABLE_DAGISEL_COV or something?
> I had a similar comment typed but the name you suggest is better.
Thanks. That sounds much better than what I picked.
================
Comment at: CMakeLists.txt:176
+if(DAG_PRINT_USED_ISEL_PATTERNS)
+ set(LLVM_TBLGEN_DAG_FLAGS "-instrument-coverage")
+endif()
----------------
ab wrote:
> Maybe do this directly in TableGen.cmake, appending to LLVM_TABLEGEN_FLAGS? That way we don't need to change AArch64/CMakeLists.txt.
>
> In theory, we should only add it to -gen-dagisel invocation, but in practice, there's only one binary, so the flag will just be useless on the other invocations.
> You can fix that too by only adding -instrument-coverage to the flags inside tablegen(), only if ${ARGN} contains '-gen-dag-isel'.
Makes sense (I was initially hesitating to add to that function) . I'll go ahead and add this.
================
Comment at: include/llvm/CodeGen/SelectionDAGISel.h:218-226
+ /// getPatternForIndex - Patterns selected by tablegen during ISEL
+ virtual StringRef getPatternForIndex(unsigned index) {
+ llvm_unreachable("Tblgen should generate the implementation of this!");
+ }
+
+ /// getIncludePathForIndex - get the td source location of pattern instantiation
+ virtual StringRef getIncludePathForIndex(unsigned index) {
----------------
dsanders wrote:
> SelectionDAGISel is already abstract (because of Select()) so I think we should use make these pure virtual with '= 0'.
Currently Tablegen emits definitions for those two functions only when -instrument-coverage is passed in. This means if we make it pure virtual, then those two methods would be unimplemented by the <Target>DAGISels when -instrument-coverage is not passed in.
================
Comment at: utils/TableGen/DAGISelMatcherEmitter.cpp:68
+ auto It =
+ std::find(VecPatternsCovered.begin(), VecPatternsCovered.end(), P);
+ if (It == VecPatternsCovered.end()) {
----------------
ab wrote:
> dsanders wrote:
> > ab wrote:
> > > While this isn't a huge deal (because it's a debug feature), the complexity of std::find makes me twitchy.
> > >
> > > Maybe use a UniqueVector or std::lower_bound?
> > Do we really need to de-dupe them? I wouldn't expect there to be duplicates since this indicates redundant patterns in the tablegen files and the MatcherTable entries for one of them will be unreachable.
> You're absolutely right, seems like this should just be a vector.
The problem I saw was that EmitMatcherList was called several times (since we need child and offset of failure code before emitting either of them, they buffer the output to a temporary string). I noticed w/o deduplication - the same patterns show up several times.
Not sure if lower_bound will work as ordering by '<' for strings seem weird?
There's no reason to use pair currently - I'll just create the concatenated strings directly and have a vector<string>
Repository:
rL LLVM
https://reviews.llvm.org/D29678
More information about the llvm-commits
mailing list