This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH]: x86 gas: allow 'rep' prefix on 'bsf' and 'bsr' instructions
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Roland McGrath <mcgrathr at google dot com>
- Cc: binutils at sourceware dot org
- Date: Thu, 21 Jun 2012 16:01:05 -0700
- Subject: Re: [PATCH]: x86 gas: allow 'rep' prefix on 'bsf' and 'bsr' instructions
- References: <email@example.com>
On Thu, Jun 21, 2012 at 2:36 PM, Roland McGrath <firstname.lastname@example.org> wrote:
> 'rep; bsf ...'/'rep; bsr ...' are encoded the same as 'tzcnt ...'/'lzcnt ...'.
> When not doing -mbmi, GCC (trunk) like to emit 'rep; bsf ...' on the
> theory that since the two instructions have sufficiently similar
> semantics for the purposes for which the compiler emits this,
> BMI-capable hardware will decode it as 'tzcnt ...' and may execute that
> faster than 'bsf ...', while older hardware will ignore the REP prefix
> and decode it as 'bsf ...'.
> When using .bundle_align_mode, the assembler might decide to insert some
> nop padding between any two instructions, so the ';' could become some
> number of nop instructions and break the encoding intended.
> This change makes the assembler accept 'rep bsf ...' or 'rep bsr ...'
> without complaint. ?The result is the same as using the 'tzcnt' or
> 'lzcnt' mnemonic, but the 'rep' forms are accepted even under
> -march=i686 or the like where 'tzcnt' and 'lzcnt' would be refused.
> With this, I can change the compiler to use this syntax (when configured
> with a new assembler) and remove the possibility of running afoul of
> .bundle_align_mode nop-insertion.
> No testsuite failures on an x86_64-linux-gnu host.
> Ok for trunk?
> (I've omitted the large patch to the generated file opcodes/i386-tbl.h,
> so use --enable-maintainer-mode to test the patch.)
Please make following changes:
1. Move RepPrefixOk next to HLEPrefixOk.
2. Add RepPrefixOk to all insns with IsString
3. Check repprefixok instead of isstring for REP prefix in
OK with those changes.