[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