[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] tcg/README: Expand advice on number of TCG ops
From: |
Blue Swirl |
Subject: |
Re: [Qemu-devel] [PATCH] tcg/README: Expand advice on number of TCG ops per target insn |
Date: |
Sat, 16 Jul 2011 17:23:49 +0300 |
Thanks, applied.
On Wed, Jul 13, 2011 at 2:00 PM, Peter Maydell <address@hidden> wrote:
> Ping?
>
> On 22 June 2011 15:40, Peter Maydell <address@hidden> wrote:
>> Expand the note on the number of TCG ops generated per target insn,
>> to be clearer about the range of applicability of the 20 op rule
>> of thumb. Also add a note about the hard MAX_OP_PER_INSTR limit.
>>
>> Signed-off-by: Peter Maydell <address@hidden>
>> ---
>> The expansion of the first bullet point is based on remarks by
>> Aurelien in this email:
>> http://lists.gnu.org/archive/html/qemu-devel/2011-06/msg00395.html
>>
>> tcg/README | 10 +++++++++-
>> 1 files changed, 9 insertions(+), 1 deletions(-)
>>
>> diff --git a/tcg/README b/tcg/README
>> index 6600122..cfdfd96 100644
>> --- a/tcg/README
>> +++ b/tcg/README
>> @@ -504,7 +504,15 @@ register.
>> - Don't hesitate to use helpers for complicated or seldom used target
>> instructions. There is little performance advantage in using TCG to
>> implement target instructions taking more than about twenty TCG
>> - instructions.
>> + instructions. Note that this rule of thumb is more applicable to
>> + helpers doing complex logic or arithmetic, where the C compiler has
>> + scope to do a good job of optimisation; it is less relevant where
>> + the instruction is mostly doing loads and stores, and in those cases
>> + inline TCG may still be faster for longer sequences.
>> +
>> +- The hard limit on the number of TCG instructions you can generate
>> + per target instruction is set by MAX_OP_PER_INSTR in exec-all.h --
>> + you cannot exceed this without risking a buffer overrun.
>>
>> - Use the 'discard' instruction if you know that TCG won't be able to
>> prove that a given global is "dead" at a given program point. The
>> --
>> 1.7.1
>>
>>
>>
>
>
>
> --
> 12345678901234567890123456789012345678901234567890123456789012345678901234567890
> 1 2 3 4 5 6 7
> 8
>
>