[llvm-commits] [llvm] r61424 - in /llvm/trunk/lib/Target/X86: X86Instr64bit.td X86InstrInfo.td

Chris Lattner clattner at apple.com
Wed Dec 24 21:19:56 PST 2008


On Dec 24, 2008, at 9:15 PM, Eli Friedman wrote:

> On Wed, Dec 24, 2008 at 9:00 PM, Chris Lattner <clattner at apple.com>  
> wrote:
>>
>> On Dec 24, 2008, at 7:28 PM, Eli Friedman wrote:
>>
>>> On Wed, Dec 24, 2008 at 5:27 PM, Chris Lattner <sabre at nondot.org>
>>> wrote:
>>>> Author: lattner
>>>> Date: Wed Dec 24 19:27:10 2008
>>>> New Revision: 61424
>>>>
>>>> URL: http://llvm.org/viewvc/llvm-project?rev=61424&view=rev
>>>> Log:
>>>> BT memory operands load from their address operand.
>>>
>>> Do we really want to map this to the same intrinsic as the register
>>> form?  "mov (%esp), %eax; bt %ebx, %eax;" has different semantics  
>>> from
>>> "bt %ebx, (%esp)", and the latter form is significantly slower.
>>
>> It does?  How so?  The later form reduces register pressure, so  
>> absent
>> a difference in semantics it is preferable.
>
> Suppose ebx contains the number 32.  The register form modifies the
> bottom bit of eax; the memory form modifies bottom bit of the
> *following* integer in memory.
>
> Also, even ignoring that, performance is hugely different: on a Core
> 2, "bt %ebx, %eax" is one uop, but "bt %ebx, (%esp)" is 10 uops.  The
> difference isn't quite as severe on other processors, but the reg-reg
> form is still significantly faster even if a load from memory is
> necessary.

Are you sure you aren't thinking of btc/bts?  bt doesn't modify any  
operands.

-Chris



More information about the llvm-commits mailing list