You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Without vector, extractelement/insertelement with non-constant index can be very costly.
This was factored into the cost model in #67334
However, in the case of full canonical loop unrolling and the index being the induction variable, the index will be constant, but is not at the time of estimating the cost of unrolling the loop.
Without vector, extractelement/insertelement with non-constant index can be very costly.
This was factored into the cost model in https://github.com//pull/67334
However, in the case of full canonical loop unrolling and the index being the induction variable, the index will be constant, but is not at the time of estimating the cost of unrolling the loop.
This wouldn't fix the general problem, but at least for the kind of example you shared (simple vector initialisation expressed using a loop), I wonder if it would make sense to do something in LoopIdiomRecognize to detect that pattern and replace the loop with logic that sets a constant vec value.
Without vector, extractelement/insertelement with non-constant index can be very costly.
This was factored into the cost model in #67334
However, in the case of full canonical loop unrolling and the index being the induction variable, the index will be constant, but is not at the time of estimating the cost of unrolling the loop.
Example before and after this change: (llvm 17 vs 18)
https://compiler-explorer.com/z/Mh6eWKjr7
I had a go at fixing this myself, but could not see a good fix. I ended up abusing ephemeral values that get passed into UnrollCostEstimator.
The text was updated successfully, but these errors were encountered: