Ping.
On 17 December 2013 15:35, Michael V. Zolotukhin
michael.v.zolotuk...@gmail.com wrote:
Hi everybody,
Here is a set of patches implementing one more piece of offloading support in
GCC. These three patches allow to build a host binary with target image and
all
tables embedded. Along
Ping.
On 17 December 2013 15:39, Michael V. Zolotukhin
michael.v.zolotuk...@gmail.com wrote:
Hi everybody,
Here is a patch 2/3: Add tables generation.
This patch is just a slightly modified patch sent a couple of weeks ago. When
compiling with '-fopenmp' compiler generates a special
Ping.
On 20 December 2013 20:46, Michael V. Zolotukhin
michael.v.zolotuk...@gmail.com wrote:
This patch seems to make rather too many assumptions about host and
target compilers. Certainly code like this can't go into
target-independent code like lto-wrapper.
That's true. The point of this
Hi Uros, HJ,
I checked expand_movmem_epilogue - it seemingly doesn't have such a
problem, so the patch is ok.
We might want to add similar adjust_automodify_address_nv call to here as well:
if (TARGET_64BIT)
{
dest = change_address (destmem, DImode, destptr);
Adding Ilya.
On 25 October 2013 10:48, Tobias Burnus bur...@net-b.de wrote:
Hi Kirill,
with the current trunk (newst git mirror version), bootstrapping fails
here with the following error. Did you forget to commit one file?
g++ -c -g -DIN_GCC-fno-exceptions -fno-rtti
Michael, why did you change epilogue_size_needed to size_needed
here? It looks wrong to me.
This function was changed in several places and meaning of
'size_needed' and 'epilogue_size_needed' could've been changed. It
needs more careful examination and I'll do it shortly.
Briefly, I
).
On Tue, Aug 6, 2013 at 1:46 AM, Michael Zolotukhin
michael.v.zolotuk...@gmail.com wrote:
There are still some formatting issues (like 8 spaces instead of a
tab, wrong indentation of do-loop and some other places) - to reveal
some of them you could use contrib/check_GNU_style.sh script
There are still some formatting issues (like 8 spaces instead of a
tab, wrong indentation of do-loop and some other places) - to reveal
some of them you could use contrib/check_GNU_style.sh script.
But that was a nitpicking again:) Actually I wanted to ask whether
you're going to use this option
Changes were checked into trunk:
http://gcc.gnu.org/ml/gcc-cvs/2013-07/msg00179.html
Thanks, Kirill
There is a lot of things we can do about string operations, taking
incremental steps is good
plan.
Then my next step will be implementation of vector_loop for memset
with 0. Thanks for the
Ping.
On 2 July 2013 18:37, Michael Zolotukhin michael.v.zolotuk...@gmail.com wrote:
Hi guys,
Thanks for the review and for your responses - please find my answers
below.
Yes, I looked on the patch in detail this week (I am currently on a travel
with
sporadic internet access and my days
, but
without emit-rtl.c changes. Is it ok for trunk?
The patch is bootstrapped and regtested on i386 and x86-64. Specs2000 are also
passing without regressions (I checked only stability, not performance).
Changelog:
2013-07-02 Michael Zolotukhin michael.v.zolotuk...@gmail.com
* config/i386
Ping.
On 20 June 2013 20:56, Michael Zolotukhin
michael.v.zolotuk...@gmail.com wrote:
It seems that one of the tests needed a small fix.
Attached is a corrected version.
On 20 June 2013 17:16, Michael Zolotukhin
michael.v.zolotuk...@gmail.com wrote:
Hi,
I added two tests to verify we
Hi,
I added two tests to verify we generate vector instructions when
vector_loop is used.
Is the patch ok with that change?
Thanks, Michael
On 5 June 2013 18:10, Michael Zolotukhin michael.v.zolotuk...@gmail.com wrote:
I'll prepare some tests shortly,
What about the rest questions?
Thanks
It seems that one of the tests needed a small fix.
Attached is a corrected version.
On 20 June 2013 17:16, Michael Zolotukhin
michael.v.zolotuk...@gmail.com wrote:
Hi,
I added two tests to verify we generate vector instructions when
vector_loop is used.
Is the patch ok with that change
I'll prepare some tests shortly,
What about the rest questions?
Thanks, Michael
On 15 May 2013 19:45, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, May 15, 2013 at 5:47 AM, Michael Zolotukhin
michael.v.zolotuk...@gmail.com wrote:
Hi HJ,
You use Pmode as the largest integer mode. Is word_mode
I agree that it is possible to use define_subst (apart from the fact
that it doesn't support define_insn_and_split yet). It's just that I
think it looks hacky and makes the patterns look
less readable if the reader has to remember that predication is implicit
when a subst_attr is encountered
Unfortunately, that is a strong point against define_subst in my case,
since on arm we have more than 400 predicable patterns, of we which we
might want to modify dozens to perform this cond_exec restriction.
And creating custom subst-attributes for each one would really make
things hard to
As things stand now, if predicable is set to no for a particular
alternative, the value of control_attr is irrelevant, that alternative
will never have a cond_exec version. In your scheme, however,
the presence of subst_predicated triggers the creation of cond_exec
variants for all of the
- What about define_insn_and_split? Currently, we can define predicable
for a define_insn_and_split,
Yes, you're right. Currently define_subst cannot be applied to
define_insn_and_split. That's not implemented yet because I didn't see
a real usages of define_substs with these (though I'm not
...@gmail.com wrote:
On Tue, May 14, 2013 at 7:34 AM, Michael Zolotukhin
michael.v.zolotuk...@gmail.com wrote:
Hi,
I attached an updated version of the patch. Looks like the 64-bit issue is
resolved in it (now a vector mode is explicitly chosen instead of TI- or
another integer mode). Also, some
Ping.
On 9 May 2013 17:07, Michael Zolotukhin michael.v.zolotuk...@gmail.com wrote:
Sweet, I like it…
Thanks!
Who could approve it for commit if it's ok?
Best regards, Michael
On 28 April 2013 23:43, Mike Stump m...@mrs.kithrup.com wrote:
On Apr 26, 2013, at 8:17 AM, Michael Zolotukhin
Sweet, I like it…
Thanks!
Who could approve it for commit if it's ok?
Best regards, Michael
On 28 April 2013 23:43, Mike Stump m...@mrs.kithrup.com wrote:
On Apr 26, 2013, at 8:17 AM, Michael Zolotukhin
michael.v.zolotuk...@gmail.com wrote:
This patch allows to use attributes inside other
for trunk?
gcc/ChangeLog
2013-04-26 Michael Zolotukhin michael.v.zolotuk...@intel.com
* read-rtl.c (copy_rtx_for_iterators): Continue applying iterators
while it has any effect.
--
---
Best regards,
Michael V. Zolotukhin,
Software Engineer
Intel Corporation.
attr.patch
Description
Hi,
Jan, thanks for the review, I hope to prepare an updated version of the patch
shortly. Please see my answers to your comments below.
Uros, there is a question of a better approach for generation of wide moves.
Could you please comment it (see details in bullets 3 and 5)?
1.
+static int
Forgot to add Uros - adding now.
On 18 April 2013 15:53, Michael Zolotukhin
michael.v.zolotuk...@gmail.com wrote:
Hi,
Jan, thanks for the review, I hope to prepare an updated version of the patch
shortly. Please see my answers to your comments below.
Uros, there is a question of a better
with your version of
glibc, and expanded memmov with implementation from this patch?
Michael
On 12 April 2013 12:54, Ondřej Bílka nel...@seznam.cz wrote:
On Thu, Apr 11, 2013 at 04:32:30PM +0400, Michael Zolotukhin wrote:
128 is about upper bound you can expand with sse moves.
Tuning did
thresholds to avoid
performance degradations on small sizes.
Michael
On 10 April 2013 22:53, Ondřej Bílka nel...@seznam.cz wrote:
On Wed, Apr 10, 2013 at 09:53:09PM +0400, Michael Zolotukhin wrote:
Hi, I am writing memcpy for libc. It avoids computed jump and has is
much faster on small strings
Michael Zolotukhin michael.v.zolotuk...@gmail.com
* config/i386/i386-opts.h (enum stringop_alg): Add vector_loop.
* config/i386/i386.c (expand_set_or_movmem_via_loop): Use
adjust_address instead of change_address to keep info about alignment.
(emit_strmov): Remove
infrastructure to allow
emitting of vector moves in movmem expanding - tuning is certainly
possible and needed, but that's out of the scope of the patch.
On 10 April 2013 21:43, Ondřej Bílka nel...@seznam.cz wrote:
On Wed, Apr 10, 2013 at 08:14:30PM +0400, Michael Zolotukhin wrote:
Hi,
This patch adds
Yep, sure. I missed that (*p != NULL) check.
Thanks, Michael
On 29 March 2013 05:15, Segher Boessenkool seg...@kernel.crashing.org wrote:
I'd suggest rewriting this expression in some easier way:
p += (*p == '%' *(p + 1)) ? 2 : 1;
I'd prefer
if (*p == '%')
I'd suggest rewriting this expression in some easier way:
p += (*p == '%' *(p + 1)) ? 2 : 1;
I'd prefer
if (*p == '%')
p++;
p++;
However, that could be only my taste:)
On 26 March 2013 15:10, Maksim Kuznetsov maks.kuznet...@gmail.com
could be copied. Probably, I'll need to implement such
'universal'-move function and stop using gen_strmov, that should solve
the problem.
On 22 March 2013 23:47, H.J. Lu hjl.to...@gmail.com wrote:
On Fri, Mar 22, 2013 at 9:58 AM, Michael Zolotukhin
michael.v.zolotuk...@gmail.com wrote:
You can't
guess it's true that in trunk everything is ok here and the
misaligned case could only come from
ix86_avx256_split_vector_move_misalign - nevertheless, this place
seems to me a bit untidy.
On 21 March 2013 21:27, H.J. Lu hjl.to...@gmail.com wrote:
On Thu, Mar 21, 2013 at 9:36 AM, Michael Zolotukhin
and probably isn't intended for
that. But in this case, it needs some guarding checks I guess.
On 22 March 2013 20:30, H.J. Lu hjl.to...@gmail.com wrote:
On Fri, Mar 22, 2013 at 5:49 AM, Michael Zolotukhin
michael.v.zolotuk...@gmail.com wrote:
Do you have a testcase to show there is a problem
generation of movapd for misaligned operands and enabling
generation of movupd for them.
If the patch is ok, could anyone please commit it? Of course, that
could wait until 4.8 is released.
Bootstrapped and tested on x86_64-unknown-linux-gnu and i686-linux.
Changelog:
2013-03-21 Michael Zolotukhin
help to
make sse.md more compact.
On 7 December 2012 12:49, Marc Glisse marc.gli...@inria.fr wrote:
On Fri, 7 Dec 2012, Michael Zolotukhin wrote:
1) Does the root problem lay in the fact that even for scalar
additions we perform the addition on the whole vector and only then
drop the higher
Hi guys,
Could I ask several questions just to clarify the things up?
1) Does the root problem lay in the fact that even for scalar
additions we perform the addition on the whole vector and only then
drop the higher parts of the vector? I.e. to fix the test from the PR
we need to replace plus on
I didn't find any dump_rtx - instead, I used print_inline_rtx which
seems to be what we need to output to stdout, instead of stderr.
Updated version of the patch is attached. Ok for trunk?
Changelog:
2012-11-30 Michael Zolotukhin michael.v.zolotuk...@intel.com
* Makefile.in: Add target
So, ok for commit this patch?
Changelog:
2012-11-29 Michael Zolotukhin michael.v.zolotuk...@intel.com
* gensupport.c (maybe_eval_c_test): Remove not-null check for expr.
* read-rtl.c (apply_iterators): Initialize condition with instead
of NULL.
On 28 November 2012 23
function maybe_eval_c_test.
What do you think?
Changelog:
2012-11-28 Michael Zolotukhin michael.v.zolotuk...@intel.com
* gensupport.c (add_c_test): Check if expr isn't NULL.
* read-md.c (join_c_conditions): Prefer empty string over NULL.
--
---
Best regards,
Michael V. Zolotukhin
Where was the null condition created in the first place?
The reason it's happening is following. Before introduction of
define_subst, function apply_iterators had the following loop:
condition = NULL;
FOR_EACH_VEC_ELT (iterator_uses, i, iuse)
{
v =
, Michael Zolotukhin wrote:
Where was the null condition created in the first place?
The reason it's happening is following. Before introduction of
define_subst, function apply_iterators had the following loop:
condition = NULL;
FOR_EACH_VEC_ELT (iterator_uses, i, iuse
Thanks for the input, the patch seems to be much more cute now.
Do we still need to play with release/non-release builds, or is it ok
to commit this patch to the trunk as it is?
Changelog:
2012-11-29 Michael Zolotukhin michael.v.zolotuk...@intel.com
* Makefile.in: Add target mddump
Yeah, one or other way to being able to debug what exactly has been
performed during the iterator expansion is certainly desirable for the
future.
We actually have internal machinery for dumping MDs with expanded
iterators and substs, but this looks really kinda hack now.
We're going to
Hi HJ,
The last-year patch is currently almost useless, as efforts needed for
its rebase seem to be almost the same as efforts needed for writing it
from scratch. I hoped to make a patch covering at least subset of
cases, but unfortunately haven't had time even for it yet.
What time do we have
Thanks!
On 9 August 2012 18:36, Kirill Yukhin kirill.yuk...@gmail.com wrote:
Ok.
Checked in:
http://gcc.gnu.org/ml/gcc-cvs/2012-08/msg00231.html
Thanks, K
--
---
Best regards,
Michael V. Zolotukhin,
Software Engineer
Intel Corporation.
Hi,
Here is an obvious fix for a mistake in description of
__builtin_ia32_rdseed_di_step.
Bootstrap and rdseed-* tests are ok.
Ok for commit to trunk?
Changelog entry:
2012-08-10 Michael Zolotukhin michael.v.zolotuk...@intel.com
* config/i386/i386.c (ix86_init_mmx_sse_builtins): Fix
Thanks!
On 10 August 2012 12:40, Kirill Yukhin kirill.yuk...@gmail.com wrote:
OK for mainline.
Thanks!
http://gcc.gnu.org/ml/gcc-cvs/2012-08/msg00264.html
K
--
---
Best regards,
Michael V. Zolotukhin,
Software Engineer
Intel Corporation.
Hi guys,
This patch generalizes recently commited addcarryx-intrinsic so that
it could be generated either via ADCX or common ADC instruction.
ADX-* tests are ok, bootstrap is passed.
Is it ok for trunk?
Changelog entry:
2012-08-09 Michael Zolotukhin michael.v.zolotuk...@intel.com
Hi,
Here is the patch with some obvious fixes. If there are no objections,
could anyone please check it in?
Changelog entry:
2012-08-08 Michael Zolotukhin michael.v.zolotuk...@intel.com
* common/config/i386/i386-common.c (OPTION_MASK_ISA_ADX_SET): New.
(OPTION_MASK_ISA_ADX_UNSET
Hi,
I made a new version of the patch, where I tried to take into account
Uros' remarks - is it ok for trunk?
Bootstrap and new tests are passing, testing is in progress.
Changelog entry:
2012-08-03 Michael Zolotukhin michael.v.zolotuk...@intel.com
* common/config/i386/i386-common.c
Thanks!
On 3 August 2012 17:51, Uros Bizjak ubiz...@gmail.com wrote:
On Fri, Aug 3, 2012 at 3:24 PM, Michael Zolotukhin
michael.v.zolotuk...@gmail.com wrote:
Hi,
I made a new version of the patch, where I tried to take into account
Uros' remarks - is it ok for trunk?
Bootstrap and new
Hi guys,
Here is a third part of patch, refactored by Kirill. This one adds
_addcarryx_u[32|64] intrinsics.
Is it ok?
Changelog entry:
2012-07-31 Michael Zolotukhin michael.v.zolotuk...@intel.com
* common/config/i386/i386-common.c (OPTION_MASK_ISA_ADX_SET): New
Hi,
This patch adds new intrinsics for new ADCX, ADOX, RDSEED and
PREFETCHW instructions, introduced here:
http://software.intel.com/en-us/avx/
Bootstrapped on x86-64, testing is in progress.
Is it ok for trunk?
Changelog entry:
2012-07-17 Michael Zolotukhin michael.v.zolotuk...@intel.com
in the attached
patch).
On 22 December 2011 00:16, Uros Bizjak ubiz...@gmail.com wrote:
On Mon, Dec 19, 2011 at 9:47 AM, Michael Zolotukhin
michael.v.zolotuk...@gmail.com wrote:
What do you mean no tests require it? For instance, all of the ones
that currently pass with with vect_perm
that
vector size also matters, so I undid changes in vect_perm and just add
a vect-size check to the test - could you please check if the changes
are ok?
On 17 December 2011 02:17, Richard Henderson r...@redhat.com wrote:
On 12/16/2011 09:44 AM, Michael Zolotukhin wrote:
Why? SSSE3 *really can
Thanks, Richard!
Is anyone else's approve needed for commit?
Michael
On 19 December 2011 20:55, Richard Henderson r...@redhat.com wrote:
On 12/19/2011 12:47 AM, Michael Zolotukhin wrote:
Ok, those were just attempts to adjust dg-scans in slp-perm-9.c, in
which one more loop was vectorized
11:21 PM, Michael Zolotukhin wrote:
E.g., in vect-114.c we need permutation only for reversing vector
elements, even ssse3 isn't required for it ...
Sure.
while in slp-perm-9 such permutation isn't enough.
Why? SSSE3 *really can* do arbitrary permutation. If you say that
isn't enough
This is vect_perm. Why are you inventing a new one?
As far as I understand, vect_perm is true if target supports at least
some vector-permutation, while vect_any_perm is intended to be true if
arbitrary permutation is supported (like in avx). It was introduced
because vectorization began to
?
On 15 December 2011 22:32, Richard Henderson r...@redhat.com wrote:
On 12/15/2011 10:22 AM, Michael Zolotukhin wrote:
This is vect_perm. Why are you inventing a new one?
As far as I understand, vect_perm is true if target supports at least
some vector-permutation, while vect_any_perm
' is specified, but I think we could return to this
issue later.
Is it ok for trunk?
Changelog:
2011-12-14 Michael Zolotukhin michael.v.zolotuk...@intel.com
* gcc.dg/vect/no-section-anchors-vect-31.c: Adjust array size and test
diag-scans to fix fail on AVX.
* gcc.dg/vect/no-section
Thanks!
Fixed patch is attached.
Any other comments?
Changelog:
2011-12-14 Michael Zolotukhin michael.v.zolotuk...@intel.com
* gcc.dg/vect/no-section-anchors-vect-31.c: Adjust array size and test
diag-scans to fix fail on AVX.
* gcc.dg/vect/no-section-anchors-vect-36.c
' to 'target'. But when wider vectors become
available (512 bit), there will be fails again.
On 12 December 2011 11:46, Jakub Jelinek ja...@redhat.com wrote:
On Mon, Dec 12, 2011 at 11:06:37AM +0400, Michael Zolotukhin wrote:
diff --git a/gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-31.c
b
? I think if we want to keep everything as general as
possible, we should have something like vect_1_vector_size_available,
vect_2_vector_sizes_available, etc.
New changelog:
2011-12-12 Michael Zolotukhin michael.v.zolotuk...@intel.com
* gcc.dg/vect/no-section-anchors-vect-31.c: Adjust
I think there is a difference between different vector sizes, and calling
it vect_X_vector_size_available is not sufficient. Your patch will cause
failures on ARM. It has two vector sizes, 16 and 8 bytes. E.g., vect-33.c
gets vectorized with the default vector size, and the alignment message
Any update?
On 5 December 2011 15:14, Michael Zolotukhin
michael.v.zolotuk...@gmail.com wrote:
Hi Jan,
I debugged the changes, and I think I've hunted down all the bugs.
I slightly refactored the code - now all new SSE-related code is more
localized. Also, I fixed some alignment issues
And even this is insufficient, since you need to distinguish between multiple
integer vector sizes and multiple fp vector sizes, aka AVX vs AVX2.
Should we introduce checks for each possible vector datatype (e.g.
vect_8byte_int_available, vect_16byte_int_available,
vect_32byte_int_available,
Hi,
This patch fixes dg-final scans in tests from vect.exp suite, which
currently fail when avx2 is used.
Ok for trunk?
Changelog:
2011-12-12 Michael Zolotukhin michael.v.zolotuk...@intel.com
* gcc.dg/vect/no-section-anchors-vect-31.c: Adjust diagnostic test to
fix fail
the last version of the patch.
Michael
On 7 December 2011 16:08, Richard Guenther richard.guent...@gmail.com wrote:
On Wed, Dec 7, 2011 at 11:27 AM, Michael Zolotukhin
michael.v.zolotuk...@gmail.com wrote:
Thanks, Richard.
Should somebody else approve the patch or is it ok for commit to trunk
Thanks, Richard.
Should somebody else approve the patch or is it ok for commit to trunk?
On 5 December 2011 18:04, Richard Guenther richard.guent...@gmail.com wrote:
On Mon, Dec 5, 2011 at 2:28 PM, Michael Zolotukhin
michael.v.zolotuk...@gmail.com wrote:
I'd just duplicate the tests you want
On 5 December 2011 10:14, Michael Zolotukhin
michael.v.zolotuk...@gmail.com wrote:
Ok, will several tests with short arrays be enough for that or should
we keep all the original tests plus new ones with longer arrays?
BTW, there is another problem with current tests with short arrays -
scans
Ok, will several tests with short arrays be enough for that or should
we keep all the original tests plus new ones with longer arrays?
Michael
On 4 December 2011 15:44, Richard Guenther richard.guent...@gmail.com wrote:
On Sat, Dec 3, 2011 at 5:54 PM, Michael Zolotukhin
michael.v.zolotuk
to duplicate all of the
tests to check this situation.
On 3 December 2011 18:31, Richard Guenther richard.guent...@gmail.com wrote:
On Fri, Dec 2, 2011 at 6:39 PM, Michael Zolotukhin
michael.v.zolotuk...@gmail.com wrote:
Shouldn't we add a variant for each testcase so that we still
excercise both 128
to use them for testing both
128- and 256- bit vectorization.
Michael
2011/12/2 Richard Guenther richard.guent...@gmail.com:
2011/12/2 Michael Zolotukhin michael.v.zolotuk...@gmail.com:
Hi,
This patch increases array sizes in tests from vect.exp suite, thus
enabling 256-bit vectorization where
.
On 21 November 2011 20:36, Michael Zolotukhin
michael.v.zolotuk...@gmail.com wrote:
Hi,
Continuing investigation of fails on bootstrap I found next problem
(besides the problem with unknown alignment described above): there is
a mess with size_needed and epilogue_size_needed when we generate
Hi,
Continuing investigation of fails on bootstrap I found next problem
(besides the problem with unknown alignment described above): there is
a mess with size_needed and epilogue_size_needed when we generate
epilogue loop which also use SSE-moves, but no unrolled - that's
probably the reason of
I found another bug in current implementation. A patch for it doesn't
cure i686-linux- bootstrap, but fixes fails on some tests (see
attached).
The problem was that we tried to add runtime tests for alignment even
if both SRC and DST had unknown alignment - in this case it could be
impossible to
Hello!
x86-specific part of this patch was committed to the trunk recently.
There is also target-independent part, which covers memset/memcopy for
the smallest sizes (from 1 to ~256 bytes). In contrast to existing
implementation, it has a cost model to choose the fastest move-mode
(which could be
Looks like we have a bootstrap issue, thus sorry if may message may appear
stupid nitpicking: why Zolotukhin Michael instead of Michael Zolotukhin in
the ChangeLog? Is Michael the family name?
Michael is the first name, Zolotukhin - last name. I probably swapped
them accidentally
Any questions on these patches? Are they ok for the trunk?
On 20 October 2011 12:37, Michael Zolotukhin
michael.v.zolotuk...@gmail.com wrote:
And, finally, part with the tests.
On 20 October 2011 12:36, Michael Zolotukhin
michael.v.zolotuk...@gmail.com wrote:
Back-end part of the patch
Middle-end part of the patch is attached.
On 20 October 2011 12:34, Michael Zolotukhin
michael.v.zolotuk...@gmail.com wrote:
I fixed the tests as well as updated my branch and fixed introduced
during this process bugs.
Here is fixed complete patch (other parts will be sent in consequent
time and uses cost-models to choose between aligned and unaligned
vector or not-vector move-modes.
Build and 'make check' was tested - in 'make check' there is a fail,
that would be cured when complete patch is applied.
On 27 September 2011 18:44, Michael Zolotukhin
michael.v.zolotuk...@gmail.com
were carried out to find threshold
values in cost models).
If the size is unknown at all, this inlining doesn't work (i.e glibc is called).
On 28 September 2011 15:55, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Sep 28, 2011 at 04:41:47AM -0700, Andi Kleen wrote:
Michael Zolotukhin
Do you know glibc version numbers when
the optimized string functions was introduced?
Afaik, it's 2.13.
I also compared my implementation to 2.13.
(I worry about the tables in i386.c deciding what strategy to use for block of
given size. This is more or less unrelated to the actual patch)
Yep, the threshold values I mentioned above are the values in these
tables. Even with fast glibs there are some cases when inlining is
profitable (e.g.
It appears that part 1 of the patch wasn't really attached.
Thanks, resending.
memfunc-mid.patch
Description: Binary data
You could add a check to configure and generate based on that?
Do you mean check if glibc is newer than 2.13?
I think that when new glibc version is released, the tables should be
re-examined anyway - we shouldn't just stop inlining, or stop
generating libcalls.
BTW I know that the tables need
significant changes in them.
On 29 September 2011 01:51, Jack Howarth howa...@bromo.med.uc.edu wrote:
On Wed, Sep 28, 2011 at 05:33:23PM +0400, Michael Zolotukhin wrote:
It appears that part 1 of the patch wasn't really attached.
Thanks, resending.
Michael,
Did you bootstrap with --enable
Sorry what I meant is that it would be bad if -mtune=corei7(-avx)? was
slower than generic.
For now, -mtune=corei7 is triggering use of generic cost-table (I'm
not sure about corei7-avx, but assume the same) - so it won't be
slower.
Adding new tables shouldn't be very difficult, even if they
Ping.
On 18 July 2011 15:00, Michael Zolotukhin
michael.v.zolotuk...@gmail.com wrote:
Here is a summary - probably, it doesn't cover every single piece in
the patch, but I tried to describe the major changes. I hope this will
help you a bit - and of course I'll answer your further questions
Any updates/questions on this?
On 18 July 2011 15:00, Michael Zolotukhin
michael.v.zolotuk...@gmail.com wrote:
Here is a summary - probably, it doesn't cover every single piece in
the patch, but I tried to describe the major changes. I hope this will
help you a bit - and of course I'll answer
Here is a summary - probably, it doesn't cover every single piece in
the patch, but I tried to describe the major changes. I hope this will
help you a bit - and of course I'll answer your further questions if
they appear.
The changes could be logically divided into two parts (though, these
parts
Resending in plain text:
On 11 July 2011 23:50, Michael Zolotukhin
michael.v.zolotuk...@gmail.com wrote:
The attached patch enables use of vector instructions in memmov/memset
expanding.
New algorithm for move-mode selection is implemented for move_by_pieces,
store_by_pieces.
x86
93 matches
Mail list logo
