[PATCH] D102002: [PassManager] unify vector passes between regular and LTO pipelines

Roman Lebedev via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sat May 8 06:32:11 PDT 2021


lebedev.ri added a comment.

In D102002#2745399 <https://reviews.llvm.org/D102002#2745399>, @lebedev.ri wrote:

> In D102002#2744200 <https://reviews.llvm.org/D102002#2744200>, @spatel wrote:
>
>> In D102002#2742902 <https://reviews.llvm.org/D102002#2742902>, @dmgreen wrote:
>>
>>> Without a lot of evidence that this is better across a range of architectures, I would recommend trying to be conservative, taking things a step at a time.
>>> We have one test where this patch would make it 88% worse. That might be a pathological case but no one is going to put up with on tenth of the speed :-)
>>
>> Agreed - I should try to move the LTO variations to be more like the regular pipeline in small steps. 
>> I'm curious if we can already see the big slowdown when compiling with "-flto" then?
>
>
>
>> Similarly for the rawspeed benchmark shown by @lebedev.ri - does the reduction in SLP vectorization show up when compiling with -flto independently of this patch?
>
> Eh, i would love to tell :) As i've just discovered, apparently some weird miscompile was introduced post-clang-12,
> so i can't run the benchmark. I guess i'll have to bisect it first.
> I can not tell if it is in X86 backend, or in a middle-end opt passes.

Ok, dealt with that in rG1acd9a1a29ac30044ecefb6613485d5d168f66ca <https://reviews.llvm.org/rG1acd9a1a29ac30044ecefb6613485d5d168f66ca>.

As far as i can tell, on that codepath, current ThinLTO build does not exhibit the same slowdown as does the plain build with this patch.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D102002/new/

https://reviews.llvm.org/D102002



More information about the llvm-commits mailing list