On Thu, Apr 27, 2017 at 2:49 PM, Richard Biener wrote:
>
> The following makes intersecting [-INF, +10] and [a + -1, +INF]
> to [10, a + -1] possible with the chance that for a <= 10 the
> resulting range will be empty (but not trivially visible as so).
Hi,
I noticed operand_less_p is quite simple
On Thu, Apr 27, 2017 at 10:25 AM, Richard Biener wrote:
>
> SCEV analysis requires us to be in loop-closed SSA form to be able
> to compute overall effects of inner loops when required. Unfortunately
> we have too many places it is used where we are not in loop-closed SSA
> form. The following p
On Wed, Apr 26, 2017 at 3:23 PM, Richard Biener
wrote:
> On Wed, Apr 26, 2017 at 3:37 PM, Bin.Cheng wrote:
>> On Wed, Apr 26, 2017 at 2:32 PM, Richard Biener
>> wrote:
>>> On Tue, Apr 18, 2017 at 12:52 PM, Bin Cheng wrote:
>>>> Hi,
>>>> Given on
On Wed, Apr 26, 2017 at 2:27 PM, Richard Biener
wrote:
> On Tue, Apr 18, 2017 at 12:51 PM, Bin Cheng wrote:
>> Hi,
>> This patch adds new loop constraint flags marking prologue, epilogue and
>> versioned loops generated
>> by vectorizer, unroller and versioning. These flags will be used in IVOP
On Wed, Apr 26, 2017 at 2:22 PM, Richard Biener
wrote:
> On Tue, Apr 18, 2017 at 12:50 PM, Bin Cheng wrote:
>> Hi,
>> IVOPTs still have difficulty for outer loop (especially for large loop
>> nest), and tend to select too many candidates.
>> It's generally bad because of unavoidable register spi
On Wed, Apr 26, 2017 at 2:32 PM, Richard Biener
wrote:
> On Tue, Apr 18, 2017 at 12:52 PM, Bin Cheng wrote:
>> Hi,
>> Given only integer variables are meaningful for register pressure estimation
>> in IVOPTs,
>> this patch skips non-integer type PHIs when counting register pressure.
>> Is it OK?
On Wed, Apr 26, 2017 at 1:58 PM, Richard Biener
wrote:
> On Tue, Apr 18, 2017 at 12:44 PM, Bin Cheng wrote:
>> Hi,
>> This patch handles more cheap cases in function force_expr_to_var_cost,
>> specifically,
>> TRUNC_DIV_EXPR, BIT_AND_EXPR, BIT_IOR_EXPR, RSHIFT_EXPR and BIT_NOT_EXPR.
>>
>> Is it
This is another one where context diff might help. No code change
from previous version.
Thanks,
bin
On Tue, Apr 18, 2017 at 11:49 AM, Bin Cheng wrote:
> Hi,
> This patch generates TMR for ivopts in new re-association order. General
> idea is,
> by querying target's addressing mode, we put as
On Wed, Apr 26, 2017 at 10:50 AM, Richard Biener
wrote:
> On Tue, Apr 18, 2017 at 12:43 PM, Bin Cheng wrote:
>> Hi,
>> This is the major part of this patch series. It rewrites cost computation
>> of ivopts using tree affine.
>> Apart from description given by cover message:
>> A) New computat
On Thu, Apr 20, 2017 at 9:35 AM, Martin Liška wrote:
> Hello.
>
> The patch adds a new test-case for the mentioned PR. Tested on
> x86_64-linux-gnu
> and ppc64le-linux-gnu.
>
> Ready for trunk or should I postpone it for next stage1?
Though can't approve, I think it's ok since we are in stage 1 n
On Wed, Apr 19, 2017 at 9:33 PM, Michael Meissner
wrote:
> On Wed, Apr 19, 2017 at 02:08:49PM +0100, Bin.Cheng wrote:
>> Hi Michael,
>> Thanks for testing it. Could you have a check if updated patch
>> resolves the ICE?
>> As for sms-*.c tests, I had difficulty in
On Tue, Apr 18, 2017 at 10:25 PM, Michael Meissner
wrote:
> I did a bootstrap and make check-{gcc,c++,fortran,lto} comparing the results
> to
> the baseline (subversion id 246975).
>
> There were 2 differences:
>
> The baseline failed on gcc.dg/sms-4.c but succeeded on gcc.dg/sms-1.c.
>
> Here ar
On Tue, Apr 18, 2017 at 1:20 PM, Trevor Saunders wrote:
> On Tue, Apr 18, 2017 at 10:39:30AM +, Bin Cheng wrote:
>> -find_depends (tree *expr_p, int *ws ATTRIBUTE_UNUSED, void *data)
>> +find_inv_vars_cb (tree *expr_p, int *ws ATTRIBUTE_UNUSED, void *data)
>> {
>> - bitmap *inv_vars = (bitma
On Tue, Apr 11, 2017 at 4:03 PM, Robin Dapp wrote:
> Hi Bin,
>
>> Seems Richi added code like below comparing costs between aligned and
>> unsigned loads, and only peeling if it's beneficial:
>>
>> /* In case there are only loads with different unknown misalignments,
>> use
>> peel
On Tue, Apr 11, 2017 at 3:38 PM, Robin Dapp wrote:
> Hi,
>
> when looking at various vectorization examples on s390x I noticed that
> we still peel vf/2 iterations for alignment even though vectorization
> costs of unaligned loads and stores are the same as normal loads/stores.
>
> A simple exampl
On Wed, Apr 5, 2017 at 12:38 PM, Markus Trippelsdorf
wrote:
> On 2017.04.03 at 15:20 +0200, Richard Biener wrote:
>> I'm re-testing the following variant.
>>
>> Richard.
>>
>> 2017-04-03 Richard Biener
>>
>> PR middle-end/80281
>> * match.pd (A + (-B) -> A - B): Make sure to preserv
And the patch..
On Wed, Apr 5, 2017 at 8:25 AM, Bin.Cheng wrote:
> On Thu, Mar 30, 2017 at 2:34 PM, Richard Biener
> wrote:
>> On Thu, Mar 30, 2017 at 3:20 PM, Bin.Cheng wrote:
>>> On Thu, Mar 30, 2017 at 2:18 PM, Bin.Cheng wrote:
>>>> On Thu, Mar 30
On Thu, Mar 30, 2017 at 2:34 PM, Richard Biener
wrote:
> On Thu, Mar 30, 2017 at 3:20 PM, Bin.Cheng wrote:
>> On Thu, Mar 30, 2017 at 2:18 PM, Bin.Cheng wrote:
>>> On Thu, Mar 30, 2017 at 1:44 PM, Richard Biener
>>> wrote:
>>>> On Thu, Mar 30, 2017 at
On Fri, Mar 31, 2017 at 2:57 PM, Bin.Cheng wrote:
> On Fri, Mar 31, 2017 at 11:37 AM, Richard Biener wrote:
>> On Fri, 31 Mar 2017, Markus Trippelsdorf wrote:
>>
>>> On 2017.03.31 at 11:16 +0200, Richard Biener wrote:
>>> > On Fri, 31 Mar 2017, Richard Biener
On Fri, Mar 31, 2017 at 11:37 AM, Richard Biener wrote:
> On Fri, 31 Mar 2017, Markus Trippelsdorf wrote:
>
>> On 2017.03.31 at 11:16 +0200, Richard Biener wrote:
>> > On Fri, 31 Mar 2017, Richard Biener wrote:
>> >
>> > > On Fri, 31 Mar 2017, Rainer Orth wrote:
>> > >
>> > > > Hi Christophe,
>> >
On Thu, Mar 30, 2017 at 2:18 PM, Bin.Cheng wrote:
> On Thu, Mar 30, 2017 at 1:44 PM, Richard Biener
> wrote:
>> On Thu, Mar 30, 2017 at 2:03 PM, Bin.Cheng wrote:
>>> On Thu, Mar 30, 2017 at 11:37 AM, Richard Biener
>>> wrote:
>>>> On Wed, Mar 29, 2017
On Thu, Mar 30, 2017 at 1:44 PM, Richard Biener
wrote:
> On Thu, Mar 30, 2017 at 2:03 PM, Bin.Cheng wrote:
>> On Thu, Mar 30, 2017 at 11:37 AM, Richard Biener
>> wrote:
>>> On Wed, Mar 29, 2017 at 5:22 PM, Bin.Cheng wrote:
>>>> On Tue, Mar 28, 2017 at
On Thu, Mar 30, 2017 at 11:37 AM, Richard Biener
wrote:
> On Wed, Mar 29, 2017 at 5:22 PM, Bin.Cheng wrote:
>> On Tue, Mar 28, 2017 at 1:34 PM, Richard Biener
>> wrote:
>>> On Tue, Mar 28, 2017 at 2:01 PM, Bin Cheng wrote:
>>>> Hi,
>>>> This
On Wed, Mar 29, 2017 at 11:05 AM, Richard Biener wrote:
>
> After quite some pondering over this and other related bugs I propose
> the following for GCC 7 which tames down PRE a bit (back to levels
> of GCC 6). Technically it's the wrong place to fix this, we do
> have measures in place during e
On Tue, Mar 28, 2017 at 1:34 PM, Richard Biener
wrote:
> On Tue, Mar 28, 2017 at 2:01 PM, Bin Cheng wrote:
>> Hi,
>> This patch is to fix PR80153. As analyzed in the PR, root cause is
>> tree_affine lacks
>> ability differentiating (unsigned)(ptr + offset) and (unsigned)ptr +
>> (unsigned)offs
On Fri, Feb 24, 2017 at 12:34 PM, Richard Biener
wrote:
> On Fri, Feb 24, 2017 at 11:53 AM, Bin Cheng wrote:
>> Hi,
>> As analyzed in PR69564, inefficient code for runtime alias check is
>> generated in benchmark
>> scimark2. It is suspected vectorized loop doesn't run enough iterations to
>>
On Tue, Feb 21, 2017 at 3:49 PM, Jan Hubicka wrote:
>> 2017-02-21 Bin Cheng
>>
>> PR tree-optimization/77536
>> * tree-ssa-loop-manip.c (niter_for_unrolled_loop): New function.
>> (tree_transform_and_unroll_loop): Use above function to compute the
>> estimated niter of unrolled loop and use it
On Mon, Feb 20, 2017 at 4:05 PM, Jan Hubicka wrote:
>> BTW, if we use gcov_type in calculation from
>> expected_loop_iterations_unbounded,
>> how should we adjust the number for calling scale_loop_frequencies
>> which has int type? In extreme case, gcov_type could be out of int's
>> range, we ha
On Mon, Feb 20, 2017 at 4:05 PM, Jan Hubicka wrote:
>> BTW, if we use gcov_type in calculation from
>> expected_loop_iterations_unbounded,
>> how should we adjust the number for calling scale_loop_frequencies
>> which has int type? In extreme case, gcov_type could be out of int's
>> range, we ha
On Mon, Feb 20, 2017 at 3:17 PM, Jan Hubicka wrote:
>> > + /* Without profile feedback, loops for which we do not know a better
>> > estimate
>> > + are assumed to roll 10 times. When we unroll such loop, it appears
>> > to
>> > + roll too little, and it may even seem to be cold. To a
On Mon, Feb 20, 2017 at 2:02 PM, Jan Hubicka wrote:
>> > 2017-02-16 Bin Cheng
>> >
>> > PR tree-optimization/77536
>> > * tree-ssa-loop-manip.c (niter_for_unrolled_loop): New function.
>> > (tree_transform_and_unroll_loop): Use above function to compute the
>> >
On Fri, Feb 17, 2017 at 3:40 AM, Jeff Law wrote:
> On 02/14/2017 03:05 AM, Bin Cheng wrote:
>>
>> Hi,
>> This is the second try fixing PR71437. The old version patch tried to fix
>> issue in VRP but it requires further non-trivial change in VRP,
>> specifically, to better support variable value r
On Tue, Feb 14, 2017 at 2:13 PM, Bin.Cheng wrote:
> On Tue, Feb 14, 2017 at 1:57 PM, Jan Hubicka wrote:
>>> Thanks,
>>> bin
>>> 2017-02-13 Bin Cheng
>>>
>>> PR tree-optimization/79347
>>> * tree-vect-loop-manip.c (apply_prob
On Tue, Feb 14, 2017 at 2:48 PM, Richard Biener wrote:
>
> The following enables final value replacement for floating point
> expressions if -funsafe-math-optimizations is set (that's the
> flag the reassoc pass controls similar transforms on).
Looks to me it's kind of abusing of current implement
On Tue, Feb 14, 2017 at 1:57 PM, Jan Hubicka wrote:
>> Thanks,
>> bin
>> 2017-02-13 Bin Cheng
>>
>> PR tree-optimization/79347
>> * tree-vect-loop-manip.c (apply_probability_for_bb): New function.
>> (vect_do_peeling): Maintain profile counters during peeling.
>>
>> gcc/testsu
On Wed, Jan 25, 2017 at 4:25 PM, Segher Boessenkool
wrote:
> On Wed, Jan 25, 2017 at 04:08:54PM +0000, Bin.Cheng wrote:
>> > I was worried this patch would prevent too many other optimisations,
>> > so I looked into better options. I didn't find any. I tested the
>&
On Wed, Jan 25, 2017 at 3:56 PM, Segher Boessenkool
wrote:
> Hi!
>
> I was worried this patch would prevent too many other optimisations,
> so I looked into better options. I didn't find any. I tested the
> effects of the patch on 31 architectures (building GCC and then Linux
Thanks very much fo
On Thu, Jan 19, 2017 at 12:07 PM, Bin.Cheng wrote:
> On Thu, Jan 19, 2017 at 11:22 AM, Richard Biener
> wrote:
>> On Thu, Jan 19, 2017 at 11:25 AM, Bin.Cheng wrote:
>>> On Thu, Jan 19, 2017 at 9:42 AM, Richard Biener
>>
>> Or a later pass introduced
On Thu, Jan 19, 2017 at 11:22 AM, Richard Biener
wrote:
> On Thu, Jan 19, 2017 at 11:25 AM, Bin.Cheng wrote:
>> On Thu, Jan 19, 2017 at 9:42 AM, Richard Biener
>> wrote:
>>> On Wed, Jan 18, 2017 at 4:32 PM, Bin.Cheng wrote:
>>>> On Wed, Jan 18, 2017 at
On Thu, Jan 19, 2017 at 9:42 AM, Richard Biener
wrote:
> On Wed, Jan 18, 2017 at 4:32 PM, Bin.Cheng wrote:
>> On Wed, Jan 18, 2017 at 2:54 PM, Richard Biener
>> wrote:
>>> On Wed, Jan 18, 2017 at 11:10 AM, Martin Liška wrote:
>>>> Hello.
>>>>
On Wed, Jan 18, 2017 at 2:54 PM, Richard Biener
wrote:
> On Wed, Jan 18, 2017 at 11:10 AM, Martin Liška wrote:
>> Hello.
>>
>>
>> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>>
>> Ready to be installed?
>
> I'm not sure. If we have such zero distance refs in the IL
On Wed, Jan 18, 2017 at 10:10 AM, Martin Liška wrote:
> Hello.
>
> After basic understanding of loop predictive commoning, the problematic
> combined chain is:
>
> Loads-only chain 0x38b6730 (combined)
> max distance 0
> references:
> MEM[(real(kind=8) *)vectp_a.29_81] (id 1)
> offs
On Mon, Dec 12, 2016 at 4:35 PM, Jakub Jelinek wrote:
> On Mon, Dec 12, 2016 at 09:32:30AM -0700, Jeff Law wrote:
>> On 12/09/2016 03:20 AM, Bin Cheng wrote:
>> >Hi,
>> >PR78652 was fixed by patch for PR77856, this patch adds a test for it.
>> >Test result checked, is it OK?
>> >
>> >Thanks,
>>
On Fri, Jan 13, 2017 at 9:46 AM, Richard Biener wrote:
>
> The following is an attempt to change those testcases to be less dependent
> on previous passes. The original motivation of the testcases seems to be
> testing SCEV capabilities and in turn IVOPTs decisions, thus the testcases
> are chang
On Wed, Nov 30, 2016 at 3:10 PM, Richard Biener
wrote:
> On Fri, Nov 18, 2016 at 5:53 PM, Bin Cheng wrote:
>> Hi,
>> This is a rework of https://gcc.gnu.org/ml/gcc-patches/2016-10/msg02007.html.
>> Though review comments suggested it could be merged with last kind
>> simplification
>> of fold_co
On Tue, Nov 29, 2016 at 9:14 PM, Christophe Lyon
wrote:
> On 29 November 2016 at 20:38, Uros Bizjak wrote:
>>> 2016-11-26 Segher Boessenkool
>>>
>>> * combine.c (change_zero_ext): Also handle extends from a subreg
>>> to a mode bigger than that of the operand of the subreg.
>>
>> This patch in
On Fri, Nov 25, 2016 at 8:23 AM, Richard Biener
wrote:
> On Thu, Nov 24, 2016 at 4:22 PM, Bin Cheng wrote:
>> Hi,
>> This patch fixes two issues in newly introduced pattern: (cond (cmp
>> (convert1? @1) @3) (convert2? @1) @2).
>> For PR78507, we need to check if from_type is INTEGRAL_TYPE_P expl
On Thu, Nov 24, 2016 at 11:17 AM, Richard Biener
wrote:
> On Thu, Nov 24, 2016 at 11:11 AM, Bin.Cheng wrote:
>> On Thu, Nov 24, 2016 at 8:57 AM, Richard Biener
>> wrote:
>>> On Wed, Nov 23, 2016 at 3:57 PM, Bin.Cheng wrote:
>>>> On Wed, Nov 23, 2016 at
Here is the patch.
Thanks,
bin
On Thu, Nov 24, 2016 at 10:11 AM, Bin.Cheng wrote:
> On Thu, Nov 24, 2016 at 8:57 AM, Richard Biener
> wrote:
>> On Wed, Nov 23, 2016 at 3:57 PM, Bin.Cheng wrote:
>>> On Wed, Nov 23, 2016 at 2:27 PM, Richard Biener
>>> wrote:
>
On Thu, Nov 24, 2016 at 8:57 AM, Richard Biener
wrote:
> On Wed, Nov 23, 2016 at 3:57 PM, Bin.Cheng wrote:
>> On Wed, Nov 23, 2016 at 2:27 PM, Richard Biener
>> wrote:
>>> On Wed, Nov 23, 2016 at 2:54 PM, Bin Cheng wrote:
>>>> Hi,
>>>>
On Wed, Nov 23, 2016 at 2:27 PM, Richard Biener
wrote:
> On Wed, Nov 23, 2016 at 2:54 PM, Bin Cheng wrote:
>> Hi,
>> This is actually the review suggestion for patch
>> @https://gcc.gnu.org/ml/gcc-patches/2016-11/msg02341.html, but I forgot to
>> incorporate it when committing that patch. Here
On Wed, Nov 23, 2016 at 2:40 PM, Marc Glisse wrote:
> On Fri, 18 Nov 2016, Bin Cheng wrote:
>
> +(for cmp (lt le gt ge)
> + (simplify
> + (cond (cmp@0 (convert1? @1) INTEGER_CST@3) (convert2? @1) INTEGER_CST@2)
> + (with
> + {
> + tree from_type = TREE_TYPE (@1);
> + tree c1_type = TRE
On Wed, Nov 23, 2016 at 10:51 AM, Richard Biener
wrote:
> On Wed, Nov 23, 2016 at 11:40 AM, Bin.Cheng wrote:
>> On Wed, Nov 23, 2016 at 10:29 AM, Richard Biener
>> wrote:
>>> On Fri, Nov 18, 2016 at 11:20 AM, Bin Cheng wrote:
>>>> Hi,
>>>> This
On Wed, Nov 23, 2016 at 10:29 AM, Richard Biener
wrote:
> On Fri, Nov 18, 2016 at 11:20 AM, Bin Cheng wrote:
>> Hi,
>> This is a rework of
>> https://gcc.gnu.org/ml/gcc-patches/2016-10/msg02005.html. According to
>> review comment, I extended the original patch and made it covering last kind
On Mon, Nov 21, 2016 at 9:34 PM, Doug Gilmore wrote:
> I haven't seen any followups to this discussion of Bin's patch to
> PR68303 and PR69710, the patch submission:
> http://gcc.gnu.org/ml/gcc-patches/2016-05/msg02000.html
>
> Discussion:
> http://gcc.gnu.org/ml/gcc-patches/2016-07/msg00761.html
On Fri, Nov 18, 2016 at 3:50 PM, Bernd Edlinger
wrote:
> On 11/18/16 12:58, Christophe Lyon wrote:
>> On 17 November 2016 at 10:23, Kyrill Tkachov
>> wrote:
>>>
>>> On 09/11/16 12:58, Bernd Edlinger wrote:
Hi!
This patch enables the ldrd/strd peephole rules unconditionall
On Fri, Nov 18, 2016 at 4:52 PM, Michael Matz wrote:
> Hi,
>
> On Thu, 17 Nov 2016, Bin.Cheng wrote:
>
>> B) Depending on ilp, I think below test strings fail for long time with
>> haswell:
>> ! { dg-final { scan-tree-dump-times "Executing predictive comm
On Wed, Nov 16, 2016 at 3:05 PM, Andreas Schwab wrote:
> On Nov 14 2016, Michael Matz wrote:
>
>> PR missed-optimization/77881
>> * combine.c (simplify_comparison): Remove useless subregs
>> also inside the loop, not just after it.
>> (make_compound_operation): Recognize s
On Thu, Nov 17, 2016 at 10:53 AM, Richard Biener
wrote:
> On Thu, Nov 17, 2016 at 11:26 AM, Bin.Cheng wrote:
>> On Thu, Nov 17, 2016 at 8:32 AM, Richard Biener
>> wrote:
>>> On Wed, Nov 16, 2016 at 6:20 PM, Bin Cheng wrote:
>>>> Hi,
>>>> Current
On Thu, Nov 17, 2016 at 8:32 AM, Richard Biener
wrote:
> On Wed, Nov 16, 2016 at 6:20 PM, Bin Cheng wrote:
>> Hi,
>> Currently test gfortran.dg/vect/fast-math-mgrid-resid.f checks all
>> predictive commoning opportunities for all possible loops. This makes it
>> fragile because vectorizer may
On Sat, Nov 12, 2016 at 8:36 AM, Evgeny Kudryashov wrote:
> On 2016-11-10 13:30, Bin.Cheng wrote:
>>
>> Hi,
>> I see the cost problem with your test now. When computing an address
>> type iv_use with a candidate, the computation consists of two parts,
>> for
On Tue, Nov 8, 2016 at 10:13 AM, kugan
wrote:
> Hi,
>
>
>
> On 04/11/16 04:36, Martin Jambor wrote:
>>
>> Hi,
>>
>> On Fri, Oct 28, 2016 at 02:03:47PM +1100, kugan wrote:
>>>
>>>
>>> ...snip...
>>>
>>> I have also separated the constant parameter conversion out and posted as
>>> https://gcc.gnu.or
On Wed, Nov 9, 2016 at 1:02 PM, Bin.Cheng wrote:
> On Thu, Nov 3, 2016 at 4:00 PM, Bin.Cheng wrote:
>> On Thu, Nov 3, 2016 at 1:35 PM, Evgeny Kudryashov
>> wrote:
>>> Hello,
>>>
>>> I'm facing the following problem related to ivopts. The probl
On Wed, Nov 9, 2016 at 9:46 PM, Christophe Lyon
wrote:
> Hi Bin
>
> On 8 November 2016 at 13:37, Bin Cheng wrote:
>> Hi,
>> Test gcc.dg/vect/vect-cond-2.c can be vectorized by GCC now, this patch
>> drops the xfail.
>>
>> Thanks,
>> bin
>>
>> gcc/testsuite/ChangeLog
>> 2016-11-04 Bin Cheng
>>
On Thu, Nov 3, 2016 at 4:00 PM, Bin.Cheng wrote:
> On Thu, Nov 3, 2016 at 1:35 PM, Evgeny Kudryashov
> wrote:
>> Hello,
>>
>> I'm facing the following problem related to ivopts. The problem is that GCC
>> generates a lot of induction variables and as a result
lso it's not
related to SVE, As a matter of fact, I haven't read any document about
SVE yet. Sorry again for the false impression conveyed by previous
messages.
Thanks,
bin
>
> Thanks.
> Yuri.
>
> 2016-11-09 14:46 GMT+03:00 Bin.Cheng :
>> On Wed, Nov 9, 2016 at
rking on this project.
>
> Any help will be appreciated.
>
> Thanks.
> Yuri.
>
> 2016-11-09 13:37 GMT+03:00 Bin.Cheng :
>> On Tue, Nov 1, 2016 at 12:38 PM, Yuri Rumyantsev wrote:
>>> Hi All,
>>>
>>> I re-send all patches sent by Ilya earlier for review wh
On Tue, Nov 1, 2016 at 12:38 PM, Yuri Rumyantsev wrote:
> Hi All,
>
> I re-send all patches sent by Ilya earlier for review which support
> vectorization of loop epilogues and loops with low trip count. We
> assume that the only patch - vec-tails-07-combine-tail.patch - was not
> approved by Jeff.
On Tue, Nov 8, 2016 at 9:11 AM, Christophe Lyon
wrote:
> Hi,
>
> On 7 November 2016 at 23:56, Jonathan Wakely wrote:
>> On 7 November 2016 at 22:49, Jason Merrill wrote:
>>> Tested x86_64-pc-linux-gnu. Are the libstdc++ changes OK for trunk?
>>
>> Yes, I like the approach, thanks.
>
> The new te
On Tue, Nov 8, 2016 at 9:11 AM, Richard Biener wrote:
> On Mon, 7 Nov 2016, Christophe Lyon wrote:
>
>> Hi Richard,
>>
>>
>> On 7 November 2016 at 09:01, Richard Biener wrote:
>> >
>> > The following fixes an oversight when computing alignment in the
>> > vectorizer.
>> >
>> > Bootstrapped and te
On Thu, Nov 3, 2016 at 1:35 PM, Evgeny Kudryashov wrote:
> Hello,
>
> I'm facing the following problem related to ivopts. The problem is that GCC
> generates a lot of induction variables and as a result there is an
> unnecessary increase of stack usage and register pressure.
>
> For instance, for
On Tue, Oct 25, 2016 at 11:40 AM, Segher Boessenkool
wrote:
> This improves a few things in change_zero_ext. Firstly, it should use
> the passed in pattern in recog_for_combine, not the pattern of the insn
> (they are not the same if the whole pattern was replaced). Secondly,
> it handled zero_e
On Tue, Nov 1, 2016 at 12:21 PM, Kyrill Tkachov
wrote:
> Hi Tamar,
>
>
> On 26/10/16 16:01, Tamar Christina wrote:
>>
>> Hi Christophe,
>>
>> Here's the updated patch.
>>
>> Cheers,
>> Tamar
>>
>> From: Christophe Lyon
>> Sent: Wednesday, October 19, 2016
On Wed, Nov 2, 2016 at 11:08 AM, Richard Biener
wrote:
> On Tue, Nov 1, 2016 at 4:24 PM, Bin.Cheng wrote:
>> On Thu, Aug 11, 2016 at 11:38 AM, Richard Biener
>> wrote:
>>> On Thu, Aug 11, 2016 at 11:56 AM, Bin.Cheng wrote:
>>>> On Thu, Aug 11, 2016 at
On Fri, Oct 28, 2016 at 1:38 PM, Richard Biener
wrote:
> On Wed, Oct 26, 2016 at 6:42 PM, Bin Cheng wrote:
>> Hi,
>> For stmt defining reduction, GCC vectorizer assumes that the reduction
>> variable is always the last (second) operand. Another fact is that
>> vectorizer doesn't swap operands
On Thu, Aug 11, 2016 at 11:38 AM, Richard Biener
wrote:
> On Thu, Aug 11, 2016 at 11:56 AM, Bin.Cheng wrote:
>> On Thu, Aug 11, 2016 at 10:50 AM, Richard Biener
>> wrote:
>>> On Wed, Aug 10, 2016 at 5:58 PM, Bin Cheng wrote:
>>>> Hi,
>>>>
On Fri, Oct 28, 2016 at 1:17 PM, Richard Biener
wrote:
> On Thu, Oct 27, 2016 at 3:37 PM, Bin Cheng wrote:
>> Hi,
>> During analysis, vect_slp checks if statements of a group are isomorphic to
>> each other, specifically, all statements have to be isomorphic to the first
>> one. Apparently, op
On Fri, Oct 28, 2016 at 12:27 PM, Tamar Christina
wrote:
> Looking at it again,
>
> it seems to be that the testcase should be adjusted.
> There's no actual spilling. It just uses more registers than before due to
> the scheduling.
Sorry I didn't look into the test, but using more registers sound
On Thu, Oct 27, 2016 at 2:58 PM, Richard Biener
wrote:
> On Tue, Oct 25, 2016 at 1:21 PM, Bin Cheng wrote:
>> Hi,
>> Second patch optimizing (cond (cmp (convert (x), c1), x, c2)) into (minmax
>> (x, c)). As commented in patch, this is done if:
>>
>> + 1) Comparison's operands are promoted f
On Wed, Oct 26, 2016 at 4:05 PM, Marc Glisse wrote:
> On Wed, 26 Oct 2016, Bin.Cheng wrote:
>
>> On Wed, Oct 26, 2016 at 3:10 PM, Bin.Cheng wrote:
>>>
>>> On Wed, Oct 26, 2016 at 3:04 PM, Marc Glisse
>>> wrote:
>>>>
>>>> On Wed
On Wed, Oct 26, 2016 at 3:10 PM, Bin.Cheng wrote:
> On Wed, Oct 26, 2016 at 3:04 PM, Marc Glisse wrote:
>> On Wed, 26 Oct 2016, Bin.Cheng wrote:
>>
>>> Thanks for reviewing, updated patch attached. Is it OK?
>>
>>
>> +/* (convert (minmax ((convert
On Wed, Oct 26, 2016 at 3:04 PM, Marc Glisse wrote:
> On Wed, 26 Oct 2016, Bin.Cheng wrote:
>
>> Thanks for reviewing, updated patch attached. Is it OK?
>
>
> +/* (convert (minmax ((convert (x) c -> minmax (x c) if x is promoted
> + and the outer convert demotes
On Tue, Oct 25, 2016 at 1:00 PM, Richard Biener
wrote:
> On Tue, Oct 25, 2016 at 1:21 PM, Bin Cheng wrote:
>> Hi,
>> This is an update patch for
>> https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00738.html . In this version,
>> existing pattern (convert (op:s (convert@2 @0) (convert?@3 @1))) is
On Tue, Oct 25, 2016 at 12:48 PM, Richard Biener
wrote:
> On Tue, Oct 25, 2016 at 1:21 PM, Bin Cheng wrote:
>> Hi,
>> This is a patch set adding various match.pd patterns in order to generate
>> simplified MIN/MAX_EXPR mostly from COND_EXPR. This is the first one
>> optimizing (convert1 (minma
On Thu, Oct 20, 2016 at 3:55 PM, Bin.Cheng wrote:
> On Thu, Oct 20, 2016 at 3:43 PM, Michael Matz wrote:
>> Hi,
>>
>> On Sat, 5 Dec 2015, Jeff Law wrote:
>>
>>> Nit. I don't think you want a comma after "so". And it looks like your
>>
On Wed, Oct 12, 2016 at 9:50 AM, Richard Biener
wrote:
> On Wed, Oct 12, 2016 at 10:29 AM, Bin.Cheng wrote:
>> On Wed, Oct 12, 2016 at 9:12 AM, Richard Biener
>> wrote:
>>> On Tue, Oct 11, 2016 at 5:03 PM, Bin Cheng wrote:
>>>> Hi,
>>>> Given
On Thu, Oct 20, 2016 at 3:43 PM, Michael Matz wrote:
> Hi,
>
> On Sat, 5 Dec 2015, Jeff Law wrote:
>
>> Nit. I don't think you want a comma after "so". And it looks like your
>> comment got truncated as well.
>>
>> With the comment above fixed, this is fine for the trunk.
>
> I'm terribly sorry
On Sat, Oct 15, 2016 at 3:07 AM, kugan
wrote:
> Hi Bin,
>
> On 15/10/16 00:15, Bin Cheng wrote:
>>
>> +/* Test for likely overcommitment of vector hardware resources. If a
>> + loop iteration is relatively large, and too large a percentage of
>> + instructions in the loop are vectorized, the
On Mon, Sep 12, 2016 at 8:58 PM, Jeff Law wrote:
> On 09/06/2016 12:54 PM, Bin Cheng wrote:
>>
>> Hi,
>> LOOP_VINFO_NITERS is computed as LOOP_VINFO_NITERSM1 + 1, which could
>> overflow in loop niters' type. Vectorizer needs to generate more code
>> computing vectorized niters if overflow does h
On Wed, Sep 7, 2016 at 1:20 PM, Jeff Law wrote:
> On 09/06/2016 12:50 PM, Bin Cheng wrote:
>>
>> Hi,
>> This simple patch adds interface reseting original copy table in cfg.c.
>> This will be used in rewriting vect_do_peeling_* functions in vectorizer so
>> that we don't need to release/allocate t
On Wed, Oct 12, 2016 at 9:12 AM, Richard Biener
wrote:
> On Tue, Oct 11, 2016 at 5:03 PM, Bin Cheng wrote:
>> Hi,
>> Given below test case,
>> int foo (unsigned short a[], unsigned int x)
>> {
>> unsigned int i;
>> for (i = 0; i < 1000; i++)
>> {
>> x = a[i];
>> a[i] = (unsign
On Mon, Sep 26, 2016 at 10:21 AM, Robin Dapp wrote:
>> Comments added. Bootstrap and test, is it reasonable?
>
> This introduces an ICE on s390x with a Fortran testcase, because
> of an assertion failure in tree_to_uhwi (DR_STEP (dr_a.dr)) for
> DR_STEP (dr_a.dr) = -8(OVF).
>
> The attached patch
On Wed, Sep 21, 2016 at 3:01 PM, Richard Biener
wrote:
> On Tue, Sep 20, 2016 at 5:25 PM, Bin Cheng wrote:
>> Hi,
>> I originally posted a patch improving code generation for alias check in
>> vectorizer at https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00929.html.
>> Here it's the 2nd version
On Wed, Sep 14, 2016 at 5:43 PM, Jeff Law wrote:
> On 09/14/2016 07:21 AM, Richard Biener wrote:
>>
>> On Tue, Sep 6, 2016 at 8:52 PM, Bin Cheng wrote:
>>>
>>> Hi,
>>> This is the main patch improving control flow graph for vectorized loop.
>>> It generally rewrites loop peeling stuff in vectoriz
On Fri, Sep 16, 2016 at 11:07 AM, Kyrill Tkachov
wrote:
>
> On 16/09/16 11:05, Bin.Cheng wrote:
>>
>> On Fri, Sep 16, 2016 at 10:53 AM, Kyrill Tkachov
>> wrote:
>>>
>>> On 16/09/16 10:50, Bin.Cheng wrote:
>>>>
>>>> On Fri, Sep 1
On Fri, Sep 16, 2016 at 10:53 AM, Kyrill Tkachov
wrote:
>
> On 16/09/16 10:50, Bin.Cheng wrote:
>>
>> On Fri, Sep 16, 2016 at 10:20 AM, Kyrill Tkachov
>> wrote:
>>>
>>> On 16/09/16 10:02, Richard Biener wrote:
>>>>
>>>> On Fri, Se
On Fri, Sep 16, 2016 at 10:20 AM, Kyrill Tkachov
wrote:
>
> On 16/09/16 10:02, Richard Biener wrote:
>>
>> On Fri, Sep 16, 2016 at 10:40 AM, Kyrill Tkachov
>> wrote:
>>>
>>> Hi all,
>>>
>>> Currently the functions:
>>> int f1(int x, int t)
>>> {
>>>if (x == -1 || x == -2)
>>> t = 1;
>>>
On Wed, Sep 7, 2016 at 1:10 AM, kugan wrote:
> Hi Bin,
>
>
> On 07/09/16 04:54, Bin Cheng wrote:
>>
>> Hi,
>> LOOP_VINFO_NITERS is computed as LOOP_VINFO_NITERSM1 + 1, which could
>> overflow in loop niters' type. Vectorizer needs to generate more code
>> computing vectorized niters if overflow d
On Fri, Sep 2, 2016 at 3:46 PM, Yuri Rumyantsev wrote:
> Hi Jeff,
>
> I am trying to reduce cost of repeated call of if-conversion for
> epilogue vectorization. I'd like to clarify your recommendation -
> should I design additional support for versioning in
> vect_do_peeling_for_loop_bound or ligh
On Tue, Aug 16, 2016 at 10:53 AM, James Greenhalgh
wrote:
> On Wed, Aug 10, 2016 at 04:00:16PM +, Bin Cheng wrote:
>> Hi,
>> This is a follow up patch for previous vcond patches. In previous ones,
>> we rely on combiner to simplify "X = !Y; Z = X ? A : B" into "Z = Y ? B : A".
>> That works f
401 - 500 of 919 matches
Mail list logo
