> /* Program behavior changed, original promoted (and inlined) target is not
> hot any more. Will avoid promote the original target. */
> if (total >= info->first * 0.5)
> return false;
This part is still not clear: Difference between OLD_INFO and INFO,
factor 0.5 comes from where etc.
> g
This patch to the Go frontend fixes the test for whether a constant
argument to the builtin function make is too large. Bootstrapped and
ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline.
Will commit to 4.8 when the branch opens.
Ian
diff -r 5aa7a9d25a56 go/expressions.cc
---
The Go frontend has a minor type error: it inherited the types of
operands of logical operators (&& and ||) from the context. This patch
fixes the bug. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline. Will commit to 4.8
branch when it reopens.
Ian
diff -r
On 08/05/13 02:08, Zhenqiang Chen wrote:
Hi
The patch reassociates X == CST1 || X == CST2 if popcount (CST2 - CST1) == 1
into ((X - CST1) & ~(CST2 - CST1)) == 0.
Bootstrap on x86-64 and ARM chromebook.
No make check regression on x86-64 and panda board.
For some targets/options, the "(X == CST
On Wed, Oct 9, 2013 at 5:18 PM, David Malcolm wrote:
> coverage_init allocates da_file_name using XNEWVEC, but it is never
> freed. This shows up as a slow memory leak in my JIT code when
> repeatedly invoking the compiler code within a single process.
>
> This patch frees it in coverage_finish w
On Wed, 9 Oct 2013, David Malcolm wrote:
> This patch adds an "--enable-host-shared" option throughout the various
> configure/Make machinery for host code, adding "-fPIC" where appropriate
> when enabled.
Please document this in install.texi (even if it isn't particularly useful
at the stage wh
Ok (please add a short comment on the decl_lineno which encodes
discriminator in it).
David
On Wed, Oct 9, 2013 at 4:57 PM, Dehao Chen wrote:
> In legacy AutoFDO, callsite is represented as a (lineno, callee_name)
> pair because there could be multiple calls in one line. However, as we
> enhance
gcc/
Patch autogenerated by refactor_ipa_passes.py from
https://github.com/davidmalcolm/gcc-refactoring-scripts
revision 9518113a5604ede755ea1dc1f073a1863f5a6de5
* ipa-cp.c (pass_ipa_cp): Convert to new API for IPA passes.
* ipa-devirt.c (pass_ipa_devirt):
r201505 and r201508 converted passes to C++ classes, with the gate
and execute hooks becoming virtual functions, allowing for the
possibility of storing state within pass instances, rather than
statically allocating it. This has benefits for state-isolation,
for example within my JIT branch, which
* passes.c (ipa_opt_pass_d::generate_summary): New.
(ipa_opt_pass_d::write_summary): New.
(ipa_opt_pass_d::read_summary): New.
(ipa_opt_pass_d::write_optimization_summary): New.
(ipa_opt_pass_d::read_optimization_summary): New.
(ipa_opt_pass_d::stmt_f
My JIT branch requires embedding GCC's code as a shared library on the
host. To do requires building the host code as position-independent,
which unfortunately incurs a small speed hit.
Hence we need a configuration option, so that you can opt-in to
position-independent host code.
This patch add
On 10/09/2013 01:43 PM, Jakub Jelinek wrote:
Perhaps DECL_TEMPLATE_INFO check could also be less expensive to be done
before calling decl_maybe_constant_var_p or undeduced_auto_decl ?
Sure.
+ DECL_LOCAL_FUNCTION_P (fndecl) = 1;
This should be set by pushdecl_maybe_friend_1, so I don
coverage_init allocates da_file_name using XNEWVEC, but it is never
freed. This shows up as a slow memory leak in my JIT code when
repeatedly invoking the compiler code within a single process.
This patch frees it in coverage_finish with XDELETEVEC (and NULLs it to
be sure).
Bootstrapped and reg
On 10/08/2013 03:53 PM, Jakub Jelinek wrote:
case OMP_CLAUSE_REDUCTION:
- gcc_assert (!is_invisiref_parm (OMP_CLAUSE_DECL (stmt)));
+ if (is_invisiref_parm (OMP_CLAUSE_DECL (stmt)))
+ {
+ *walk_subtrees = 0;
+ if (OMP_CLAUSE_REDUCTION_INIT (stmt))
+
ipa-inline.c:ipa_inline leaks "order" when optimizations are disabled.
This potentially becomes significant in my JIT branch since the
compilation code could be invoked many times within one process.
Bootstrapped and regtested against trunk on x86_64-unknown-linux.
OK for trunk?
(Seen using valg
In Go a type conversion of a constant is not necessarily itself a
constant, as in []byte(nil). This patch fixes the Go frontend to
recognize that. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline. Will commit to 4.8
branch when it reopens.
Ian
diff -r a6f45
In legacy AutoFDO, callsite is represented as a (lineno, callee_name)
pair because there could be multiple calls in one line. However, as we
enhanced the debug info by assigning discriminators for each function
call in the same line, callee_name is not needed when indexing the
callsite.
This patch
ok.
David
On Wed, Oct 9, 2013 at 4:47 PM, Dehao Chen wrote:
> This patch updates the AutoFDO profile propagation of equivalence
> class: instead of looking just immediate dominators, traverse all
> dominators. This helps improving profile accuracy.
>
> Bootstrapped and passed regression test.
>
This patch updates the AutoFDO profile propagation of equivalence
class: instead of looking just immediate dominators, traverse all
dominators. This helps improving profile accuracy.
Bootstrapped and passed regression test.
OK for google-4_8 branch?
Thanks,
Dehao
Index: gcc/auto-profile.c
=
Hi,
This is a follow-up to the recent patch that fixed constant permute
control vectors for little endian. When the control vector is constant,
we can adjust the constant and use a vperm without increasing code size.
When the control vector is unknown, however, we have to generate two
additional
Hi Richard,
This patch implements a workaround for errors on the PMC-Sierra RM7000 cpu
while executing the dmult or dmultu instruction. The workaround is to insert
three nops after the dmult/dmultu.
Does this look okay to commit?
Thanks,
Catherine
gcc/
2013-10-09 Catherine Moore
On Wed, Oct 09, 2013 at 11:51:30PM +0200, Tobias Burnus wrote:
> A rather obvious fix; the memory is freed by the caller
> (gfc_simplify_compiler_options). It is unlikely that the compiler has no
> arguments as the driver tends to send some, e.g. "-mtune=generic
> -march=x86-64" on my system. Ho
This patch to the Go frontend and libgo fixes complex division of NaN /
0. Go expects that to produce NaN. When using libgcc it could produce
Inf. Specifically NaN+1i / 0+0i produced NaN+Infi, which by the rules
of C99 Annex G is Inf. This may be correct for C, but it's not correct
for Go. Boo
Hi,
This patch is a first small sample of dejagnu-ization of my ARM Neon
intrinsics tests.
It's derived from my previous work at
http://gitorious.org/arm-neon-tests/arm-neon-tests which supports all
the ARM intrinsics, with executable tests. As I have to manually
transform each test (to include t
On 10/09/2013 03:29 AM, Kirill Yukhin wrote:
> Here's 14th subpatch. It introduces VI48F_256_512 iterator.
Ok.
r~
On 10/09/2013 03:29 AM, Kirill Yukhin wrote:
> Here's 13th subpatch. It introduces VI4_AVX iterator.
Ok.
r~
On 10/09/2013 03:28 AM, Kirill Yukhin wrote:
> Here's 12th subpatch. It introduces VF_512 and VI_512 iterators.
Ok.
r~
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 for TARGET_AVX512F even when
> TARGET_FMA
> +;; and TARGET_FMA4 are both false.
How do you force an evex encoding of the instruc
A rather obvious fix; the memory is freed by the caller
(gfc_simplify_compiler_options). It is unlikely that the compiler has no
arguments as the driver tends to send some, e.g. "-mtune=generic
-march=x86-64" on my system. However, it is better to be safe than sorry.
Build and regtested on x86
On 10/09/2013 03:27 AM, Kirill Yukhin wrote:
> Here's 10th subpatch. It introduces VI248_AVX2_8_AVX512F and VI124_256_48_512
> iterators.
Ok.
r~
> 2013-10-09 Sterling Augustine
>
> * dwarf2out.c (include_pubname_in_output): Add conditional on
> is_declaration_die
> and debug_generate_pubnames.
OK for google 4.8 branch. Thanks!
-cary
On 10/09/2013 03:27 AM, Kirill Yukhin wrote:
> Here's 9th subpatch. It extends VI124_AVX2_48 and VI8F iterators.
Ok.
r~
On 10/09/2013 03:27 AM, Kirill Yukhin wrote:
> Here's 8th subpatch. It extends VI48 and VI48_AVX2 iterators.
Ok.
r~
On 10/09/2013 03:26 AM, Kirill Yukhin wrote:
> Here's 7th subpatch. It extends VI4 and VI8 iterators.
Ok.
r~
On 10/09/2013 03:26 AM, Kirill Yukhin wrote:
> Here's 6th subpatch. It extends VI2 and VI124 iterators.
Ok.
r~
On 10/09/2013 02:18 PM, Andrew MacLeod wrote:
On 10/09/2013 02:15 PM, Andrew MacLeod wrote:
Fair enough. I'll adjust... the front end files which use that
routine will just have to include gimplify.h
Unless maybe we should expand the gimplify module to have a
gimplfy-fe.[ch] which includ
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 exactly one thing. Congratulations.
Ok.
r~
On 10/09/2013 03:25 AM, Kirill Yukhin wrote:
> Here's 4th subpatch. It extends V iterator.
And much much more that's totally unrelated to changing V.
That said, I didn't see anything wrong in there.
Ok.
r~
On 10/09/2013 03:24 AM, Kirill Yukhin wrote:
> Here's 3rd subpatch. It extends VF1 and VI iterators.
Ok.
r~
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.
Ok.
r~
Also note that this patch needs to add testcases to the testsuite
(gcc/testsuite/c-c++-common/, probably) testing what cases generate
warnings with the new option and what cases don't.
--
Joseph S. Myers
jos...@codesourcery.com
On Wed, 9 Oct 2013, Joshua J Cogliati wrote:
> Because this changes -Wextra, when compiling with -Werror and -Wextra,
> some code will not compile now. The code in gcc that this occurred in
> was changed to use explicit casts. The patch would be shorter if
I think those changes should be submit
On Wed, Oct 9, 2013 at 6:23 PM, Richard Henderson wrote:
> This doesn't seem right at all.
>
> The bug is that I gets set to UINT64_MAX, right? Where's the
> incorrect conversion from int to __int128_t? Surely you can
Please see Comment #5 of PR58542:
--cut here--
The problem actually starts
On 08/21/13 03:21, Andreas Krebbel wrote:
[RFC] Allow functions calling mcount before prologue to be leaf functions
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00993.html
I don't think this is necessarily correct for all targets. ISTM the
ability to consider a function calling mcount as a leaf
On 09/28/13 09:30, Mikael Pettersson wrote:
This patch fixes PR58369, an ICE in subreg_get_info when compiling
boost for m68k-linux.
choose_reload_regs attempts to reload a DFmode (8-byte) reg, finds
an XFmode (12-byte) reg in "last_reg", and calls subreg_regno_offset
with these two modes and a
On 10/08/13 21:39, Zhenqiang Chen wrote:
I'll go ahead and pull the common bits into a single function and commit on
Zhenqiang's behalf.
Thank you!
No problem. If you think you'll be contributing regularly, you might
want to go ahead and ask for write-after-approval privileges.
jeff
On 09/30/13 03:29, Zhenqiang Chen wrote:
Hi,
The patch enhances phiopt to handle cases like:
if (a == 0 && (...))
return 0;
return a;
Boot strap and no make check regression on X86-64 and ARM.
Is it OK for trunk?
Thanks!
-Zhenqiang
ChangeLog:
2013-09-30 Zhenqiang Chen
Hi Cary,
The enclosed patch stops declaration dies from generating
gnu-pubnames. Declaration dies don't include enough information to be
useful to gdb, so it has to scan all the entries in the index until it
finds a definition. Not including declarations prevents this problem.
Google ref: b/10191
On 9 October 2013 16:15, Jakub Jelinek wrote:
> On Wed, Oct 09, 2013 at 04:12:21PM +0100, Jonathan Wakely wrote:
>> On 9 October 2013 15:26, Marcus Shawcroft wrote:
>> > The test case add here:
>> >
>> > http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00474.html
>> >
>> > Introduced an unprototyped ca
On 10/09/2013 02:15 PM, Andrew MacLeod wrote:
On 10/09/2013 01:48 PM, Richard Biener wrote:
Andrew MacLeod wrote:
On 10/08/2013 06:22 AM, Richard Biener wrote:
unvisit_body isn't generic enough to warrant moving out of gimplify.c
(the only user).
Bah, now I remember.. so there *are* other us
On 10/09/2013 01:48 PM, Richard Biener wrote:
Andrew MacLeod wrote:
On 10/08/2013 06:22 AM, Richard Biener wrote:
unvisit_body isn't generic enough to warrant moving out of gimplify.c
(the only user).
Bah, now I remember.. so there *are* other users.. this routine is
called from various front
This patch simply moves std_gimplify_va_arg_expr() and the related
build_va_arg_indirect_ref to gimplify.c where I think it belongs.
It also moves gimple_fold_indirect_ref out of gimplfy.c and into
gimple-fold.c.
bootstraps on x86_64-unknown-linux-gnu... regressions running. OK?
Andrew
* b
On Wed, Oct 9, 2013 at 4:11 AM, Richard Biener
wrote:
> On Tue, Oct 8, 2013 at 11:04 PM, Easwaran Raman wrote:
>> In cfgexpand.c, variables in non-overlapping lexical scopes are
>> assigned same stack locations at -O1 and above. At -O0, this is
>> attempted only if the size of the stack objects i
Andrew MacLeod wrote:
>On 10/08/2013 06:22 AM, Richard Biener wrote:
>>
>> unvisit_body isn't generic enough to warrant moving out of gimplify.c
>> (the only user).
>
>Bah, now I remember.. so there *are* other users.. this routine is
>called from various front ends.. fortran, c-family and cp all
On Wed, Oct 09, 2013 at 10:47:22AM -0400, Jason Merrill wrote:
> On 10/07/2013 07:02 AM, Jakub Jelinek wrote:
> >duplicates anywhere, but during error diagnostics. Without those two decl.c
> >hunks (either of them), pushdecl will sometimes return a different decl from
> >the original or error_mark
On 10/08/2013 11:37 AM, Uros Bizjak wrote:
>
> As shown in the attached testcase, arguments of various __atomic
> builtins should be converted as signed, so the immediates get properly
> extended.
>
> 2013-10-08 Uros Bizjak
>
> * optabs.c (maybe_emit_atomic_exchange): Convert operands as
On Wed, Oct 9, 2013 at 11:37 AM, Andrew MacLeod wrote:
> bootstraps on x86_64-unknown-linux-gnu, regressions test are still running.
> OK?
Sure.
On 10/08/2013 06:22 AM, Richard Biener wrote:
unvisit_body isn't generic enough to warrant moving out of gimplify.c
(the only user).
Bah, now I remember.. so there *are* other users.. this routine is
called from various front ends.. fortran, c-family and cp all call it.
That is why I wanted
Most of loop-doloop.c is wrapped by
#ifdef HAVE_doloop_end
<...>
#endif
so on my bootstraps/builds, it doesn't exercise the code. It was
pointed out to me the restructuring broke this file on some targets.
This should fix it by calling the refactored get_max_loop_iterations()
function. cross
On Wed, Oct 09, 2013 at 04:12:21PM +0100, Jonathan Wakely wrote:
> On 9 October 2013 15:26, Marcus Shawcroft wrote:
> > The test case add here:
> >
> > http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00474.html
> >
> > Introduced an unprototyped call to abort() resulting in failures due to
> > unexepe
Ping.
On 03 Oct 20:05, Ilya Tocar wrote:
> On 26 Sep 21:21, Ilya Tocar wrote:
> > On 25 Sep 15:48, Richard Biener wrote:
> > > On Wed, Sep 25, 2013 at 3:29 PM, Ilya Tocar
> > > wrote:
> > > > On 24 Sep 11:02, Richard Biener wrote:
> > > >> On Mon, Sep 23, 2013 at 3:29 PM, Ilya Tocar
> > > >> w
On 9 October 2013 15:26, Marcus Shawcroft wrote:
> The test case add here:
>
> http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00474.html
>
> Introduced an unprototyped call to abort() resulting in failures due to
> unexepected warnings in aarch64-none-elf cross testing.
>
> Committed to trunk as obvi
On 10/07/2013 07:02 AM, Jakub Jelinek wrote:
duplicates anywhere, but during error diagnostics. Without those two decl.c
hunks (either of them), pushdecl will sometimes return a different decl from
the original or error_mark_node, and the original fndecl passed to it has
ggc_free called on it, t
Hi,
On 10/09/2013 03:56 PM, Jason Merrill wrote:
On 10/08/2013 07:03 PM, Paolo Carlini wrote:
.. a curiosity: the cp_parser_commit_to_tentative_parse at the end of
cp_parser_pseudo_destructor_name, which didn't exist in 4.6.x and we can
consider the root of this issue, is also my fault:
h
OK.
Jason
Hi all,
I've committed this trivial patch as r203322.
It moves the comment for the arm_early_load_addr_dep from above the #includes in
the file to above the function definition.
Thanks,
Kyrill
2013-10-09 Kyrylo Tkachov
* config/arm/aarch-common.c (arm_early_load_addr_dep):
Place c
The test case add here:
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00474.html
Introduced an unprototyped call to abort() resulting in failures due to
unexepected warnings in aarch64-none-elf cross testing.
Committed to trunk as obvious.
Cheers
/Marcus
2013-10-09 Marcus Shawcroft
On 10/08/2013 07:03 PM, Paolo Carlini wrote:
.. a curiosity: the cp_parser_commit_to_tentative_parse at the end of
cp_parser_pseudo_destructor_name, which didn't exist in 4.6.x and we can
consider the root of this issue, is also my fault:
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg02246.h
Hi!
I've noticed that this testcase doesn't clean up after itself.
Fixed thusly, committed as obvious to trunk.
2013-10-09 Jakub Jelinek
* gcc.dg/vect/bb-slp-31.c: Add cleanup-tree-dump.
--- gcc/testsuite/gcc.dg/vect/bb-slp-31.c.jj2013-08-30 14:38:40.0
+0200
+++ gcc/test
> Before merging the insn reservations, I need to compare the latency values
> for bdver1 and bdver3. I know that they are different for some of the
> instructions.
> In that case, the merging should prop up another subset of latency
> differences. I would like to keep these insn reservations i
> Well, ok. Please adjust the comment
>
> + /* Different fields of the same record type cannot overlap, unless
> they +are both bitfields and we are at the RTL level. */
>
> to sth like
>
> ??? Bitfields can overlap at RTL level so punt if we end up at
> them.
>
> or s
== Administrivia ==
This is my first patch. I have emailed in the signed copyright transfer
documents already.
== Description ==
This patch is a fix for Bug 53001
As required by the C and C++ standards, gcc automatically converts
floating point numbers to lower precision or integer values. Si
On 8 October 2013 17:45, Alex Velenko wrote:
>
> 2013-10-08 Alex Velenko
>
> * gcc.target/aarch64/vclz.c: New testcase.
>
> gcc/
>
> 2013-10-08 Alex Velenko
>
> * config/aarch64/arm_neon.h (vclz_s8): Asm replaced with C
> (vclz_s16): Likewise.
>
On Wed, Oct 9, 2013 at 1:36 PM, Eric Botcazou wrote:
>> In my opinion the MEM_EXPR is "wrong", as it is supposed to be
>> the tree equivalent of the memory access. At gimple level we
>> handle accesses at bit-granularity so bit-accesses are fine.
>> Not so at RTL level it seems.
>>
>> [this also
On 8 October 2013 17:35, Alex Velenko wrote:
> 2013-10-08 Alex Velenko
>
> * gcc.target/aarch64/vadd_f64.c: New testcase.
> * gcc.target/aarch64/vsub_f64.c: New testcase.
>
> gcc/
>
> 2013-10-08 Alex Velenko
>
> * config/aarch64/arm_neon.h (vadd_f64): Implementation
On 8 October 2013 17:25, Alex Velenko wrote:
> gcc/testsuite/
>
> 2013-09-10 Alex Velenko
>
> * gcc.target/aarch64/vdiv_f.c: New testcase.
>
> gcc/
>
> 2013-09-10 Alex Velenko
>
> * config/aarch64/arm_neon.h (vdiv_f64): Added.
OK. I fixed the date format for the pro
Hi!
On Tue, 8 Oct 2013 17:24:14 +0200, Jakub Jelinek wrote:
> These tests were expecting 5 loopfn matches, 3 on the fn definition, one
> as GOMP_parallel_start argument and one called in between
> GOMP_parallel_start and GOMP_parallel_end. But the new API is
> to call GOMP_parallel with the func
> In my opinion the MEM_EXPR is "wrong", as it is supposed to be
> the tree equivalent of the memory access. At gimple level we
> handle accesses at bit-granularity so bit-accesses are fine.
> Not so at RTL level it seems.
>
> [this also shows we probably should lower bit-granular accesses
> at t
Hi,
this is a completely different approach at fixing the bug, which overall
I like better.
In this case most of the patch touches cp_parser_decltype_expr: instead
of using cp_parser_postfix_expression only for member access
expressions, we accept all its valid return values (still identifyi
On Tue, Oct 8, 2013 at 11:04 PM, Easwaran Raman wrote:
> In cfgexpand.c, variables in non-overlapping lexical scopes are
> assigned same stack locations at -O1 and above. At -O0, this is
> attempted only if the size of the stack objects is above a threshold
> (32). The rationale is at -O0, more va
On Wed, Oct 9, 2013 at 1:31 AM, Andrew MacLeod wrote:
> On 10/08/2013 07:44 AM, Andrew MacLeod wrote:
>>
>> On 10/08/2013 06:22 AM, Richard Biener wrote:
>>>
>>> graphite.h should be unnecessary with moving the pass struct like you
>>> did for other loop opts. Likewise tree-parloops.h (well, ok,
On 8 October 2013 17:10, Alex Velenko wrote:
> gcc/testsuite/
>
> 2013-10-08 Alex Velenko
>
> * gcc.target/aarch64/vneg_f.c: New testcase.
> * gcc.target/aarch64/vneg_s.c: New testcase.
>
> gcc/
>
> 2013-10-08 Alex Velenko
>
> * config/aarch64/arm_neon.h (vneg_f32):
On Tue, Oct 8, 2013 at 7:52 PM, Eric Botcazou wrote:
>> Probably because the actual accesses may overlap if we choose to
>> perform a bigger access.
>
> Nope, simply because they share a byte.
>
>> The same can happen if we for struct { char c1; char c2; } perform
>> an HImode access in case the t
On 01/10/13 11:15, Marcus Shawcroft wrote:
On 30 September 2013 14:23, Renlin Li wrote:
OK for trunk?
Kind regards,
Renlin Li
gcc/ChangeLog:
2013-09-30 Renlin Li
* config/arm/arm.c (arm_output_mi_thunk): Use plus_constant.
OK
/Marcus
Hi Renlin,
Richard Earnshaw also ok'd this p
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,
> 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 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 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 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 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 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 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 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 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 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 6th subpatch. It extends VI2 and VI124 iterators.
Is it Ok?
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spec 2
1 - 100 of 115 matches
Mail list logo
