This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH, i386] RTM support


On 02/20/12 10:51, Uros Bizjak wrote:
> On Mon, Feb 20, 2012 at 7:43 PM, Richard Henderson <rth@redhat.com> wrote:
> 
>>>>> IIUC the documentation, the fallback label is a parameter to xbegin
>>>>> insn, but the insn itself doesn't jump anywhere - it just records the
>>>>> parameter as a fallback address. However, there is no guarantee that
>>>>> the fallback code is exactly at (pc)+6, so we have to use asm labels
>>>>> here.
>>>>
>>>> 6 bytes is the length of the xbegin instruction, so xbegin .+6
>>>> says that it has the fallback address at the immediately next insn
>>>> after xbegin.  Which is the _xbegin () semantics.
>>>
>>> No! From 319433-012a.pdf, page 523, it says that
>>>
>>> tempRIP = RIP + SignExtend (IMM),
>>>
>>> where RIP is instruction following XBEGIN instruction.
>>
>> So?  .+N is generic assembler syntax, not specifying IMM=6.
>> With "xbegin .+6" the assembler will of course encode IMM=0,
>> because it knows that the xbegin insn is 6 bytes.
> 
> Is the "fallback code" the insn just after the xbegin insn?

Yes.

If you write everything in pure assembly (or if the compiler gets
really smart) then you can use the branch-like semantics and 
arrange for the fallback code to be completely out of line.

Otherwise we ignore the branch-like feature and rely entirely on
the data characteristics of the insn, in that %rax is modified.
Thus the initial set of -1 and subsequent compare vs the same.


r~


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]