ABataev added a comment. In D108826#2969594 <https://reviews.llvm.org/D108826#2969594>, @lebedev.ri wrote:
> In D108826#2969547 <https://reviews.llvm.org/D108826#2969547>, @ABataev wrote: > >> In D108826#2969471 <https://reviews.llvm.org/D108826#2969471>, @lebedev.ri >> wrote: >> >>> I think there is something really wrong with vectorzer passes in LTO >>> pipelines. >>> Can you say whether the problem you are observing is in ThinLTO, Full LTO, >>> or both? >> >> I saw it in Full LTO but suppose we have a similar problem in ThinLTO. SLP >> vectorizer at compile-time tries to vectorize using small vectors at it may >> affect other optimizations at link time (e.g. after inlining we may try to >> vectorize using large vector sizes etc.). This is just a preliminary attempt >> to see how can we fix this early optimization in SLP. > > Aha, so full lto. That is consistent with the phase ordering dilemma @spatel > discovered: D102002 <https://reviews.llvm.org/D102002> Aha, do I understand correctly that he tries to add a flag(s) that we have a compile without LTO, compile at LTO and link at LTO? Or something else? Or he just tries to reorder passes depending whether we're in LTO or not in LTO? > IMO workarounding it in the pass isn't the right course of action. Such > workarounds tend to stick around. I agree, I thought about a pipeline fix, this is just a temp solution to check how it affects the performance. It gets important especially for upcoming non-power-2 vectorization, which may cause regressions with LTO. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D108826/new/ https://reviews.llvm.org/D108826 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
