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
On Fri, Jul 6, 2012 at 7:25 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 06.07.12 at 16:09, "H.J. Lu" <firstname.lastname@example.org> wrote:
>> On Fri, Jul 6, 2012 at 6:47 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>> On 06.07.12 at 15:06, "H.J. Lu" <email@example.com> wrote:
>>>> On Fri, Jul 6, 2012 at 2:52 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>>> On 21.06.12 at 23:36, Roland McGrath <firstname.lastname@example.org> wrote:
>>>>>> 'rep; bsf ...'/'rep; bsr ...' are encoded the same as 'tzcnt ...'/'lzcnt
>>>>> While tzcnt really is an extension of bsf, lzcnt is not one of bsr,
>>>>> so I don't really follow why it's useful to allow the prefix there.
>>>> It can be used to encode lzcnt with the older assembler,
>>>> similar to pause.
>>> You didn't get my point: rep bsr, for non-zero input, is _not_
>>> equivalent to bsr (this equivalence exists only for bsf/tzcnt,
>>> no matter what the Intel SDM says). Hence allowing this
>>> combination is potentially misleading, and not useful to gcc
>>> (which was the supposed original goal of the change).
>> lzcnt is executed as bsr on the older processors.
> That is exactly my point: It will, even for non-zero inputs,
> produce different results depending on whether it is being
> run on an old or a new CPU. Hence it's not suitable for
> trickery like can be played with the bsf/tzcnt pair.
> And just to be clear - the fact that this being possible was
> implicitly (but wrongly) suggested by the original description
> of the patch here made me almost fall into that trap and try
> to use tzcnt as (presumably better performing) replacement
> for bsr somewhere else.
You can't draw this conclusion from rep XXX. Even tzcnt != bsf
on zero input. We fixed a GCC bug recently. I will leave it