[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%

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