[PATCH] D134453: Introduce the `AlwaysIncludeTypeForNonTypeTemplateArgument` into printing policy

[Nenad Mikša via Phabricator via cfe-commits]

DoDoENT added a comment.

> Right - I'm trying to understand what your overall goals are and what clang needs to facilitate them, if it's suitable to do so. And it seems to me that the right way to support them, is for your approach to change - not to rely on the type printing to communicate certain information, but to use the AST to get the information you need (& if you want to encode that in a string, that's up to you - I'd suggest encoding it in some more semantic data structure (a struct, with variables, lists/vectors, etc, describing the properties you want - so you don't have to rely on what clang does/doesn't include in the text and have to parse that information out of the text later on with your own home-grown C++ type parsing code, I guess)).

I've got a machine-generated c++ function in the form:

  c++
  template< typename Pixel >
  auto processImage( Image< Pixel > const & input )
  {
      auto result0{ processor.step1( input ) };
      auto result1{ processor.step2( result0 ) };
      ...
      auto resultN{ processor.stepNplus1( resultNminus1, resultK, resultM, ... ) }; // for K, M, ... < N - 1
      return resultN;
  }

The `processor` is a graph processor that has steps that perform node computations (imagine it as neural network layers in machine learning inference).

Now, this works fine, but produces unnecessarily large binary, as types of most results don't depend on the `Pixel` template, but get instantiated anyway, thus making both binary larger and source slower to compile.

The idea of my tool is to use a clang to obtain concrete types of every `result0, result1, ..., resultN` and then decide whether its type depends on `Pixel` or not. Then use that information to cut the function into two functions - one that contains part of processing that depends on `Pixel` and the one that does not. The one that does not will be a normal function, while the one that does will remain in the function template and will call to the other after performing part of processing that depends on `Pixel`.

So, my idea is to obtain the types of each result as strings and then simply search for the keyword "Pixel"` in those strings to classify each result type. This approach works pretty well with my patch. Also, I find that much easier than navigating the AST.

But in general, you both are right - this tool could possibly be implemented differently and probably will in the future.

Now, let's keep our focus on verbosity in the diagnostic outputs, as this was the main reason I contributed this patch back to the upstream LLVM.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134453/new/

https://reviews.llvm.org/D134453