[PATCH] D77632: [TLI] Per-function fveclib for math library used for vectorization

Sat Apr 11 12:15:26 PDT 2020

wenlei added a comment.

In D77632#1974409 <https://reviews.llvm.org/D77632#1974409>, @tejohnson wrote:

> In D77632#1974363 <https://reviews.llvm.org/D77632#1974363>, @wenlei wrote:
>
> > In D77632#1974015 <https://reviews.llvm.org/D77632#1974015>, @nikic wrote:
> >
> > > This change causes a ~0.5% compile-time regressions: http://llvm-compile-time-tracker.com/compare.php?from=5b18b6e9a84d985c0a907009fb71de7c1943bc88&to=60c642e74be6af86906d9f3d982728be7bd4329f&stat=instructions This is quite a lot as these things go, so it would be great if you could double check if there's any optimization potential here. In particular I'm wondering why this affects normal builds so much, even though they (presumably?) don't use any veclib at all.
> >
> >
> > Thanks for the heads-up. This is surprising but there is a change even when veclib is not used - in order to allow each function to use different veclib without duplicating the work of populating vector function list for each function, we now always pre-populate vector function list for three supported vector libraries for each module. However 0.5% compile-time for that work given it's per-module is not expected. I suspect we may be passing/copying TLII around more than we anticipated (now we always have more stuff to copy). I will take a look. We could also turn this into a lazy initialization - only populate the needed list for module level TLII when it's first queried by a function level TLI.
>
>
> Hmm, yeah that is surprising, because the TLII should be built once per module per TLI analysis, which is never invalidated. We've gone from populating one set of vec libs to 3, I wouldn't have thought that was particularly expensive, so it would be good to see what is going on here and confirm we are only building this once as expected.
>
> Looking at the compile time data at that link, interestingly the "instructions" metric increased, but not wall time or cycles or task clock - they were all neutral.

Turns out there're a few places where we call copy ctor for TLI unnecessarily. Made some changes in D77952 <https://reviews.llvm.org/D77952> to use move when possible. In addition, I should have used move for `TLI.VecLibDescs` in move ctor of `TargetLibraryInfoImpl` too.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77632