> OK, provided that the patches in the above threads apply without conflicts.
> If there are conflicts, please repost for review.
Comitted to 4.7 branch: http://gcc.gnu.org/ml/gcc-cvs/2012-08/msg00360.html
Thanks, K
> OK for mainline.
Thanks!
http://gcc.gnu.org/ml/gcc-cvs/2012-08/msg00264.html
K
>
> Ok.
Checked in:
http://gcc.gnu.org/ml/gcc-cvs/2012-08/msg00231.html
Thanks, K
> Here is the patch with some obvious fixes. If there are no objections,
> could anyone please check it in?
Done:
http://gcc.gnu.org/ml/gcc-cvs/2012-08/msg00203.html
Thanks, K
> Yes, you can put it on the 4.6 branch.
Hi,
Thanks! Checked into 4.6 branch.
http://gcc.gnu.org/ml/gcc-cvs/2012-08/msg00130.html
Thanks, K
Hi Richard,
> Frankly I don't understand the point of these instructions
> being added to the ISA at all. I would have understood an
> add-with-carry that did *not* modify the flags at all, but
> two separate ones that modify C and O separately is just
> downright strange.
If there is only one ca
>
> OK with that change.
Thanks a lot!
Checked into the trunk: http://gcc.gnu.org/ml/gcc-cvs/2012-07/msg00878.html
Thanks, K
htly fixed).
>
> +
> + UNSPEC_RDSEED
>
> Needs to be volatile. Please also add comment.
Done.
>
> Wrong! Please copy pattern from "rdrand_1" (also, please name it
> in the same way).
Done.
>
> +#if !defined _X86INTRIN_H_INCLUDED && !defined _IMMINTRIN_H_INCLUDED
>>
>> OK if you remove the declarations for abort, exit, rand, and srand;
>> they're no longer needed. Presumably an alternate fix would be to
>> add "extern" before the declarations of rand and srand.
>>
>> Janis
Comitted to trunk and 4.7 branch
http://gcc.gnu.org/ml/gcc-cvs/2012-07/msg00811.ht
Hi again,
Here is second patch which adds support of rdseed[16|32|64] insn.
Changelog entry:
2012-07-25 Kirill Yukhin
Michael Zolotukhin
* common/config/i386/i386-common.c (OPTION_MASK_ISA_RDSEED_SET): New.
(OPTION_MASK_ISA_RDSEED_UNSET): Likewise
>> Is it OK for trunk?
>
> OK.
Thanks!
Checked in.
http://gcc.gnu.org/viewcvs?view=revision&revision=189844
Next I think would be rdseed* insns.
Thanks, K
ed (__PRFCHW__) || defined (__3dNOW__)
> +#include
> +#endif
>
> Not needed. This header is already included through mm3dnow.h
> inclusion and directly below
Fixed.
Updated Changelog:
2012-07-25 Kirill Yukhin
Michael Zolotukhin
* common/config/i386/i3
orking both for PRFTCH and 3DNOW bits.
Changelog entry:
2012-07-24 Kirill Yukhin
Michael Zolotukhin
* common/config/i386/i386-common.c (OPTION_MASK_ISA_PRFCHW_SET): New.
(OPTION_MASK_ISA_PRFCHW_UNSET): Likewise.
(ix86_handle_option): Handle mprfchw option.
> - else
> -return "prefetchw\t%a0";
> -}
> + "prefetch\t%a0"
>
> You have a mnemonic clash here. prefetchw is not good name for a new
> instruction, it clashes with existing 3dnow name. Intel will need to
> fix the spec, you probably won't be able to change prefetchw encoding
> in binutils.
Hello guys,
Here is a tiny patch which adds two new intrinsics which were
introduced in recent spec [1].
They're aliased to the existing __lzcnt_* and live under same CPUID.
ChangeLog entry is:
2012-07-16 Kirill Yukhin
PR target/53877
* config/i386/lzcntintrin.h (_lzcn
Reverted.
http://gcc.gnu.org/ml/gcc-cvs/2012-07/msg00442.html
Thanks, K
On Mon, Jul 16, 2012 at 5:36 PM, Kai Tietz wrote:
> Hi,
>
> I would kindly ask to revert this patch soonish. The define
> OPTION_BIONIC is defined within linux.h header, which isn't used by
> cygwin and mingw targets. so t
> Otherwise, this looks good.
>
Thanks, I've applied inputs!
Comitted to MT: http://gcc.gnu.org/ml/gcc-cvs/2012-05/msg00047.html
Thanks, K
ription to extend.texi to mention
Since, I've changed i386 part, I thing Uros's OK is also needed.
ChangeLog entry:
2012-04-27 Kirill Yukhin
Andi Kleen
* coretypes (MEMMODEL_MASK): New.
* builtins.c (get_memmodel): Add val. Call target.memmodel_check
> Otherwise, OK as far as x86 is concerned, but you will need separate
> approval for middle-end part.
Hi guys, this is a ping
Could anybody from middle-end please have a look?
Thanks, K
ated ChangeLog entry:
2012-04-20 Kirill Yukhin
* coretypes (MEMMODEL_MASK): New.
* builtins.c (get_memmodel):Check of upper bound with respect
to target dependent mask.
(expand_builtin_atomic_compare_exchange): Mask memmodel values.
* config/i386/cpuid.h
Thanks!
K
On Thu, Apr 19, 2012 at 9:18 PM, Uros Bizjak wrote:
> On Thu, Apr 19, 2012 at 5:21 PM, Kirill Yukhin
> wrote:
>> Folks,
>> Thanks a lot for prompts!
>> I've updated my patch, so cmparing to previous it is:
>> - have dedicated hook var, to d
entry:
2012-04-19 Kirill Yukhin
* builtins.c (get_memmodel):Check of upper bound with respect
to target dependent mask.
(expand_builtin_atomic_compare_exchange): Mask memmodel values.
* config/i386/cpuid.h (bit_HLE): New.
* config/i386/driver-i
On Wed, Apr 18, 2012 at 5:32 PM, Andrew MacLeod wrote:
> Stupid mailer.. sigh. trying again:
>
>
> On 04/18/2012 05:36 AM, Kirill Yukhin wrote:
>
>> op = expand_normal (exp);
>> - if (INTVAL (op) < 0 || INTVAL (op) >= MEMMODEL_LAST)
>> + if (INT
Sure, thanks for prompt!
On Wed, Apr 18, 2012 at 2:12 PM, Uros Bizjak wrote:
> On Wed, Apr 18, 2012 at 11:34 AM, Kirill Yukhin
> wrote:
>> Hello guys,
>> Since there is no more objections to my RFC, started here [1],
>> I've implemented rest __atomic builtins in th
Whoops, thank you. I'll fix it
K
On Wed, Apr 18, 2012 at 1:44 PM, Rainer Orth
wrote:
> Kirill Yukhin writes:
>
>> Forgot to attach the patch :)
>
> Just a nit: you're using `prefixies' throughout the patch. I guess this
> should be `
Forgot to attach the patch :)
On Wed, Apr 18, 2012 at 1:34 PM, Kirill Yukhin wrote:
> Hello guys,
> Since there is no more objections to my RFC, started here [1],
> I've implemented rest __atomic builtins in the same way.
> It corresponds to Spec, which can be found here [2].
&
Hello guys,
Since there is no more objections to my RFC, started here [1],
I've implemented rest __atomic builtins in the same way.
It corresponds to Spec, which can be found here [2].
Patch attached.
ChangeLog entry:
2012-04-18 Kirill Yukhin
* builtins.c (get_memmodel): Remove
http://gcc.gnu.org/ml/gcc-cvs/2012-04/msg00511.html
> No, just the bits; programmers would need to do
> __atomic_...(..., __ATOMIC_RELEASE | HLE_RELEASE);
> I believe this is what you had in one of your versions of the patch. My
> suggestions was not about doing something new but instead a
> suggestions/poll for a resolution of the discussion.
Oh
> I would suggest that we keep the HLE acq/rel bits independent of the
> memory order bits. Both are independent on a conceptual level. And we
> should add documentation that tells programmers that memory orders need
> always be specified.
>
Sorry, I didn't get your point. You propose to separate
Folks,
Here is patch with removed implied atomic ACQUIRE/RELEASE. Could you
please have a look?
ChangeLog entry:
2012-04-12 Kirill Yukhin
* builtins.c (get_memmodel): Remove check of upper bound.
(expand_builtin_atomic_compare_exchange): Mask memmodel values.
* config
> Perhaps HLE_ACQUIRE / HLE_RELEASE should be something like HLE_START /
> HLE_END instead? Not particularly great names, but at least it avoids
> overloading ACQUIRE/RELEASE and thus should make it clearer that you
> still need to specify a memory order.
>
IMHO, this is also not as good, since AC
t dependant.
ChangeLog entry:
2012-04-11 Kirill Yukhin
* builtins.c (get_memmodel): Remove check of upper bound,
imply HLE to use standard ACQUIRE/RELEASE.
(expand_builtin_atomic_compare_exchange): Mask memmodel values.
* config/i386/cpuid.h (bit_HLE): New.
*
Folks,
Thanks a lot for inputs and suggestions!
Here is updated version of patch.
ChangeLog entry:
2012-04-11 Kirill Yukhin
* builtins.c (get_memmodel): Remove check of upper bound.
(expand_builtin_atomic_compare_exchange): Mask memmodel values.
* config/i386/cpuid.h
>
> Yeah. And you don't need to change the FEs in any way, all that is needed
> is to change the middle-end/expansion (builtins.c - e.g. get_memmodel)
> and the backend (plus predefine the macros in the backend).
>
>Jakub
Hi Jakub,
Attached patch implements HLE support for __atomic_compar
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 a
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 n
>
> 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 entr
Hello guys,
I am attaching initial patch which enables TSX's HLE [1] prefixes in
GCC. Since we have no official intrinsics declarations, I want to hear
your comments about the patch
Note, there is no option '-mhle' and no tests (I'll do that after)
[1] -
http://software.intel.com/en-us/blogs/201
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")
> +
> 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/co
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
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:"
>&
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!
>
>>
&g
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
00 00 xbeginq 0xd
d: 90 nop
K
On Tue, Feb 21, 2012 at 4:37 PM, Jakub Jelinek wrote:
> 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
>> pref
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
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.
>
&g
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
.L3
Thanks, K
On Wed, Dec 14, 2011 at 4:25 PM, Jakub Jelinek wrote:
> On Tue, Dec 13, 2011 at 05:57:40PM +0400, Kirill Yukhin wrote:
>> > Let me hack up a quick pattern recognizer for this...
>
> Here it is, untested so far.
> On the testcase doing 200 f1+f2+f3+f4 calls
Hi Jacob,
this looks really cool. I have a liitle question, since I do not
understand vectorizer as good.
Say, we have a snippet:
int *p;
int idx[N];
int arr[M];
for (...)
{
p[i%4] += arr[idx[I]];
}
As far as I understand, we cannot do gather we, since p may point to
somewere in arr,
and, idx ma
Hi folks,
I've just committed this:
Index: ChangeLog
===
--- ChangeLog (revision 180428)
+++ ChangeLog (revision 180429)
@@ -1,3 +1,7 @@
+2011-10-25 Kirill Yukhin
+
+ * MAINTAINERS (Write After Approval): Add m
Thanks!
K
On Fri, Oct 21, 2011 at 6:34 PM, Uros Bizjak wrote:
> On Fri, Oct 21, 2011 at 3:58 PM, Kirill Yukhin
> wrote:
>
>> Updated testsuite/ChangeLog:
>> 2011-10-21 H.J. Lu
>> Kirill Yukhin
>>
>> * gcc.target/i386
Thanks,
Updated testsuite/ChangeLog:
2011-10-21 H.J. Lu
Kirill Yukhin
* gcc.target/i386/avx2-check.h (main): Check CPUID level
correctly.
* gcc.target/i386/bmi2-check.h: Ditto.
Could anybody please commit that?
K
On Fri, Oct 21, 2011 at 4:56 PM, Uros
Hello,
Here is the patch which checks CPUID correctly to get BMI/BMI2/AVX2 feature.
ChangeLog entry is:
2011-10-21 H.J. Lu
Kirill Yukhin
* config/i386/driver-i386.c (host_detect_local_cpu): Do cpuid 7 only
if max_level allows that.
testsuite/ChangeLg entry is
Thanks!
K
On Fri, Oct 21, 2011 at 12:37 AM, H.J. Lu wrote:
> On Thu, Oct 20, 2011 at 1:30 AM, Kirill Yukhin
> wrote:
>>>
>>> OK.
>>>
>>> Thanks,
>>> Uros.
>>
>> Great,
>> could anybody please commit that?
>>
>
> I checked it in for you.
>
> --
> H.J.
>
>
> OK.
>
> Thanks,
> Uros.
Great,
could anybody please commit that?
K
Thank you guys,
Updated patch is attached. Test fails wihout and passing with the fix.
ChangeLog entry:
2011-10-20 Kirill Yukhin
PR target/50766
* config/i386/i386.md (bmi_bextr_): Update register/
memory operand order.
(bmi2_bzhi_3): Ditto
Hi,
Here is (almost obvous) patch, which fixes PR50766.
ChangeLog entry:
2011-10-19 Kirill Yukhin
* config/i386/i386.md (bmi_bextr_): Update register/
memory operand order.
(bmi2_bzhi_3): Ditto.
(bmi2_pdep_3): Ditto.
(bmi2_pext_3): Ditto.
Bootstrapped
Thank you!
K
On Tue, Oct 18, 2011 at 7:42 PM, H.J. Lu wrote:
> On Mon, Oct 17, 2011 at 7:49 AM, Kirill Yukhin
> wrote:
>> Thanks, guys, could anybody please commit that?
>>
>
> I checked it in for you.
>
>
> --
> H.J.
>
Thanks, guys, could anybody please commit that?
K
On Mon, Oct 17, 2011 at 6:33 PM, Jakub Jelinek wrote:
> On Mon, Oct 17, 2011 at 06:27:04PM +0400, Kirill Yukhin wrote:
>> Thanks for inputs, Jakub!
>>
>> I am attaching updated patch.
>>
>> Updated testsui
Thanks for inputs, Jakub!
I am attaching updated patch.
Updated testsuite/ChangeLog entry:
2011-10-17 Kirill Yukhin
* gcc.target/i386/avx2-vpop-check.h: New header.
* gcc.target/i386/avx2-vpaddd-3.c: New test.
* gcc.target/i386/avx2-vpaddw-3.c: Ditto
Thanks!
K
On Sat, Oct 15, 2011 at 3:08 PM, Uros Bizjak wrote:
> On Sat, Oct 15, 2011 at 10:32 AM, Uros Bizjak wrote:
>
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/fma_double_1.c
@@ -0,0 +1,19 @@
+/* { dg-do compile } */
+/* { dg-prune-output ".*warning: 'sseregpar
Thanks, done.
Anything else?
K
On Fri, Oct 14, 2011 at 3:53 PM, Jakub Jelinek wrote:
> On Fri, Oct 14, 2011 at 03:13:45PM +0400, Kirill Yukhin wrote:
>
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/avx2-vpaddb-3.c
> @@ -0,0 +1,49 @@
> +/* { dg-do run } */
> +/* { d
Hello guys,
Here is a bunch of tests which check basic vectorization abilities to
generate AVX2 instructions.
testsuite/ChangeLog entry is:
2011-10-14 Kirill Yukhin
* gcc.target/i386/avx2-vpaddd-3.c: New test.
* gcc.target/i386/avx2-vpaddw-3.c: Ditto.
* gcc.target/i386
Thank you!
K
On Tue, Oct 11, 2011 at 2:19 PM, Uros Bizjak wrote:
> On Tue, Oct 11, 2011 at 12:12 PM, Kirill Yukhin
> wrote:
>
>> Uros, you was right both with fpmath and configflags. That is why it
>> was passing for me.
>>
>> Attached patch which cures the p
Hi
Uros, you was right both with fpmath and configflags. That is why it
was passing for me.
Attached patch which cures the problem.
testsuite/ChangeLog entry:
2011-10-11 Kirill Yukhin
* gcc.target/i386/fma_double_1.c: Add -mfpmath=sse.
* gcc.target/i386/fma_double_2.c: Ditto
Thank you
K
On Mon, Oct 10, 2011 at 8:08 PM, H.J. Lu wrote:
> On Sun, Oct 9, 2011 at 12:49 PM, Kirill Yukhin
> wrote:
>> Hi guys,
>> This is a Ping. Could anyboady with appropriate rights commit that?
>>
>>
>
> I checked it in for you. Please provide Chang
Hi guys,
This is a Ping. Could anyboady with appropriate rights commit that?
Thanks, K
On Thu, Oct 6, 2011 at 11:46 PM, Uros Bizjak wrote:
> On Thu, Oct 6, 2011 at 3:48 PM, Kirill Yukhin wrote:
>>>
>>> BTW, don't you also need "-mfmpath=sse" in dg
>
> BTW, don't you also need "-mfmpath=sse" in dg-options?
>
According to doc/invoke.texi
...
@itemx -mfma
...
These options will enable GCC to use these extended instructions in
generated code, even without @option{-mfpmath=sse}.
Seems it -mfpmath=sse is useless..
Although, if this is wrong, we
Thank you guys for your support!
K
Done
K
On Mon, Oct 3, 2011 at 10:09 PM, H.J. Lu wrote:
> On Mon, Oct 3, 2011 at 10:19 AM, Kirill Yukhin
> wrote:
>> Hi,
>> I did
>>
>> cvs update
>> cvs diff > ~/changes.html.www.patch
>>
>> It is attached. Is it applying?
>>
>> T
Hi,
I did
cvs update
cvs diff > ~/changes.html.www.patch
It is attached. Is it applying?
Thanks, K
changes.html.www.patch
Description: Binary data
Okay, seems maintainers have no objections
Could anybody please commit that to wwwdocs?
Thanks, K
On Tue, Sep 27, 2011 at 8:19 PM, Gerald Pfeifer wrote:
> On Tue, 27 Sep 2011, Kirill Yukhin wrote:
>> So, if you are ok, let's wait a couple of days for maintainers inputs.
>
Hi,
Gerald, thanks for fixing my "excellent" English :)
Here is updated patch:
Index: htdocs/gcc-4.7/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v
retrieving revision 1.28
diff -p -r1.28 changes.html
*** ht
a typo fixed.
K
On Thu, Sep 22, 2011 at 2:28 PM, Kirill Yukhin wrote:
> Hi,
> I've perepared a list of IA-32/x86-64 related changes (for changes.html).
>
> Could you please have a look and if there're no objections commit?
>
> Thanks, K
>
4.7.0-x86-changes.htm
Hi,
I've perepared a list of IA-32/x86-64 related changes (for changes.html).
Could you please have a look and if there're no objections commit?
Thanks, K
4.7.0-x86-changes.html.www.patch
Description: Binary data
Thank you!
K
On Wed, Sep 21, 2011 at 7:57 PM, H.J. Lu wrote:
> On Wed, Sep 21, 2011 at 5:16 AM, Uros Bizjak wrote:
>> On Wed, Sep 21, 2011 at 2:07 PM, Kirill Yukhin
>> wrote:
>>
>>>> Comments at #else and #endif are now wrong. Also, please avoid -dp in th
>
> Comments at #else and #endif are now wrong. Also, please avoid -dp in the
> tests.
Thanks for inputs. Updated patch is attached (updated comment +
updated tests without -dp).
New tests still passing
Is it OK?
Thanks, K
bmi2.mulx-intrin-2.gcc.patch
Description: Binary data
Hi there,
I've prepared a patch which implements couple of intrinsics for
generation of MULX 32 and 64 bit wide (part of BMI2 extensions).
Tests are added as well
ChangeLog entry:
2011-09-21 Kirill Yukhin
* config/i386/bmi2intrin.h (_mulx_u64): New.
(_mulx_u32):
Thank you!
Guys who is able to write, could you please check-in my changes?
K
On Tue, Aug 30, 2011 at 12:12 PM, Uros Bizjak wrote:
> On Tue, Aug 30, 2011 at 8:39 AM, Kirill Yukhin
> wrote:
>> Hi,
>> This is a ping.
>>
>> Is the patch ok for trunk?
>
> OK.
>
> Thanks,
> Uros.
>
Hi,
This is a ping.
Is the patch ok for trunk?
Thanks, K
On Fri, Aug 26, 2011 at 5:52 PM, H.J. Lu wrote:
> On Fri, Aug 26, 2011 at 6:45 AM, Kirill Yukhin
> wrote:
>> Hi guys,
>> Thanks for your objections.
>>
>> HJ, I scanned all AVX2 tests. So, e
ht. Patch contains usless file. Updated one is attached.
Thanks, K
On Fri, Aug 26, 2011 at 5:04 PM, H.J. Lu wrote:
> On Fri, Aug 26, 2011 at 5:04 AM, Kirill Yukhin
> wrote:
>> According to Jakub's input, I've updated test to scan instruction, not
>> pattern name.
According to Jakub's input, I've updated test to scan instruction, not
pattern name.
Is it ok?
Thanks, K
On Fri, Aug 26, 2011 at 3:45 PM, Kirill Yukhin wrote:
> Hi,
> Here is a fix for http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50182
>
> testsuite/ChangeLog entry:
Hi,
Here is a fix for http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50182
testsuite/ChangeLog entry:
2011-08-26 Kirill Yukhin
PR testsuite/50185
* gcc.target/i386/avx2-vmovmskb-2.c: Rename to ...
* gcc.target/i386/avx2-vpmovmskb-2.c: ... this. Update.
Test passes.
Ok
Pulled down. Updated patch attached.
--
Thanks, K
On Tue, Aug 23, 2011 at 9:06 PM, H.J. Lu wrote:
> On Tue, Aug 23, 2011 at 9:55 AM, Kirill Yukhin
> wrote:
>> Thanks,
>>
>> could anybody please commit that?
>>
>
> Please regenerate AVX2 patch with the cur
Thanks,
could anybody please commit that?
K
On Tue, Aug 23, 2011 at 8:54 PM, Uros Bizjak wrote:
> On Tue, Aug 23, 2011 at 6:31 PM, Kirill Yukhin
> wrote:
>> Thanks, done.
>> Updated patch attached.
>
> OK for mainline.
>
> Thanks,
> Uros.
>
Great! Thanks.
Could anybody please commit that?
K
On Tue, Aug 23, 2011 at 8:53 PM, Uros Bizjak wrote:
> On Tue, Aug 23, 2011 at 6:22 PM, Kirill Yukhin
> wrote:
>
>> thanks. I've applied your inputs.
>>
>> Updated patch, ChangeLog, testsuite/ChangeLog are
Thanks, done.
Updated patch attached.
--
K
On Tue, Aug 23, 2011 at 8:16 PM, Uros Bizjak wrote:
> On Tue, Aug 23, 2011 at 6:03 PM, Kirill Yukhin
> wrote:
>
>> thanks for inputs! I've applied all.
>>
>> Also I fixed I a bug (which produced ICE).
>>
>
2:54 PM, Kirill Yukhin wrote:
> Hi,
> Here is last patch to add initial support of AVX2 in GCC.
> It contains bunch of tests for built-ins.
> All tests pass under simulator and ignored when AVX2 is out.
>
> patch and testsuite/ChangeLog entry are attached,
>
> Is it OK
Thanks for inputs.
Updated test attached.
K
On Mon, Aug 22, 2011 at 11:12 PM, Jakub Jelinek wrote:
> On Mon, Aug 22, 2011 at 10:51:19PM +0400, Kirill Yukhin wrote:
>> testsuite/ChangeLog entry:
>> 2011-08-22 Kirill Yukhin
>>
>> PR target/50155
>>
Hi,
Attached fix for http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50155
ChangeLog entry:
2011-08-22 Kirill Yukhin
PR target/50155
* config/i386/sse.md (VI1248_AVX2): New.
(3): Update.
(*3): Likewise.
(_andnot3): Likewise.
(avx2_pbroadcast
Thanks!
K
On Mon, Aug 22, 2011 at 5:57 PM, H.J. Lu wrote:
> On Mon, Aug 22, 2011 at 6:18 AM, Kirill Yukhin
> wrote:
>> Hi,
>> thanks for input, Uros. Spaces were fixed.
>>
>> Updated patch is attached. ChangeLog entry is attached.
>>
>> Could anybody
Done. Patch attached in previous mail
K
On Fri, Aug 19, 2011 at 6:51 PM, Kirill Yukhin wrote:
> On Fri, Aug 19, 2011 at 6:31 PM, H.J. Lu wrote:
>> It is hard to tell. Can you double check indentation on
>>
>> + if (can_create_pseudo_p () && mode != SI
It was checked in by HJ
http://gcc.gnu.org/viewcvs?view=revision&revision=177876
I am testing next patch.
Thanks, K
On Thu, Aug 11, 2011 at 1:16 PM, Kirill Yukhin wrote:
> Hi Uros,
> Thanks for patience reviewing my English :) and for finding a bug in souces.
>
> Updated patch
Hi Uros,
Thanks for patience reviewing my English :) and for finding a bug in souces.
Updated patch is attached. It was bootstrapped successfully.
updated ChangeLog entry:
2011-08-11 Kirill Yukhin
* common/config/i386/i386-common.c (OPTION_MASK_ISA_AVX2_SET): New
Hi,
Here is second stage patch.
It introduces AVX2 option, define etc.
ChangeLog entry:
2011-08-09 Kirill Yukhin
* common/config/i386/i386-common.c (OPTION_MASK_ISA_AVX2_SET): New.
(OPTION_MASK_ISA_FMA_UNSET): Update.
(OPTION_MASK_ISA_AVX2_UNSET): New
>
> How was the patch tested? On the simulator?
Actually, the problem is not catched by testing. I found one when
runnning Spec 2006 under simulator.
With the patched Spec 2006 suite seems to work OK
>
>> Could anybody with `waa` commit it?
>
> Patch is OK and committed to mainline.
>
> Thanks,
>
Hi,
here is patch for fixing FMA typo + bunch of traling spaces removed.
Changelog entry:
2011-08-09 Kirill Yukhin
* config/i386/i386.c: Remove traling spaces.
* config/i386/sse.md: Likewise.
(*fma_fmadd_): Update.
(*fma_fmsub_): Likewise
701 - 800 of 829 matches
Mail list logo
