llvm dev - Jun 2017 - Is every intrinsic norecurse?

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/7b8b9574/attachment.html>

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>

On 06/04/2017 05:29 PM, Piotr Padlewski wrote:
> 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.
I'm not sure that it is a universal property of all intrinsics, strictly 
speaking. patchpoints, for example, might recurse? It is certainly true 
for most of them.

  -Hal
>
> Best
> Piotr
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

On Sun, Jun 4, 2017 at 7:16 PM, Hal Finkel <hfinkel at anl.gov>
wrote:
> I'm not sure that it is a universal property of all intrinsics,
strictly
> speaking. patchpoints, for example, might recurse? It is certainly true for
> most of them.
Yes, patchpoints and statepoints may recurse.  For instance

void f() {
  llvm.patchpoint(&f);
}

has "mutual recursion" between the patchpoint intrinsic and f.

-- Sanjoy