On Tue, 13 Mar 2012, Uros Bizjak wrote:
> A small no-op change - there is no need for a constraint in an expand
> pattern. Plus some formatting.
If you want to remove it, then remove it, don't just empty it. ;)
> 2012-03-13 Uros Bizjak
>
> * config/i386/i386.md (xbegin): Remove constrai
Thanks!
K
On Tue, Mar 13, 2012 at 11:14 PM, Uros Bizjak wrote:
> On Sun, Mar 11, 2012 at 10:16 AM, Kirill Yukhin
> wrote:
>>>
>>> The patch is OK for mainline, if there are no further comments in next 24h.
>>
>> According to Tobias's input, I've added few lines about RTM to
>> doc/invoke.texi.
On Sun, Mar 11, 2012 at 10:16 AM, Kirill Yukhin wrote:
>>
>> The patch is OK for mainline, if there are no further comments in next 24h.
>
> According to Tobias's input, I've added few lines about RTM to
> doc/invoke.texi. If no objections - I'll commit the patch tomorrow.
A small no-op change -
I forgot to commit headers, but that was fixed in an hour. At the
moment trunk builds
K
On Mon, Mar 12, 2012 at 6:36 PM, H.J. Lu wrote:
> On Sun, Mar 11, 2012 at 1:16 AM, Kirill Yukhin
> wrote:
>>>
>>> The patch is OK for mainline, if there are no further comments in next 24h.
>>
>> Thank you!
On Sun, Mar 11, 2012 at 1:16 AM, Kirill Yukhin wrote:
>>
>> The patch is OK for mainline, if there are no further comments in next 24h.
>
> Thank you!
>
> According to Tobias's input, I've added few lines about RTM to
> doc/invoke.texi. If no objections - I'll commit the patch tomorrow.
>
I think
>
> The patch is OK for mainline, if there are no further comments in next 24h.
Thank you!
According to Tobias's input, I've added few lines about RTM to
doc/invoke.texi. If no objections - I'll commit the patch tomorrow.
Updated patch attached.
Updated ChangeLog entry:
2012-03-11 Kirill Yukhin
On Tue, Mar 6, 2012 at 2:09 PM, Kirill Yukhin wrote:
> Updated patch attached.
>
>> Technically OK, but let's wait for rth's comments about -mrtm option.
> Thanks! Let's wait then.
>
>>
>> break;
>> + case INT_FTYPE_VOID:
>>
>> Please add vertical space.
>>
> Added.
>
>> +(define_expand
Updated patch attached.
>
> Technically OK, but let's wait for rth's comments about -mrtm option.
Thanks! Let's wait then.
>
> break;
> + case INT_FTYPE_VOID:
>
> Please add vertical space.
>
Added.
> +(define_expand "xbegin"
> + [(set (match_operand:SI 0 "register_operand" "=a")
> +
On Tue, Mar 6, 2012 at 12:59 PM, Kirill Yukhin wrote:
>> I'd suggest you generate local label in the expander and pass it to
>> insn RTX. This way, we can also reuse insn pattern later with eventual
>> different code label.
>
> Thanks! Done.
>
> New patch attached.
> Updated changelogs:
>
> Change
> I'd suggest you generate local label in the expander and pass it to
> insn RTX. This way, we can also reuse insn pattern later with eventual
> different code label.
Thanks! Done.
New patch attached.
Updated changelogs:
ChangeLog:
2012-02-16 Kirill Yukhin
* common/config/i386/i386-co
> That said, -mrtm could easily be tested by the compiler to generate
> (or not) inline HTM for implementing -fgnu-tm
Consider my earlier example
if (cpuid(rtm)) _xbegin() .. else fallback
Today if I want to do that I have to pass -mrtm. And the binary would work
on CPUs with and without RT
On 03/05/2012 10:04 AM, Uros Bizjak wrote:
> On Mon, Mar 5, 2012 at 6:12 PM, Andi Kleen wrote:
>> On Mon, Mar 05, 2012 at 03:31:32PM +0400, Kirill Yukhin wrote:
>>> Adding patch
>>
>> I would still remove the "-mrtm" option. I never understood what options
>> for intrinsics are good for. They are
> IIUC, you are annoyed by:
>
> +#ifndef __RTM__
> +# error "RTM instruction set not enabled"
> +#endif /* __RTM__ */
That, yes, but also
(and see PR44987)
>
> in the headers. Indeed, this prevents "#pragma GCC target" to be effective.
>
> But OTOH, intrinsics are internally implemented using
On Mon, Mar 5, 2012 at 8:12 PM, Andi Kleen wrote:
>> Removing -mrtm option would remove one point of control.
>
> If I use the intrinsics I can never remove it because it would just make the
> code not compile.
>
> If I don't use the intrinsics I never need it in the first place.
Aha, I see your
> Removing -mrtm option would remove one point of control.
If I use the intrinsics I can never remove it because it would just make the
code not compile.
If I don't use the intrinsics I never need it in the first place.
-Andi
--
a...@linux.intel.com -- Speaking for myself only.
On Mon, Mar 5, 2012 at 7:47 PM, Andi Kleen wrote:
> The problem I have with the flag is that the typical use model is to
> have multiple code paths, like:
>
> if (cpuid_has_rtm())
> ... do rtm ...
> else
> ... do something else ...
>
> So you have a basic block which needs RTM and another o
On Mon, Mar 05, 2012 at 07:04:47PM +0100, Uros Bizjak wrote:
> On Mon, Mar 5, 2012 at 6:12 PM, Andi Kleen wrote:
> > On Mon, Mar 05, 2012 at 03:31:32PM +0400, Kirill Yukhin wrote:
> >> Adding patch
> >
> > I would still remove the "-mrtm" option. I never understood what options
> > for intrinsics
On Mon, Mar 5, 2012 at 6:12 PM, Andi Kleen wrote:
> On Mon, Mar 05, 2012 at 03:31:32PM +0400, Kirill Yukhin wrote:
>> Adding patch
>
> I would still remove the "-mrtm" option. I never understood what options
> for intrinsics are good for. They are just a pain to add to Makefiles,
> but don't give
On Mon, Mar 5, 2012 at 9:12 PM, Andi Kleen wrote:
> On Mon, Mar 05, 2012 at 03:31:32PM +0400, Kirill Yukhin wrote:
>> Adding patch
>
> I would still remove the "-mrtm" option. I never understood what options
> for intrinsics are good for. They are just a pain to add to Makefiles,
> but don't give
On Mon, Mar 05, 2012 at 03:31:32PM +0400, Kirill Yukhin wrote:
> Adding patch
I would still remove the "-mrtm" option. I never understood what options
for intrinsics are good for. They are just a pain to add to Makefiles,
but don't give any benefit.
-Andi
On Mon, Mar 5, 2012 at 1:02 PM, Kirill Yukhin wrote:
>>> Agreed, this seems not as nice, but still it works :)
>>> I still do not understand, why not to put something like this?
>>> "xbegin\t1f\n1:"
>>> This is local label, which is not intercept others...
>>
>> Because they should be reserved fo
On Mon, Mar 5, 2012 at 3:34 PM, Jakub Jelinek wrote:
> On Mon, Mar 05, 2012 at 03:30:53PM +0400, Kirill Yukhin wrote:
>> Agreed, this seems not as nice, but still it works :)
>> I still do not understand, why not to put something like this?
>> "xbegin\t1f\n1:"
>> This is local label, which is not
On Mon, Mar 05, 2012 at 03:30:53PM +0400, Kirill Yukhin wrote:
> Agreed, this seems not as nice, but still it works :)
> I still do not understand, why not to put something like this?
> "xbegin\t1f\n1:"
> This is local label, which is not intercept others...
Because they should be reserved for inl
Adding patch
On Mon, Mar 5, 2012 at 3:30 PM, Kirill Yukhin wrote:
> Hello Uros,
>
>> As the first remark, you don't have to add BLKmode memory clobbers.
>> unspec_volatile RTX is considered to use and clobber all memory:
>>
>
> Thanks, fixed!
>
>>
>> But, I think that we want to use code label fr
Hello Uros,
> As the first remark, you don't have to add BLKmode memory clobbers.
> unspec_volatile RTX is considered to use and clobber all memory:
>
Thanks, fixed!
>
> But, I think that we want to use code label from the top of the false
> branch instead of ".+6". The question is, how to get i
Yes,
Patrick, you were faster :)
Seems, we just need to pass 0 as IMM value
On Tue, Feb 21, 2012 at 7:14 PM, Patrick Marlier
wrote:
> On 02/21/2012 02:52 AM, Uros Bizjak wrote:
>>
>> On Tue, Feb 21, 2012 at 12:26 AM, Andi Kleen wrote:
IIUC the documentation, the fallback label is a par
On 02/21/2012 02:52 AM, Uros Bizjak wrote:
On Tue, Feb 21, 2012 at 12:26 AM, Andi Kleen 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
From the point of view of the program XBEGIN behaves like a
On Tue, Feb 21, 2012 at 3:21 PM, Jakub Jelinek wrote:
>> As far as I undersand, correct one seems like that:
>> .intel_syntax
>> xbegin $0
>> nop
>>
>> .att_syntax
>> xbegin ($0)
>> nop
>>
>> Which disassembles into:
>> <.text>:
>> 0: c7 f8 00
On Tue, Feb 21, 2012 at 06:11:54PM +0400, Kirill Yukhin wrote:
> As far as I undersand, correct one seems like that:
> .intel_syntax
> xbegin $0
> nop
>
> .att_syntax
> xbegin ($0)
> nop
>
> Which disassembles into:
> <.text>:
>0: c7 f8 00 00
As far as I undersand, correct one seems like that:
.intel_syntax
xbegin $0
nop
.att_syntax
xbegin ($0)
nop
Which disassembles into:
<.text>:
0: c7 f8 00 00 00 00 xbeginq 0x6
6: 90 nop
7: c7 f8 00 00 00 00
On Tue, Feb 21, 2012 at 04:30:01PM +0400, Kirill Yukhin wrote:
> I've played ".+6" and it seems to be working, although I'd rather
> prefer "$0" much better, since it is not deal with insn+ops length.
> Will prepare updated patch later today
xbegin $0
seems to work only for Intel syntax, not AT&T.
Hi guys,
I've played ".+6" and it seems to be working, although I'd rather
prefer "$0" much better, since it is not deal with insn+ops length.
Will prepare updated patch later today
K
On Tue, Feb 21, 2012 at 12:02 PM, Andi Kleen wrote:
>> BTW: Looking a bit more to the spec, we can simply write
> BTW: Looking a bit more to the spec, we can simply write
>
> xbegin $0
>
> as the spec says that offset is relative to the _NEXT_ instruction
Yes that's true. I'm not sure the .+6 even results in 0. Kirill?
-Andi
--
a...@linux.intel.com -- Speaking for myself only.
On Tue, Feb 21, 2012 at 12:26 AM, Andi Kleen 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
>
> From the point of view of the program XBEGIN behaves like a conditional
> jump (with a very compli
> IIUC the documentation, the fallback label is a parameter to xbegin
> insn, but the insn itself doesn't jump anywhere - it just records the
>From the point of view of the program XBEGIN behaves like a conditional
jump (with a very complicated and unpredictable condition)
-Andi
--
a...@linux.i
On Mon, Feb 20, 2012 at 7:57 PM, Richard Henderson wrote:
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,
>>
On 02/20/2012 01:51 PM, Uros Bizjak wrote:
On Mon, Feb 20, 2012 at 7:43 PM, Richard Henderson 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 g
On 02/20/12 10:51, Uros Bizjak wrote:
> On Mon, Feb 20, 2012 at 7:43 PM, Richard Henderson 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,
On Mon, Feb 20, 2012 at 7:43 PM, Richard Henderson 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
On 02/20/12 10:35, Uros Bizjak wrote:
> On Mon, Feb 20, 2012 at 7:31 PM, Jakub Jelinek wrote:
>> On Mon, Feb 20, 2012 at 07:27:48PM +0100, Uros Bizjak wrote:
>>> IIUC the documentation, the fallback label is a parameter to xbegin
>>> insn, but the insn itself doesn't jump anywhere - it just record
On Mon, Feb 20, 2012 at 7:31 PM, Jakub Jelinek wrote:
> On Mon, Feb 20, 2012 at 07:27:48PM +0100, Uros Bizjak 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. H
On Mon, Feb 20, 2012 at 07:27:48PM +0100, Uros Bizjak 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 ex
On Mon, Feb 20, 2012 at 7:18 PM, Jakub Jelinek wrote:
> On Mon, Feb 20, 2012 at 07:10:26PM +0100, Uros Bizjak wrote:
>> > So the above is right and needed, though perhaps we might want
>> > a combine pattern or peephole to turn the
>> > movl $-1, %eax
>> > xbegin .+6
>> > cmpl %eax, $-1
>> > jne 1
On Mon, Feb 20, 2012 at 07:10:26PM +0100, Uros Bizjak wrote:
> > So the above is right and needed, though perhaps we might want
> > a combine pattern or peephole to turn the
> > movl $-1, %eax
> > xbegin .+6
> > cmpl %eax, $-1
> > jne 1f
>
> The compiler can reverse the condition and exchange arms
On Thu, Feb 16, 2012 at 5:47 PM, Jakub Jelinek wrote:
> On Thu, Feb 16, 2012 at 11:26:53AM -0500, Patrick Marlier wrote:
>> On 02/16/2012 11:06 AM, Kirill Yukhin wrote:
>> > +(define_insn "xbegin_1"
>> > + [(set (match_operand:SI 0 "register_operand" "=a")
>> > + (unspec_volatile:SI [(match_du
On Thu, Feb 16, 2012 at 5:06 PM, Kirill Yukhin wrote:
> Hello guys,
> Here is a patch which adds support of first part of Intel TSX extensions.
>
> Could you please have a look?
As the first remark, you don't have to add BLKmode memory clobbers.
unspec_volatile RTX is considered to use and clobbe
On 02/16/2012 11:47 AM, Jakub Jelinek wrote:
if you want to use different fallback code from the transaction code.
So the above is right and needed, though perhaps we might want
a combine pattern or peephole to turn the
movl $-1, %eax
xbegin .+6
cmpl %eax, $-1
jne 1f
sequence into
movl $-1, %eax
On Thu, Feb 16, 2012 at 11:26:53AM -0500, Patrick Marlier wrote:
> Here you cannot specify your fallback instruction address. Since those
> primitives provide high performance speculative code, I would prefer to
> move my fallback code far away from the speculative code path to improve
> the cod
On Thu, Feb 16, 2012 at 11:26:53AM -0500, Patrick Marlier wrote:
> On 02/16/2012 11:06 AM, Kirill Yukhin wrote:
> > +(define_insn "xbegin_1"
> > + [(set (match_operand:SI 0 "register_operand" "=a")
> > +(unspec_volatile:SI [(match_dup 0)] UNSPECV_XBEGIN))
> > + (set (match_operand:BLK 1 "" "
Hi,
On 02/16/2012 11:06 AM, Kirill Yukhin wrote:
> +(define_insn "xbegin_1"
> + [(set (match_operand:SI 0 "register_operand" "=a")
> +(unspec_volatile:SI [(match_dup 0)] UNSPECV_XBEGIN))
> + (set (match_operand:BLK 1 "" "")
> +(unspec_volatile:BLK [(match_dup 1)] UNSPECV_XBEGIN))]
> +
Here is link to the description of TSX:
http://software.intel.com/en-us/blogs/2012/02/07/transactional-synchronization-in-haswell/
K
On Thu, Feb 16, 2012 at 8:06 PM, Kirill Yukhin wrote:
> Hello guys,
> Here is a patch which adds support of first part of Intel TSX extensions.
>
> Could you pleas
Hello guys,
Here is a patch which adds support of first part of Intel TSX extensions.
Could you please have a look?
ChangeLog entry:
2012-02-16 Kirill Yukhin
* common/config/i386/i386-common.c (OPTION_MASK_ISA_RTM_SET):
New.
(OPTION_MASK_ISA_RTM_UNSET): Ditto.
(
52 matches
Mail list logo
