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

[Wenlei He via Phabricator via cfe-commits]

wenlei added a comment.

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.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77632