```
$ benchmark-driver -v --rbenv 'before --jit;after --jit' --repeat-count=12 --alternate --output=all benchmark.yml
before --jit: ruby 3.0.0dev (2020-12-17T06:17:46Z master 3b4d698e0b) +JIT [x86_64-linux]
after --jit: ruby 3.0.0dev (2020-12-17T07:01:48Z master 843abb96f0) +JIT [x86_64-linux]
last_commit=Lazily move PC with RUBY_VM_CHECK_INTS
Calculating -------------------------------------
                                 before --jit           after --jit
Optcarrot Lan_Master.nes    80.29343646660429     83.15779723251525 fps
                            82.26755637885149     85.50197941326810
                            83.50682959728820     88.14657804306270
                            85.01236533133049     88.78201988978667
                            87.81799334561326     88.94841008936447
                            87.88228562393064     89.37925215601926
                            88.06695585889995     89.86143277214475
                            88.84730834922165     90.00773346420887
                            90.46317871213088     90.82603371104014
                            90.96308347148916     91.29797694822179
                            90.97945938504556     91.31086331868738
                            91.57127890154500     91.49949184318844
```

Use ID instead of GENTRY for gvars.

Global variables are compiled into GENTRY (a pointer to struct
rb_global_entry). This patch replace this GENTRY to ID and
make the code simple.

We need to search GENTRY from ID every time (st_lookup), so
additional overhead will be introduced.
However, the performance of accessing global variables is not
important now a day and this simplicity helps Ractor development.

This commit introduces an "inline ivar cache" struct.  The reason we
need this is so compaction can differentiate from an ivar cache and a
regular inline cache.  Regular inline caches contain references to
`VALUE` and ivar caches just contain references to the ivar index.  With
this new struct we can easily update references for inline caches (but
not inline var caches as they just contain an int)

Support loading builtin features written in Ruby, which implement
with C builtin functions.
[Feature #16254]

Several features:

(1) Load .rb file at boottime with native binary.

Now, prelude.rb is loaded at boottime. However, this file is contained
into the interpreter as a text format and we need to compile it.
This patch contains a feature to load from binary format.

(2) __builtin_func() in Ruby call func() written in C.

In Ruby file, we can write `__builtin_func()` like method call.
However this is not a method call, but special syntax to call
a function `func()` written in C. C functions should be defined
in a file (same compile unit) which load this .rb file.

Functions (`func` in above example) should be defined with
  (a) 1st parameter: rb_execution_context_t *ec
  (b) rest parameters (0 to 15).
  (c) VALUE return type.
This is very similar requirements for functions used by
rb_define_method(), however `rb_execution_context_t *ec`
is new requirement.

(3) automatic C code generation from .rb files.

tool/mk_builtin_loader.rb creates a C code to load .rb files
needed by miniruby and ruby command. This script is run by
BASERUBY, so *.rb should be written in BASERUBY compatbile
syntax. This script load a .rb file and find all of __builtin_
prefix method calls, and generate a part of C code to export
functions.

tool/mk_builtin_binary.rb creates a C code which contains
binary compiled Ruby files needed by ruby command.

To perform a regular method call, the VM needs two structs,
`rb_call_info` and `rb_call_cache`. At the moment, we allocate these two
structures in separate buffers. In the worst case, the CPU needs to read
4 cache lines to complete a method call. Putting the two structures
together reduces the maximum number of cache line reads to 2.

Combining the structures also saves 8 bytes per call site as the current
layout uses separate two pointers for the call info and the call cache.
This saves about 2 MiB on Discourse.

This change improves the Optcarrot benchmark at least 3%. For more
details, see attached bugs.ruby-lang.org ticket.

Complications:
 - A new instruction attribute `comptime_sp_inc` is introduced to
 calculate SP increase at compile time without using call caches. At
 compile time, a `TS_CALLDATA` operand points to a call info struct, but
 at runtime, the same operand points to a call data struct. Instruction
 that explicitly define `sp_inc` also need to define `comptime_sp_inc`.
 - MJIT code for copying call cache becomes slightly more complicated.
 - This changes the bytecode format, which might break existing tools.

[Misc #16258]

This changeset modifies the VM generator so that vm.inc is written in
C99.  Also added some comments in _insn_entry.erb so that the
intention of each parts to be made more clear.  I think this improves
overall readability of the generated VM.

Confirmed that the exact same binary is generated before/after this
changeset.


git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66923 b2dd03c8-39d4-4d8f-98ff-823fe69b080e

These settings are now covered by .dir-locals.el.


git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66584 b2dd03c8-39d4-4d8f-98ff-823fe69b080e

The idea behind this commit is that handles_sp and leaf are two
concepts that are not mutually independent.  By making one explicitly
depend another, we can reduces the number of lines of codes written,
thus making things concise.


git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65426 b2dd03c8-39d4-4d8f-98ff-823fe69b080e

This enhances stability of the generated source code (namely
insns_info.inc) across attribute insertion / deletion.  It does
not change the compiled binary at all; just a bit of readability.


git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65425 b2dd03c8-39d4-4d8f-98ff-823fe69b080e

This is mostly cosmetic.  Should generate a slightly readable
vm.inc output.


git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64709 b2dd03c8-39d4-4d8f-98ff-823fe69b080e