Ping.
On 20 December 2013 20:46, Michael V. Zolotukhin
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 patch was to show what is
Ping.
On 17 December 2013 15:39, Michael V. Zolotukhin
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 symbol, containing
> addresses
Ping.
On 17 December 2013 15:35, Michael V. Zolotukhin
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 with patches for libgomp
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);
emit_
Adding Ilya.
On 25 October 2013 10:48, Tobias Burnus 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
> -fasynchronous-unwind
> 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 significan
id).
>
> On Tue, Aug 6, 2013 at 1:46 AM, Michael Zolotukhin
> 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_styl
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 fo
> 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 fo
Ping.
On 2 July 2013 18:37, Michael Zolotukhin 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
some tests to measure performance - whether
these tests are Specs or some others.
I attached the updated patch - it's the same as the previous, 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 wit
Ping.
On 20 June 2013 20:56, Michael Zolotukhin
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
> wrote:
>> Hi,
>> I added two tests to verify we generate vector instructions
It seems that one of the tests needed a small fix.
Attached is a corrected version.
On 20 June 2013 17:16, Michael Zolotukhin
wrote:
> Hi,
> I added two tests to verify we generate vector instructions when
> vector_loop is used.
> Is the patch ok with that change?
>
> Thanks
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 wrote:
> I'll prepare some tests shortly,
> What about the rest questions?
>
> Thanks, Michael
&
I'll prepare some tests shortly,
What about the rest questions?
Thanks, Michael
On 15 May 2013 19:45, H.J. Lu wrote:
> On Wed, May 15, 2013 at 5:47 AM, Michael Zolotukhin
> wrote:
>> Hi HJ,
>>> You use Pmode as the largest integer mode. Is word_mode better
>>&g
> 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 encounte
> 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 triggers the creation of cond_exec
> variants for all of the alternative
> 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
> - 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
Hi Kyrylo, Richard,
> What would be the function of (set_attr "ds_predicable" "yes") ?
> Doesn't the use of already trigger the substitution?
To use define subst one doesn't need to write (set_attr
"ds_predicable" "yes") - it's triggered by mentioning any of connected
subst-attributes in the patt
Ping.
On 9 May 2013 17:07, Michael Zolotukhin 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 wrote:
>> On Apr 26, 2013, at 8:17 AM, Michael Zolotukhin
>
:
> On Tue, May 14, 2013 at 7:34 AM, Michael Zolotukhin
> 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, so
> 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 wrote:
> On Apr 26, 2013, at 8:17 AM, Michael Zolotukhin
> wrote:
>> This patch allows to use attributes inside other attributes in MD-files.
kinds of iterators and it could be very useful
when several different substs are applied to the same pattern.
The patch is regtested and bootstrapped on i386 and x86_64, and tested on
Specs2k, 2k6.
Is it ok for trunk?
gcc/ChangeLog
2013-04-26 Michael Zolotukhin
* 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: Binary data
Forgot to add Uros - adding now.
On 18 April 2013 15:53, Michael Zolotukhin
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 approach fo
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 sma
ibcall with your version of
glibc, and expanded memmov with implementation from this patch?
Michael
On 12 April 2013 12:54, Ondřej Bílka 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.
>> &g
ely should adjust thresholds to avoid
performance degradations on small sizes.
Michael
On 10 April 2013 22:53, Ondřej Bílka 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
>
ble.
What I did in this patch is introducing some 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 wrote:
> On Wed, Apr 10, 2013 at 08:14:30PM +04
ngelog entry:
2013-04-10 Michael Zolotukhin
* 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.
Yep, sure. I missed that (*p != NULL) check.
Thanks, Michael
On 29 March 2013 05:15, Segher Boessenkool wrote:
>> I'd suggest rewriting this expression in some easier way:
>> p += (*p == '%' && *(p + 1)) ? 2 : 1;
>>
>> I'd prefer
>> if (*p == '%')
>> 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 wrote:
>> Thanks for the
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 wrote:
> On Fri, Mar 22, 2013 at 9:58 AM, Michael Zolotukhin
> wrote:
>>> You can't use
7;t used for such cases before 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 wrote:
> On Fri, Mar 22, 2013 at 5:49 AM, Michael Zolotukhin
> wrote:
>>> Do you have a testcase to show there is a pro
ing some function in a wrong way.
So, I 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 wrote:
> On Thu, Mar 2
he condition, thus
preventing 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.
could help to
make sse.md more compact.
On 7 December 2012 12:49, Marc Glisse 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
>>
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 v
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
* Makefile.in: Add target mddump, build/genmdd
So, ok for commit this patch?
Changelog:
2012-11-29 Michael Zolotukhin
* 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:46, Michael
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
* Makefile.in: Add target mddump, build/genmddump.o. Extend
> Well, there does seem to be a mistake -- the use of NULL in the first
> place. It seems to me that the easiest fix is
>
> condition = "";
>
> right at the beginning.
Yep, that'll work too, you're right.
On 28 November 2012 22:36, Richard Henderson wr
> 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 = iuse->iterator->cu
probably need to remove similar check from function maybe_eval_c_test.
What do you think?
Changelog:
2012-11-28 Michael Zolotukhin
* gensupport.c (add_c_test): Check if expr isn't NULL.
* read-md.c (join_c_conditions): Prefer empty string over NULL.
--
---
Best regards,
Mic
>> 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
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 for
Thanks!
On 10 August 2012 12:40, Kirill Yukhin 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,
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
* config/i386/i386.c (ix86_init_mmx_sse_builtins): Fix description of
Thanks!
On 9 August 2012 18:36, Kirill Yukhin 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 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
* config/i386/adxintrin.h: Remove
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
* common/config/i386/i386-common.c (OPTION_MASK_ISA_ADX_SET): New.
(OPTION_MASK_ISA_ADX_UNSET): Likewise
Thanks!
On 3 August 2012 17:51, Uros Bizjak wrote:
> On Fri, Aug 3, 2012 at 3:24 PM, Michael Zolotukhin
> 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
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
* common/config/i386/i386-common.c (OPTION_MASK_ISA_ADX_SET)
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
* common/config/i386/i386-common.c (OPTION_MASK_ISA_ADX_SET): New.
(OPTION_MASK_ISA_ADX_UNSET): Likewise
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
* common/config/i386
ng changes in the attached
patch).
On 22 December 2011 00:16, Uros Bizjak wrote:
> On Mon, Dec 19, 2011 at 9:47 AM, Michael Zolotukhin
> wrote:
>>> What do you mean no tests require it? For instance, all of the ones
>>> that currently pass with with vect_perm?
>
Thanks, Richard!
Is anyone else's approve needed for commit?
Michael
On 19 December 2011 20:55, Richard Henderson 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 vect
ectorization of this loop - it seems 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 wrote:
> On 12/16/2011 09:44 AM, Michael Zolotukhin wrote
ote:
> On 12/15/2011 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? S
d complicated,
as they don't reflect the real reason.
Ok with such changes?
On 15 December 2011 22:32, Richard Henderson 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_pe
> 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 occu
Thanks!
Fixed patch is attached.
Any other comments?
Changelog:
2011-12-14 Michael Zolotukhin
* 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: Ditto.
* gcc.dg/vect
). There are still fails when
'-mprefer-avx128' is specified, but I think we could return to this
issue later.
Is it ok for trunk?
Changelog:
2011-12-14 Michael Zolotukhin
* gcc.dg/vect/no-section-anchors-vect-31.c: Adjust array size and test
diag-scans to fix fail on AV
> 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,
Any update?
On 5 December 2011 15:14, Michael Zolotukhin
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.
> Please f
> 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 messag
t-specific? 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
* gcc.dg/vect/no-section-anchors-vect-31.c: Adjust diagnostic test to
nge 'xfail' to 'target'. But when wider vectors become
available (512 bit), there will be fails again.
On 12 December 2011 11:46, Jakub Jelinek wrote:
> On Mon, Dec 12, 2011 at 11:06:37AM +0400, Michael Zolotukhin wrote:
> diff --git a/gcc/testsuite/gcc.dg/vect/n
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
* gcc.dg/vect/no-section-anchors-vect-31.c: Adjust diagnostic test to
fix fail on AVX.
* gcc.dg/vect/no
ommit the last version of the patch.
Michael
On 7 December 2011 16:08, Richard Guenther wrote:
> On Wed, Dec 7, 2011 at 11:27 AM, Michael Zolotukhin
> wrote:
>> Thanks, Richard.
>> Should somebody else approve the patch or is it ok for commit to trunk?
>
> It's ok
Thanks, Richard.
Should somebody else approve the patch or is it ok for commit to trunk?
On 5 December 2011 18:04, Richard Guenther wrote:
> On Mon, Dec 5, 2011 at 2:28 PM, Michael Zolotukhin
> wrote:
>>> I'd just duplicate the tests you want to change to a larger array
On 5 December 2011 10:14, Michael Zolotukhin
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 are expecting specific
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 wrote:
> On Sat, Dec 3, 2011 at 5:54 PM, Michael Zolotukhin
> wrote:
>>> I mean, tha
an we don't need to duplicate all of the
tests to check this situation.
On 3 December 2011 18:31, Richard Guenther wrote:
> On Fri, Dec 2, 2011 at 6:39 PM, Michael Zolotukhin
> wrote:
>>>
>>> Shouldn't we add a variant for each testcase so that we still
>&
at.
When they are enabled, it'll be possible to use them for testing both
128- and 256- bit vectorization.
Michael
2011/12/2 Richard Guenther :
> 2011/12/2 Michael Zolotukhin :
>> Hi,
>>
>> This patch increases array sizes in tests from vect.exp suite, thus
>
.
On 21 November 2011 20:36, Michael Zolotukhin
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
> epilo
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 t
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 m
> 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 accidental
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
> I am going to benchmark the following hunk separately tonight. It is
> independent change.
You would probably need some changes from sse.md (for gen_sse2_loadq).
Michael
Hi Jan!
Thanks for the review, you could find my answers to some of your
remarks below. I'll send a corrected patch soon with answers to the
rest of your remarks.
> - {{rep_prefix_1_byte, {{-1, rep_prefix_1_byte}}},
> + {{{rep_prefix_1_byte, {{-1, rep_prefix_1_byte}}},
>{rep_prefix_1_byte, {
Any questions on these patches? Are they ok for the trunk?
On 20 October 2011 12:37, Michael Zolotukhin
wrote:
> And, finally, part with the tests.
>
> On 20 October 2011 12:36, Michael Zolotukhin
> wrote:
>> Back-end part of the patch is attached here.
>>
>> On
Middle-end part of the patch is attached.
On 20 October 2011 12:34, Michael Zolotukhin
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 letters).
>
> The
> 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
n't separate the patches in other way without
significant changes in them.
On 29 September 2011 01:51, Jack Howarth 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,
> 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
> It appears that part 1 of the patch wasn't really attached.
Thanks, resending.
memfunc-mid.patch
Description: Binary data
> (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.
> 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.
ial experiments 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 wrote:
> On Wed, Sep 28, 2011 at 04:41:47AM -0700, Andi Kleen wrote:
>&g
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
wrote:
> I
Ping.
On 18 July 2011 15:00, Michael Zolotukhin
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 if
>
Any updates/questions on this?
On 18 July 2011 15:00, Michael Zolotukhin
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 f
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 h
Resending in plain text:
On 11 July 2011 23:50, Michael Zolotukhin
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-specif
96 matches
Mail list logo
