I know finding a spare bit in MonoMethod is impossible :-)
On Tue, 2008-07-29 at 20:48 -0300, Rodrigo Kumpera wrote:
Other option is to kill the inline_info bit in MonoMethod and
use the space for a force_inline bit. inline_info can easily
be replaced by a hash table in mini.c. This would
Hi,
Massimiliano Mantione wrote:
IMHO, it is just easier to force inlining according to wrapper
type: IIRC we already force inlining of certain wrappers, so we
would not change the code logic that much.
And if there are two kinds of managed to managed wrappers,
one that must be forced
On Wed, 2008-07-30 at 09:19 +0200, Kornél Pál wrote:
I believe that there is no use to force managed-to-managed wrappers to
be inlined. I just would like to elminiate the code that prevents them
being inlined. If inlining is considered carefully (this should be the
case) then I don't think
Hi,
Massimiliano Mantione wrote:
The good news is that the current commit of the linear IR work
is the first step in getting a better JIT infrastructure so
that we can handle these things properly.
Thanks for the explanation about inlining. Now I understand that it's
even more complicated
Hi,
This patch replaces a small, fast, simple piece of code
in mono_emit_inst_for_method () with something far more complex. Also,
about replacing
icalls with generated IL code:
- the code to generate the icalls is usually much bigger and more
complex than the icall
itself.
- it replaces code
On Wed, Jul 30, 2008 at 4:08 AM, Massimiliano Mantione [EMAIL PROTECTED]wrote:
I know finding a spare bit in MonoMethod is impossible :-)
On Tue, 2008-07-29 at 20:48 -0300, Rodrigo Kumpera wrote:
Other option is to kill the inline_info bit in MonoMethod and
use the space for a
Hi Zoltan,
It's only doable to encode some very simple icalls with IL. I have the
feeling that
we get an order of magnitude code increase for going from C/C# to emitting
IL.
OTOH, for things like UnsafeAddrOfPinnedArrayElement, the code is so
straight
forward that gcc will hardly do much better
Hi,
Zoltan Varga wrote:
This patch replaces a small, fast, simple piece of code
in mono_emit_inst_for_method () with something far more complex. Also,
The three icall builders are reference implementations for demonstrating
what icall builders can do. I don't insist on OffsetToStringData
On 07/30/08 Kornél Pál wrote:
Zoltan Varga wrote:
This patch replaces a small, fast, simple piece of code
in mono_emit_inst_for_method () with something far more complex. Also,
The three icall builders are reference implementations for demonstrating
what icall builders can do. I don't
Paolo Molaro wrote:
If you propose a considerable amount of increased complexity and your
reference 'improvements' are actually a lot worse you should at least
choose better references to show.
My goal would be to make some icalls execute faster. Of course I don't
want to cripple the JIT. (I
Hi Kornél,
From your email the advantage of the patch is that by replacing some icalls
with managed code we would get rid of some managed-native transitions.
But there are some side effects:
-It makes the new full AOT mode a bit more complicated as these would be
another
kind of wrappers that
Hi,
Rodrigo Kumpera wrote:
From your email the advantage of the patch is that by replacing some icalls
with managed code we would get rid of some managed-native transitions.
The long term goal would be to replace all native icalls with managed
icalls (build by icall builders) that call no
On Tue, Jul 29, 2008 at 7:35 PM, Kornél Pál [EMAIL PROTECTED] wrote:
-For simple methods such as OffsetToStringData the method call overhead
might be a killer. We
should make sure that these new wrappers get a change to be inlined.
Currently it doesn't get inlined because the JIT has some
13 matches
Mail list logo
