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%? Otherwise there should be just a few extra register moves here and there, that should be cheap on modern processors.