On Tue, 13 May 2025, Eric Botcazou wrote: > > In PR116140 it was brought up that adding pragma GCC unroll in std::find > > makes it so that you can't use a larger unroll factor if you wanted to. > > This is because the value can't be overriden by the other unrolling flags > > such as -funroll-loops. > > What about letting -funroll-loops either augment or use a multiple of the > specified factor?
I'm adding my general comment here. While I think it's reasonable to honor a #pramga unroll during vectorization by trying to adjust the vectorization factor to the suggested unroll factor, adjusting the "remaining" (forced) unroll is probably not always desired, expected or good. In absence of #pragma unroll the loop unroller has heuristics that might want to incorporate whether a loop was already unrolled from original scalar, but the heuristics should work independent of that. This is especially true in the context of complete unrolling in cunroll, not so much about the RTL unroller which lacks any good heuristics. The current #pragma unroll is a force thing originally invented to guide the RTL unroller when it is disabled (as it is by default). That it is effectively a "force exact value" is a side-effect of the lack of any different behavior there (before the #pramga it would unroll by 8, always). IMO there's not enough reason to complicate the tunable, much less by "weak" attributes like requested vs. preferred. I'd rather allow #pragma GCC unroll without a specific unroll factor to suggest GCC should enable unrolling for this loop, but according to heuristics, rather than to a fixed amount (that would be your "preferred" I guess). Richard.
