[Mono-dev] inlining and performance of SIMD code

[Rodrigo Kumpera]

On Tue, Oct 20, 2009 at 2:10 PM, Erven Rohou <erven.rohou at inria.fr> wrote:

> Hello,
>
> I have a few questions about inlining:
>
> - I am curious what the heuristics are. I looked at the function
> mono_method_check_inlining, but even when the function returns TRUE, the
> function might not be inlined. Could you point me the relevant piece of
> code? Is
> there any high level rule to make a guess, like complex control flow, use
> of
> certain opcode, etc?
>

The code in mono_method_check_inlining is just an heristics of what methods
to
try to inline. The code that decides what gets inlined or not is in
mono_method_to_ir,
look for INLINE_FAILURE calls.




>
> - Can I force inlining of a given function? Even a hack is fine, I am
> trying to
> evaluate several code generation schemes, and I would like to measure the
> impact
> of inlining. Whatever works is fine.
>

This has been requested a few times, there is a patch floating on the
mailing list
that adds the beginning of the code required for such thing. Other than
that, no, there
is not way to force inlining.

As a hack you can simply change the heristics function to check against an
env var
and then make the call to inline_method pass true to the last argument.



> It seems that a simple copy propagation followed by dead code elimination
> would
> fix it. But I am not sure where I should look. Any comment or suggestion?
>
>
Generating good code without the simd ops enabled was never the idea, but to
improve
it I fear we would need a scalar replacement pass, which is very tricky.

We could get most of the same benefit by using high level load/store from
vtypes
instructions and decompose them later. This would enable us to do apply the
usual
optimizations which right now are not enabled since we generate indirect
loads instructions
which disable most optimizations.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20091202/e7d77b86/attachment.html