This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH, i386] Add prefixes avoidance tuning for silvermont target
- From: Mike Stump <mikestump at comcast dot net>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Andi Kleen <andi at firstfloor dot org>, Ilya Enkovich <enkovich dot gnu at gmail dot com>, gcc-patches at gcc dot gnu dot org
- Date: Wed, 2 Jul 2014 10:08:27 -0700
- Subject: Re: [PATCH, i386] Add prefixes avoidance tuning for silvermont target
- Authentication-results: sourceware.org; auth=none
- References: <20140702103536 dot GA1827 at msticlxl57 dot ims dot intel dot com> <87r423u3y2 dot fsf at tassilo dot jf dot intel dot com> <20140702162700 dot GX31640 at tucnak dot redhat dot com>
On Jul 2, 2014, at 9:27 AM, Jakub Jelinek <email@example.com> wrote:
> On Wed, Jul 02, 2014 at 09:21:25AM -0700, Andi Kleen wrote:
>> Ilya Enkovich <firstname.lastname@example.org> writes:
>>> Silvermont processors have penalty for instructions having 4+ bytes of
>>> prefixes (including escape bytes in opcode). This situation happens
>>> when REX prefix is used in SSE4 instructions. This patch tries to
>>> avoid such situation by preferring xmm0-xmm7 usage over xmm8-xmm15 in
>>> those instructions. I achieved it by adding new tuning flag and new
>>> alternatives affected by tuning.
>> Why make it a tuning flag? Shouldn't this help unconditionally for code
>> size everywhere? Or is there some drawback?
> I don't think it will make code smaller, if you already have some value in
> xmm8..xmm15 register, then by not allowing those registers directly on SSE4
> insns just means it reloading and larger code.
I can’t help but think a better way to do this is to explain the costs of the REX registers as being more expensive, then let the register allocator prefer the cheaper registers. You then leave them all as valid, which I think is better than disappearing 1/2 of the registers. Is it really cheaper to spill and reload those than use a REX register?