Hello,
> All good, thanks!
Checked into MT: http://gcc.gnu.org/viewcvs?rev=201871&root=gcc&view=rev
--
Thanks, K
quot;TARGET_AVX") V4SF
> > + (V8DF "TARGET_AVX512F") (V4DF "TARGET_AVX") V2DF])
>
> Let's rename this VMOVE, and apply only that change as a separate patch.
Hello,
I think this is kinda obvious.
I've renamed V16 iterator into VMOVE.
ChangeLog en
On 20 Aug 08:30, Richard Henderson wrote:
Hello,
> This is ok.
Checked into main trunk: http://gcc.gnu.org/ml/gcc-cvs/2013-08/msg00504.html
--
Thanks, K
Hello,
> The patch is ok to commit.
Thanks a lot! Checked in to main trunk:
http://gcc.gnu.org/ml/gcc-cvs/2013-08/msg00524.html
--
K
Hello Richard,
On 19 Aug 14:17, Richard Henderson wrote:
> On 08/14/2013 12:23 AM, Kirill Yukhin wrote:
> > + ;; For AVX512F mask support
> > + UNSPEC_KIOR
> > + UNSPEC_KXOR
> > + UNSPEC_KAND
> > + UNSPEC_KANDN
>
> I thought we determined that y
On 14 Aug 11:44, Kirill Yukhin wrote:
PING?
Thanks, K
Hello,
On 21 Aug 13:02, Richard Henderson wrote:
> On 08/21/2013 11:28 AM, Kirill Yukhin wrote:
> > (eq_attr "alternative" "12,13")
> > - (cond [(ior (not (match_test "TARGET_SSE2"))
> > + (cond [(ior (matc
Hello,
On 22 Aug 12:06, Richard Henderson wrote:
> Ok.
I've updated ChangeLog (thanks, HJ!) and
checked in to main trunk: http://gcc.gnu.org/ml/gcc-cvs/2013-08/msg00545.html
--
Thanks, K
ga
Anna Tikhonova
Ilya Tocar
Andrey Turetskiy
Ilya Verbin
Kirill Yukhin
Michael Zolotukhin
* config/i386/constraints.md (k): New.
(Yk): Ditto.
* config/i386/i386.c (const regclass_map): A
Hello Reichard,
On 26 Aug 09:37, Richard Henderson wrote:
> On 08/26/2013 09:13 AM, Kirill Yukhin wrote:
> > +(define_split
> > + [(set (match_operand:SWI12 0 "mask_reg_operand")
> > + (any_logic:SWI12 (match_operand:SWI12 1 "mask_reg_operand")
> &
Hello,
> This patch is still far too large.
>
> I think you should split it up based on every single mode iterator that
> you need to add or change.
Problem is that some iterators are depend on each other, so patches are
not going to be tiny.
Here is 1st one. It extends VF iterator - biggest im
On 27 Aug 22:11, Kirill Yukhin wrote:
Hello, I've while pasting the patch I've accidentally put
extra brace.
Pls Ignore it
> +(define_insn "kxnor"
> + [(set (match_operand:SWI12 0 "register_operand" "=r,!k")
> + (not:SWI12
> +
Hello Richard,
On 27 Aug 13:07, Richard Henderson wrote:
> On 08/27/2013 11:11 AM, Kirill Yukhin wrote:
> >> > What happened to the bmi andn alternative we discussed?
> > BMI only supported for 4- and 8- byte integers, while
> > kandw - for HI/QI
> >
>
>
Hello Richard,
On 28 Aug 10:55, Richard Henderson wrote:
> On 08/28/2013 10:45 AM, Kirill Yukhin wrote:
> > Hello Richard,
> >
> > On 27 Aug 13:07, Richard Henderson wrote:
> >> On 08/27/2013 11:11 AM, Kirill Yukhin wrote:
> >>>>> What happened to
Hello,
On 28 Aug 13:17, Richard Henderson wrote:
> Uh, no, you can't just add it when doing the split. You could be adding it in
> a place that the flags register is live. You must ALWAYS have the clobber on
> the whole pattern when gprs are possible.
I see now, thanks a lot for explanation!
>
Hello,
> Testing in progress, is it ok for trunk if pass?
I forgot to add clobber to split of andn,
so testing fail. Fixed.
Updated patch in the bottom.
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spec 2000 & 2006 build show no regressions both with and without -mavx5
Hello,
> This patch [actually the change at 201915] also broke X86 Darwin
> bootstrap/ABI: pr59269
> - ISTM that SSE_REGNO_P() now returns true for a different set of registers
> than before the patch,
> I've attached a starting-point to fix to the PR - but would welcome any
> additional inputs
Hello,
PING.
--
Thanks, K
Hello,
On 04 Sep 20:11, Maxim Kuvyrkov wrote:
> On 4/09/2013, at 7:43 PM, Alexander Ivchenko wrote:
> The patch is OK with definitions of OPTION_GLIBC, OPTION_UCLIBC and
> OPTION_BIONIC copied verbatim from gcc/config/l
Checked into main trunk: http://gcc.gnu.org/ml/gcc-cvs/2013-09/msg00137.html
Hello,
Here is a patch to fix pr58269.
Actually this is not a full fix, but an obvious part.
ChangeLog entry:
2013-09-06 Kirill Yukhin
PR target/58269
* gcc/config/i386/i386.c (ix86_conditional_register_usage):
Proper initialize extended SSE registers.
Bootstrap pass
Hello,
On 06 Sep 11:29, Jakub Jelinek wrote:
> On Fri, Sep 06, 2013 at 11:28:53AM +0200, Uros Bizjak wrote:
> > This is OK.
>
> But please leave out gcc/ prefix from the ChangeLog entry.
Thanks, checked into main trunk:
http://gcc.gnu.org/ml/gcc-cvs/2013-09/msg00181.html
with fixed ChangeLog.
-
Hello,
PING.
--
Thanks, K
Hello,
On 29 Aug 15:59, Kirill Yukhin wrote:
> /* Define parameter passing and return registers. */
> @@ -4219,8 +4225,13 @@ ix86_conditional_register_usage (void)
>
>/* If AVX512F is disabled, squash the registers. */
>if (! TARGET_AVX512F)
> -for (i = FIRST_
Hello,
On 04 Sep 22:45, Kirill Yukhin wrote:
> Hello,
>
> PING.
PING.
--
Thanks, K
Hello,
On 06 Sep 17:41, Kirill Yukhin wrote:
> Hello,
>
> PING.
PING.
--
Thanks, K
Hello,
On 09 Sep 13:50, Uros Bizjak wrote:
> OK.
Checked into main trunk: http://gcc.gnu.org/ml/gcc-cvs/2013-09/msg00286.html
--
Thanks, K
Hello Richard,
Thanks for inputs.
On 09 Sep 10:39, Richard Henderson wrote:
> gen_andhi_1 is not used, nor is it likely to be in the future, therefore this
> should still have "*".
We're using it in patch 6/8 when introducing plugins:
+ { OPTION_MASK_ISA_AVX512F, CODE_FOR_andhi_1, "__builtin_ia3
Hello,
On 10 Sep 09:17, Richard Henderson wrote:
> On 09/10/2013 05:57 AM, Kirill Yukhin wrote:
> > + { OPTION_MASK_ISA_AVX512F, CODE_FOR_andhi_1, "__builtin_ia32_kandhi",
> > IX86_BUILTIN_KAND16, UNKNOWN, (int) HI_FTYPE_HI_HI },
>
> Alternately, why not u
Hello,
On 10 Sep 19:42, Uros Bizjak wrote:
> The patch is OK for mainline.
Checked into main trunk: http://gcc.gnu.org/ml/gcc-cvs/2013-09/msg00353.html
--
Thanks, K
Hello,
On 10 Sep 11:51, Richard Henderson wrote:
> On 09/10/2013 11:25 AM, Kirill Yukhin wrote:
> > Is it ok now?
>
>
> Yes.
Thanks a lot!
Checked into main trunk: http://gcc.gnu.org/ml/gcc-cvs/2013-09/msg00354.html
--
Thanks, K
Hello,
On 10 Sep 19:32, Uros Bizjak wrote:
> On Tue, Sep 10, 2013 at 4:56 PM, Yuri Rumyantsev wrote:
> > Is it OK for trunk?
> OK.
Checked into main trunk: http://gcc.gnu.org/ml/gcc-cvs/2013-09/msg00383.html
--
Thanks, K
Hello,
On 09 Sep 15:11, Kirill Yukhin wrote:
> Hello,
> On 06 Sep 17:41, Kirill Yukhin wrote:
> > Hello,
> >
> > PING.
> PING.
PING.
--
Thanks, K
Hello,
On 12 Sep 08:19, Caroline Tice wrote:
> Yes, that patch is ok.
>
> -- Caroline Tice
> cmt...@google.com
>
> On Thu, Sep 12, 2013 at 3:56 AM, Alexander Ivchenko
> wrote:
> >
> > Is following patch OK?
Checked into main trunk: http://gcc.gnu.org/ml/gcc-cvs/2013-09/msg00425.html
--
Thanks
Hello,
On 16 Sep 16:36, Uros Bizjak wrote:
> The patch with a fixed comment is OK otherwise.
Checked into main trunk: http://gcc.gnu.org/ml/gcc-cvs/2013-09/msg00512.html
--
Thanks, K
Hello,
On 13 Sep 14:28, Kirill Yukhin wrote:
> Hello,
> On 09 Sep 15:11, Kirill Yukhin wrote:
> > Hello,
> > On 06 Sep 17:41, Kirill Yukhin wrote:
> > > Hello,
> > >
> > > PING.
> > PING.
> PING.
PING
--
Thanks, K
Hello,
On 18 Sep 11:17, Kirill Yukhin wrote:
> Hello,
> On 13 Sep 14:28, Kirill Yukhin wrote:
> > Hello,
> > On 09 Sep 15:11, Kirill Yukhin wrote:
> > > Hello,
> > > On 06 Sep 17:41, Kirill Yukhin wrote:
> > > > Hello,
> > > >
> > > > PING.
> > > PING.
> > PING.
> PING
PING.
--
Thanks, K
Hi,
> Based on this opinion, the patch is OK for mainline, if there are no
...
Checked in: http://gcc.gnu.org/ml/gcc-cvs/2012-10/msg00187.html
K
Hi guys,
>> Is it ok for release it into trunk and 4.7?
>
> Yes, please do so.
Checked into trunk: http://gcc.gnu.org/ml/gcc-cvs/2012-10/msg00419.html
and 4.7: http://gcc.gnu.org/ml/gcc-cvs/2012-10/msg00431.html
Thanks, K
Reverted.
Trunk: http://gcc.gnu.org/ml/gcc-cvs/2012-10/msg00516.html
4.7: http://gcc.gnu.org/ml/gcc-cvs/2012-10/msg00517.html
K
>> Looks Ok. If David can test is successfully on AIX I can approve it.
>
> I was able to bootstrap successfully with the patch.
Checked in: http://gcc.gnu.org/ml/gcc-cvs/2012-10/msg00581.html
Thanks, K
Hi,
> So, the patch is OK for mainline (with -mxsave removed from sse-X tests).
>
> Please commit the patch to mainline SVN.
>
Checked in: http://gcc.gnu.org/ml/gcc-cvs/2012-10/msg00963.html
Thanks, K
> If it were not approved yet by an insn scheduler maintainer, it is ok for
> me. As Uros wrote that he rubberstamps the patch if a scheduler maintainer
> approves it, so you can commit it into the mainline.
Checked in: http://gcc.gnu.org/ml/gcc-cvs/2012-10/msg00965.html
K
Hello,
> This patch is still far too large.
>
> I think you should split it up based on every single mode iterator that
> you need to add or change.
Here's 2nd subpatch. It fixes missing `v' constraints.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spec 20
Hello,
> This patch is still far too large.
>
> I think you should split it up based on every single mode iterator that
> you need to add or change.
Here's 3rd subpatch. It extends VF1 and VI iterators.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spec 2000
Hello,
> This patch is still far too large.
>
> I think you should split it up based on every single mode iterator that
> you need to add or change.
Here's 4th subpatch. It extends V iterator.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spec 2000 & 2006 bu
Hello,
> This patch is still far too large.
>
> I think you should split it up based on every single mode iterator that
> you need to add or change.
Here's 6th subpatch. It extends VI2 and VI124 iterators.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spec 2
Hello,
> This patch is still far too large.
>
> I think you should split it up based on every single mode iterator that
> you need to add or change.
Here's 5th subpatch. It introduces `multdiv' code iterator.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spe
Hello,
> This patch is still far too large.
>
> I think you should split it up based on every single mode iterator that
> you need to add or change.
Here's 7th subpatch. It extends VI4 and VI8 iterators.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spec 200
Hello,
> This patch is still far too large.
>
> I think you should split it up based on every single mode iterator that
> you need to add or change.
Here's 8th subpatch. It extends VI48 and VI48_AVX2 iterators.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. S
Hello,
> This patch is still far too large.
>
> I think you should split it up based on every single mode iterator that
> you need to add or change.
Here's 10th subpatch. It introduces VI248_AVX2_8_AVX512F and VI124_256_48_512
iterators.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check
Hello,
> This patch is still far too large.
>
> I think you should split it up based on every single mode iterator that
> you need to add or change.
Here's 9th subpatch. It extends VI124_AVX2_48 and VI8F iterators.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
Hello,
> This patch is still far too large.
>
> I think you should split it up based on every single mode iterator that
> you need to add or change.
Here's 11th subpatch. It introduces AVX-512 FMA instructions.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. S
Hello,
> This patch is still far too large.
>
> I think you should split it up based on every single mode iterator that
> you need to add or change.
Here's 13th subpatch. It introduces VI4_AVX iterator.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spec 2000
Hello,
> This patch is still far too large.
>
> I think you should split it up based on every single mode iterator that
> you need to add or change.
Here's 12th subpatch. It introduces VF_512 and VI_512 iterators.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3
Hello,
> This patch is still far too large.
>
> I think you should split it up based on every single mode iterator that
> you need to add or change.
Here's 15th subpatch. It introduces VI48F_512 iterator.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spec 20
Hello,
> This patch is still far too large.
>
> I think you should split it up based on every single mode iterator that
> you need to add or change.
Here's 14th subpatch. It introduces VI48F_256_512 iterator.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spe
Hello,
> This patch is still far too large.
>
> I think you should split it up based on every single mode iterator that
> you need to add or change.
Here's 17th subpatch. It introduces V8FI and V16FI iterators.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. S
Hello,
> This patch is still far too large.
>
> I think you should split it up based on every single mode iterator that
> you need to add or change.
Here's 18th subpatch. It introduces various new insns.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spec 200
Hello,
> This patch is still far too large.
>
> I think you should split it up based on every single mode iterator that
> you need to add or change.
Here's 20th subpatch. It introduces last insns of AVX-512F.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spe
Hello,
> This patch is still far too large.
>
> I think you should split it up based on every single mode iterator that
> you need to add or change.
Here's 19th subpatch. It extends extract and convert insn patterns.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
Hello,
> This patch is still far too large.
>
> I think you should split it up based on every single mode iterator that
> you need to add or change.
Here's 1st subpatch. It extends VI4F_128 and introduces VI48_512 iterator.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regres
Hello,
Thanks a lot for all reviews!
On 09 Oct 14:55, Richard Henderson wrote:
> On 10/09/2013 03:28 AM, Kirill Yukhin wrote:
> > +;; CPUID bit AVX512F enables evex encoded scalar and 512-bit fma. It
> > doesn't
> > +;; care about FMA bit, so we enable fma fo
Hello,
On 09 Oct 14:20, Richard Henderson wrote:
> On 10/09/2013 03:24 AM, Kirill Yukhin wrote:
> > Here's 2nd subpatch. It fixes missing `v' constraints.
>
> And one v constraint that shouldn't have been.
Exactly!
> Ok.
Checked into main trunk: http://gcc.gn
Hello,
On 09 Oct 14:25, Richard Henderson wrote:
> On 10/09/2013 03:24 AM, Kirill Yukhin wrote:
> > Here's 3rd subpatch. It extends VF1 and VI iterators.
>
> Ok.
Thanks, checked into main trunk:
http://gcc.gnu.org/ml/gcc-cvs/2013-10/msg00380.html
K
Hello,
On 09 Oct 14:32, Richard Henderson wrote:
> On 10/09/2013 03:25 AM, Kirill Yukhin wrote:
> > Here's 4th subpatch. It extends V iterator.
> Ok.
Thanks, checked into main trunk:
http://gcc.gnu.org/ml/gcc-cvs/2013-10/msg00382.html
K
Hello,
On 09 Oct 14:34, Richard Henderson wrote:
> On 10/09/2013 03:25 AM, Kirill Yukhin wrote:
> > Here's 5th subpatch. It introduces `multdiv' code iterator.
>
> This is the sort of patch I like to see. It's the first one
> you've sent that's done e
Hello
On 09 Oct 14:35, Richard Henderson wrote:
> On 10/09/2013 03:26 AM, Kirill Yukhin wrote:
> > Here's 6th subpatch. It extends VI2 and VI124 iterators.
>
> Ok.
Thanks, checked into main trunk:
http://gcc.gnu.org/ml/gcc-cvs/2013-10/msg00384.html
K
Hello,
On 09 Oct 14:37, Richard Henderson wrote:
> On 10/09/2013 03:26 AM, Kirill Yukhin wrote:
> > Here's 7th subpatch. It extends VI4 and VI8 iterators.
>
> Ok.
Thanks, checked into main trunk:
http://gcc.gnu.org/ml/gcc-cvs/2013-10/msg00385.html
K
On 11 Oct 15:43, Jakub Jelinek wrote:
> On Fri, Oct 11, 2013 at 05:39:05PM +0400, Kirill Yukhin wrote:
> > Thanks, checked into main trunk:
> > http://gcc.gnu.org/ml/gcc-cvs/2013-10/msg00383.html
>
> Everybody can read gcc-cvs mailing list, it's archives or svn log
>
Hello,
On 11 Oct 10:30, Richard Henderson wrote:
> On 10/09/2013 03:29 AM, Kirill Yukhin wrote:
> > +(define_insn "avx512f_vec_dup_mem"
> > + [(set (match_operand:VI48F_512 0 "register_operand" "=x")
> > + (vec_duplicate:VI48F_512
>
Hello,
On 11 Oct 11:21, Richard Henderson wrote:
> On 10/09/2013 03:30 AM, Kirill Yukhin wrote:
> > +;; Return true if OP is either -1 constant or stored in register.
> > +(define_predicate "register_or_constm1_operand"
> > + (ior (match_operand 0 "register_o
Hello,
On 14 Oct 13:10, Richard Henderson wrote:
> On 10/09/2013 03:31 AM, Kirill Yukhin wrote:
> > +(define_mode_attr ssefixupmode
> > + [(V16SF "V16SI") (V4SF "V4SI") (V8DF "V8DI") (V2DF "V2DI")])
> > +
>
> Oh, I forgot. H
++---
2 files changed, 23 insertions(+), 105 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index ebaa3e0..b25d8eb 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,12 @@
+2013-10-16 Kirill Yukhin
+
+ * config/i386/sse.md
Hello,
On 15 Oct 08:46, Richard Henderson wrote:
> On 10/09/2013 03:31 AM, Kirill Yukhin wrote:
> > + rtx op1 = operands[1];
> > + if (REG_P (op1))
> > +op1 = gen_rtx_REG (V16HImode, REGNO (op1));
> > + else
> > +op1 = gen_lowpart (V16HImode, op1);
&g
Hello,
On 16 Oct 09:59, Richard Henderson wrote:
> On 10/16/2013 09:07 AM, Kirill Yukhin wrote:
> > I suspect gen_lowpart is bad turn when reload is completed, as
> > far as it can create new pseudo. gen_lowpart () may call
> > gen_reg_rtx (), which contain corresponging gcc_
Hello,
On 17 Oct 13:14, Uros Bizjak wrote:
> On Thu, Oct 17, 2013 at 12:47 PM, Kirill Yukhin
> wrote:
> >
> >> > I suspect gen_lowpart is bad turn when reload is completed, as
> >> > far as it can create new pseudo. gen_lowpart () may call
> >>
Hello,
On 20 Oct 11:55, Uros Bizjak wrote:
> Please also add back expanders with operand fixups and insn
> constraints, as is the case with other commutative operators. They are
> needed to hoist operand loads out of the loops (reload and later
> passes won't hoist memory loads out of the loops whe
Hello Richard,
Thanks for remarks, they all seems reasonable.
One question
On 21 Oct 16:01, Richard Henderson wrote:
> > +(define_insn "avx512f_moves_mask"
> > + [(set (match_operand:VF_128 0 "register_operand" "=v")
> > + (vec_merge:VF_128
> > + (vec_merge:VF_128
> > + (match_operan
Hello Richard,
On 22 Oct 08:16, Richard Henderson wrote:
> On 10/22/2013 07:42 AM, Kirill Yukhin wrote:
> > Hello Richard,
> > Thanks for remarks, they all seems reasonable.
> >
> > One question
> >
> > On 21 Oct 16:01, Richard Henderson wrote:
Hello,
This patch introduces mask scalar subst.
Is it ok to commit to main trunk?
Testing pass.
--
Thanks, K
---
gcc/config/i386/sse.md | 104 ---
gcc/config/i386/subst.md | 23 +++
2 files changed, 95 insertions(+), 32 deletions(-)
diff
Hello,
This patch introduces "mask_scalar_merge" subst.
Is it ok to commit to main trunk?
Testing pass.
--
Thanks, K
---
gcc/config/i386/sse.md | 26 +-
gcc/config/i386/subst.md | 16
2 files changed, 29 insertions(+), 13 deletions(-)
diff --git a/
Hello Richard,
On 28 Oct 08:20, Richard Henderson wrote:
> Why is a masked *scalar* operation useful?
The reason the instructions exist is so that
you can do fully fault correct predicated scalar algorithms.
I example.
In fact, with some hacky tricks, you can fully predicate
normal C code in the
Hello Richard,
On 28 Oct 14:45, Richard Henderson wrote:
> On 10/28/2013 01:58 PM, Kirill Yukhin wrote:
> > Hello Richard,
> > On 28 Oct 08:20, Richard Henderson wrote:
> >> Why is a masked *scalar* operation useful?
> >
> > The reason the instructions exist i
Hello,
On 01 Nov 16:19, Kirill Yukhin wrote:
> Coould you pls take a look?
PING.
--
Thanks, K
Hello,
Small correction.
On 01 Nov 16:19, Kirill Yukhin wrote:
> +(define_insn "avx512f_store_mask"
> + [(set (match_operand:VI48F_512 0 "memory_operand" "=m")
> + (vec_merge:VI48F_512
> + (match_operand:VI48F_512 1 &quo
Thanks, K
commit 7fa978b9b80a6d50a81065755be81acc2923b0e2
Author: Kirill Yukhin
Date: Wed Feb 3 12:37:13 2016 +0300
AVX512. Fix PR69118 - wrong target for compare pattern.
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 7f89679..045a85f 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386
Hi Sasha,
On 04 Feb 17:59, Alexander Fomin wrote:
> OK for trunk and 5-branch?
Patch is OK for main trunk and release branches.
(IMHO, pretty much obvious).
--
Thanks, K
Hello Jakub,
On 17 Feb 17:46, Jakub Jelinek wrote:
> Hi!
>
> As I wrote in the PR, fwprop is able to forward CONST0_RTX back into
> instructions even if CSE optimized them, but the problem in that case is
> that for vector_move_operand "0C" operands if they appear inside of
> (vec_select ... (para
Hi Jakub!
On 15 Feb 22:00, Jakub Jelinek wrote:
> Hi!
>
> We ICE on the following testcase, because vcondv32hiv32hi pattern
> really needs avx512bw, but it is enabled for avx512f.
> As VI_512 iterator is only used in vcond* patterns which need the
> avx512bw ISA for the V64QI and V32HI modes, I've
Hi Jakub,
On 03 Mar 13:08, Jakub Jelinek wrote:
> routine has changed and looks good to me). Can somebody test this please
> on real hw or emulator?
I'll run testing on the simulator.
--
Thanks, K
On 03 Mar 21:17, Jakub Jelinek wrote:
> On Thu, Mar 03, 2016 at 01:08:41PM +0100, Jakub Jelinek wrote:
> > Fixed thusly, unfortunately I don't have access to avx512f (and not even to
> > avx512dq) hw, so while I will bootstrap/regtest it on Haswell-E, can't test
> > the tests if they now work at ru
Hello,
On 20 Nov 18:37, Kirill Yukhin wrote:
> Hello,
> Patch in the bottom fixes PR52731.
> Is it ok for trunk?
Ping?
--
Thanks, K
Hello Bernd,
On 29 Nov 13:17, Bernd Schmidt wrote:
> 5. There's a new DECL_TARGET which refers to this list of target
> machines. It's set when creating a child function from e.g. "#pragma acc
> parallel"
Actually, I do not understand, what term `target machine' means here.
Are you talking about
Hello,
On 19 Nov 12:05, Kirill Yukhin wrote:
> Hello,
> On 15 Nov 20:03, Kirill Yukhin wrote:
> > Ping?
> Ping?
Ping?
--
Thanks, K
Hello,
On 19 Nov 12:08, Kirill Yukhin wrote:
> Hello,
> On 15 Nov 20:06, Kirill Yukhin wrote:
> > Ping.
> Ping.
Ping.
--
Thanks, K
Hello,
On 19 Nov 12:12, Kirill Yukhin wrote:
> Hello,
> On 15 Nov 20:08, Kirill Yukhin wrote:
> > > Is it ok for trunk?
> > Ping.
> Ping.
Ping.
--
Thanks, K
Hello,
On 19 Nov 12:11, Kirill Yukhin wrote:
> Hello,
> On 15 Nov 20:07, Kirill Yukhin wrote:
> > > Is it ok for trunk?
> > Ping.
> Ping.
Ping.
--
Thanks, K
Hello,
On 19 Nov 12:14, Kirill Yukhin wrote:
> Hello,
> On 15 Nov 20:09, Kirill Yukhin wrote:
> > > Is it ok for trunk?
> > Ping.
> Ping.
Ping.
--
Thanks, K
Hello,
On 19 Nov 12:14, Kirill Yukhin wrote:
> Hello,
> On 15 Nov 20:10, Kirill Yukhin wrote:
> > > Is it ok to commit to main trunk?
> > Ping.
> Ping.
Ping.
--
Thanks, K
Hello
> Ok for trunk?
Ping?
--
Thanks, K
1 - 100 of 829 matches
Mail list logo
