Blue Swirl writes:
> On Mon, Mar 26, 2012 at 13:05, Paul Brook <p...@codesourcery.com> wrote:
>>> On 24 March 2012 18:58, Blue Swirl <blauwir...@gmail.com> wrote:
>>> > v2: fix patch 1, tweak patch 2 and rebase to master.
>>> >
>>> > URL git://repo.or.cz/qemu/blueswirl.git
>>> > http://repo.or.cz/r/qemu/blueswirl.git
>>> >
>>> > Blue Swirl (6):
>>> > arm: move neon_tbl to neon_helper.c
>>> > arm: move saturating arithmetic to helper.c
>>> > arm: move other arithmetic to helper.c
>>> > arm: move cpsr and banked register access to helper.c
>>> > arm: move exception and wfi helpers to helper.c
>>> > arm: move load and store helpers, switch to AREG0 free mode
>>>
>>> The patches themselves look OK, but do we really want to take
>>> a 5% performance hit for this cleanup?
>>
>> I have a similar concern. I'd like to at least have some idea where this
>> slowdown is coming from.
> At least stack protector is protecting more code than before (for
> example TLB miss handler), but could overhead from that amount to 5%?
Then you can try comparing both builds with a modified configure that does not
add the "-fstack-protector-all" option.
If you want to fine-tune it, you can add
"__attribute__((optimize("no-stack-protector")))" to those functions or just
add:
#pragma GCC push_options
#pragma GCC optimize ("no-stack-protector")
at the beginning of the "softmmu_template.h", and:
#pragma GCC pop_options
at the end of it.
Or even better, use it for the whole "target-*/*helper.c" file, as there should
be no user-induced overflow in helpers (unless the instr decoding code in
"translate.c" is exploitable).
Thanks,
Lluis
--
"And it's much the same thing with knowledge, for whenever you learn
something new, the whole world becomes that much richer."
-- The Princess of Pure Reason, as told by Norton Juster in The Phantom
Tollbooth
