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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
