0

I have code with #pragma clang loop vectorize(enable), which enforces vectorization. For some types, this vectorization is not possible - example:

#include <string>
#include <vector>

template <typename T>
void double_entries(std::vector<T>& vec) {
    #pragma clang loop vectorize(enable)
    for (auto i = 0; i < 100; ++i) vec[i] = vec[i] + vec[i];
}

int main() {
    auto char_vector = std::vector<char>{100};
    auto string_vector = std::vector<std::string>{100};

    double_entries(char_vector);
    double_entries(string_vector);
}

https://godbolt.org/z/EgiogQ

Clang gives me a warning about that:

<source>:7:2: warning: loop not vectorized: failed explicitly specified loop vectorization [-Wpass-failed=loop-vectorize]

        for (auto i = 0; i < 100; ++i) vec[i] = vec[i] + vec[i];

        ^

This doesn't really help if I don't know that the std::string initialization of double_entries is causing the problem.

Is there any way I can get clang to print all involved template instantiations? Once I can identify the problematic types using that compiler output, I can simply disable vectorization for those.

mrks
  • 8,033
  • 1
  • 33
  • 62
  • Is the error not preceded by "In function templatename", where one of args is clearly a string? – Gem Taylor Oct 19 '18 at 18:17
  • The way to fix this in c++11 and going forward is to add restriction conditions in your template arguments, so the call site generates an error. This link is a simple example that restricts the type to arithmetic: https://stackoverflow.com/questions/44848011/c-limit-template-type-to-numbers – Gem Taylor Oct 19 '18 at 18:19
  • The output above is everything that clang emits. In the actual code, we already have conditionals that restrict the vectorization to the appropriate types, however, this sometimes does not work (e.g., uint16_t can be vectorized, uint8_t). The question is more how to *identify* the cases that do not work, not how to handle them once we know what types are problematic. – mrks Oct 19 '18 at 18:21
  • Upgrade your clang, perhaps? I get so much info back from template issues that it is often difficult to spot the /actual/ error message. – Gem Taylor Oct 19 '18 at 18:24
  • Clearly this template does not have a restriction. Perhaps your policy should be to add a basic one, then look at the reported callsite, then consider if the restriction needs to be widened or the callsite is wrong. – Gem Taylor Oct 19 '18 at 18:51
  • About updating clang: The godbolt link uses clang trunk. I am not sure if I understand your second comment. Are you suggesting experimentally limiting/widening the allowed vectorizations? That is what I am doing right now, but it would save a lot of time if I could get the same detailed error message that I usually get with template-related problems. – mrks Oct 19 '18 at 20:36
  • Yes, I'm suggesting tightening the template arguments, and then examining the callsites that fail the tightening. If any of them are acceptable, then weaken. To be honest, though template error handling is better than macro handling it is often still not perfect. – Gem Taylor Oct 22 '18 at 10:12

0 Answers0