> we need to discern what we want to achieve here. The goal might > be to prevent the vectorizer from performing peeling or versioning > for alignment. I realize the peeling code looks ugly but it's > actually for a good cause when the target does not support > misaligned vector access or only with severe penalty.
Vector spec says it should support element alignment, so my understanding is default behavior should be just aligned to vector-spec said :) I guess Ju-Zhe might have different thoughts on that, we might need some more comment from him. > So I'd much rather prefer that over the current approach as it > is more localized and will need an mtune-related approach later > anyway. I know there is some HW implementation that might be faster if the address is aligned to 128 bit or 256 bit, and some HW implementation might only get a few penalties from the first iteration if not aligned to some alignment. Anyway those are all mtune-related, so I guess eventually both riscv_builtin_vectorization_cost and riscv_vectorize_preferred_vector_alignment should get info from mtune. > > Regards > Robin
