[llvm-dev] Is every intrinsic norecurse?
Piotr Padlewski via llvm-dev
llvm-dev at lists.llvm.org
Sun Jun 4 16:51:04 PDT 2017
To bring some statistics:
Number of functions marked as norecurse:
name before after delta%
LLVM normal 1252902 1400128 10.52%
LLVM devirtualization 1231893 1400129 12.02%
ChakraCore normal 181366 257878 29.67%
ChakraCore with devirtualization 164891 257893 36.06%
where:
normal is Release build,
devirtualization is Relase + -fstrict-vtable-pointers
before is what it is right now
after is how it is after marking every intrinsic with norecurse
As you can see we could mark from 10-40% more functions as norecurse if all
of the intrinsics would be marked norecurse.
Let's look at other numbers to see if it actually helps in optimizations:
Number of global variables removed
name before after delta%
LLVM normal 932 1344 30.65%
LLVM devirtualization 1206 1621 25.6%
ChakraCore normal 1060 1060 0%
ChakraCore devirtualization 1072 1072 0%
For ChakraCore it didn't all statistics besides # of functions marked as
norecurse didn't change.
2017-06-05 0:29 GMT+02:00 Piotr Padlewski <piotr.padlewski at gmail.com>:
> Hi folks,
> I've been measuring some devirtualization statistics and I found that when
> barriers are introduced, the number of functions marked as norecurse is
> lower.
> The llvm.group.barrier is obviously norecursive and I've been thinking: is
> every intrinsic norecurse?
>
> I think it make sense to mark all of the intrinsics that can be considered
> as norecursive this way, so it won't gonna stop the optimizer marking
> functions as norecurse.
>
> Best
> Piotr
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170605/a5968a78/attachment.html>
More information about the llvm-dev
mailing list