On Tue, Feb 10, 2015 at 6:02 PM, Richard Biener
wrote:
> On Mon, Feb 9, 2015 at 11:33 AM, Bin Cheng wrote:
>> The second time I missed patch in one day, I hate myself.
>> Here it is.
>
> I think the patch is reasonable but I would have used a default = NULL
> arg for 'stop' to make the patch smal
On Tue, Feb 10, 2015 at 6:18 PM, Bin.Cheng wrote:
> On Tue, Feb 10, 2015 at 6:02 PM, Richard Biener
> wrote:
>> On Mon, Feb 9, 2015 at 11:33 AM, Bin Cheng wrote:
>>> The second time I missed patch in one day, I hate myself.
>>> Here it is.
>>
>> I thin
On Tue, Feb 10, 2015 at 12:24 AM, Richard Biener
wrote:
> On February 9, 2015 11:09:49 AM CET, Bin Cheng wrote:
>
> Did you extract a testcase for it? Note that the IV step itself may be
> expanded
> Too much.
>
> I
>>looked into the regression and thought it was because of passes after
>>IVO
On Wed, Feb 11, 2015 at 4:55 AM, Jeff Law wrote:
>
> This PR was originally minor issue where we regressed on this kind of
> sequence:
>
> typedef struct toto_s *toto_t;
> toto_t add (toto_t a, toto_t b) {
> int64_t tmp = (int64_t)(intptr_t)a + ((int64_t)(intptr_t)b&~1L);
> return (toto_t)(int
On Wed, Feb 11, 2015 at 7:24 PM, Richard Biener
wrote:
> On Wed, Feb 11, 2015 at 9:23 AM, Bin.Cheng wrote:
>> On Tue, Feb 10, 2015 at 12:24 AM, Richard Biener
>> wrote:
>>
>> Previously, the computation of _1174 can be replaced by _629 in bb8 in
>> DOM2 pa
Thanks for giving it a try.
On Fri, Oct 31, 2014 at 3:43 AM, Jeff Law wrote:
> On 10/10/14 21:32, Bin.Cheng wrote:
>>
>> Mike already gave great answers, here are just some of my thoughts on
>> the specific questions. See embedded below.
>
> Thanks to b
On Mon, Nov 3, 2014 at 6:11 AM, Andreas Tobler wrote:
> Hello all,
>
> this is a patch which brings support for arm*-*-freebsd* to trunk.
> The architectures supported are arm-*-*freebsd*, armv6-*-freebsd* and
> armv6hf-*-freebsd*.
> armv6 stands for ARM_ARCH == 6, arm stands for ARM_ARCH < 6.
Jus
On Sat, Nov 1, 2014 at 4:29 AM, Jeff Law wrote:
> On 09/30/14 03:22, Bin Cheng wrote:
>
>>
>> 2014-09-30 Bin Cheng
>> Mike Stump
>>
>> * timevar.def (TV_SCHED_FUSION): New time var.
>> * passes.def (pass_sched_fusion): New pass.
>> * config/arm/arm.c (TARGET_SC
On Thu, Nov 29, 2018 at 12:20 AM Jan Hubicka wrote:
>
> > On Tue, Nov 20, 2018 at 6:55 PM bin.cheng
> > wrote:
> > >
> > > Sender:Jan Hubicka
> > > Sent at:2018 Nov 5 (Mon) 22:21
> > > To:Richard Biener
> > > Cc:bin.cheng ; GCC Patc
On Tue, Dec 4, 2018 at 4:40 PM Bin.Cheng wrote:
>
> On Thu, Nov 29, 2018 at 12:20 AM Jan Hubicka wrote:
> >
> > > On Tue, Nov 20, 2018 at 6:55 PM bin.cheng
> > > wrote:
> > > >
> > > > Sender:Jan Hubicka
> > > > Sent at:2018
On Sat, Dec 8, 2018 at 12:57 AM Jan Hubicka wrote:
>
> > Hi Honza,
> > I have committed the typo fix as revision 266885.
> > Also I followed your suggestion (IIUC) by calling
> > profile_count::adjust_for_ipa_scaling for zero den in function
> > update_profiling_info. It works and does make more
On Thu, Nov 8, 2018 at 6:33 AM Jeff Law wrote:
>
> On 10/31/18 12:34 AM, bin.cheng wrote:
> > Hi,
> > This patch fixes AutoFDO breakage on trunk. The main reason for breakage
> > is AutoFDO
> > relies on standalone edge count computing and propagating profile
>
Hi,
This patch calls update_max_bb_count even if autofdo counts are all zeros,
otherwise it would trigger ICE because of mismatch between basic blocks'
count (all autofdo::zero) and cfun->cfg->max_count (guessed::non_zero).
For functions with all autofdo::zero counts, we should improve by restoring
Hi,
This patch skips generating histogram value for internal function call in
autofdo,
otherwise it would trigger ICE with following patch re-enabling indirect call
value
profile transformation. I think this patch is actually needed for GCC-6 on
which
indirect call value profile is not disabled
Hi,
Due to ICE and mal-functional bugs, indirect call value profile transformation
is disabled on GCC-7/8/trunk. This patch restores the transformation. The
main issue is AutoFDO should store cgraph_node's profile_id of callee func in
the first histogram value's counter, rather than pointer to c
On Sun, Dec 16, 2018 at 9:11 AM Andi Kleen wrote:
>
> "bin.cheng" writes:
>
> > Hi,
> >
> > Due to ICE and mal-functional bugs, indirect call value profile
> > transformation
> > is disabled on GCC-7/8/trunk. This patch restores the transforma
On Wed, Dec 19, 2018 at 5:27 AM Andi Kleen wrote:
>
> > Yes, take g++.dg/tree-prof/morefunc.C as an example:
> > - int i;
> > - for (i = 0; i < 1000; i++)
> > + int i, j;
> > + for (i = 0; i < 100; i++)
> > +for (j = 0; j < 50; j++)
> > g += tc->foo();
> > if (g<100) g++;
> >
On Tue, Dec 18, 2018 at 7:15 PM Bin.Cheng wrote:
>
> On Sun, Dec 16, 2018 at 9:11 AM Andi Kleen wrote:
> >
> > "bin.cheng" writes:
> >
> > > Hi,
> > >
> > > Due to ICE and mal-functional bugs, indirect call value profile
> &g
On Wed, Dec 19, 2018 at 12:00 PM Andi Kleen wrote:
>
> On Wed, Dec 19, 2018 at 10:01:15AM +0800, Bin.Cheng wrote:
> > On Tue, Dec 18, 2018 at 7:15 PM Bin.Cheng wrote:
> > >
> > > On Sun, Dec 16, 2018 at 9:11 AM Andi Kleen wrote:
> > > >
> &g
On Wed, Aug 14, 2019 at 3:23 PM Kewen.Lin wrote:
>
> Hi!
>
> Comparing to the previous versions of implementation mainly based on the
> existing IV cands but zeroing the related group/use cost, this new one is
> based
> on Richard and Segher's suggestion introducing one doloop dedicated IV cand.
On Thu, Aug 22, 2019 at 11:18 AM Kewen.Lin wrote:
>
> Hi Bin,
>
> Thanks for your time!
>
> on 2019/8/21 下午8:32, Bin.Cheng wrote:
> > On Wed, Aug 14, 2019 at 3:23 PM Kewen.Lin wrote:
> >>
> >> Hi!
> >>
> >> Comparing to the previous ver
On Thu, Aug 22, 2019 at 3:09 PM Kewen.Lin wrote:
>
> Hi Bin,
>
> on 2019/8/22 下午1:46, Bin.Cheng wrote:
> > On Thu, Aug 22, 2019 at 11:18 AM Kewen.Lin wrote:
> >>
> >> Hi Bin,
> >>
> >> Thanks for your time!
> >>
> >> on
On Fri, Aug 23, 2019 at 4:27 PM Kewen.Lin wrote:
>
> Hi Bin
>
> on 2019/8/23 上午10:19, Bin.Cheng wrote:
> > On Thu, Aug 22, 2019 at 3:09 PM Kewen.Lin wrote:
> >>
> >> Hi Bin,
> >>
> >> on 2019/8/22 下午1:46, Bin.Cheng wrote:
> >>> O
Hi,
The company (Alibaba) finished signing copyright assignment with FSF, so this
patch updates my email address as attached.
Thanks,
bin
email-address.txt
Description: Binary data
Hi,
This patch fixes PR87022. The root cause is the original code checks the first
bit
in dist vector for zero and we still do that after enabling loop nest
distribution.
For the test case, the first bit is for outer loop while the dependence happens
in
the inner loop, as a result, the directi
Hi,
This simple patch avoids infinite recursion when tracing inlined function decl
by using
pre-defined macro DECL_FROM_INLINE in tree.h.
Bootstrap and test on x86_64 in patch set. Is it OK?
Thanks,
bin
2018-10-31 Bin Cheng
* auto-profile.c (string_table::get_index_by_decl)
Hi,
In new profile probability/count infra, we have different precision quality
categories,
and probabilities/counts of different categories are not supposed to be
compared or
calculated. Though in general is an improvement, it introduces unexpected
behavior.
Specifically, class profile_probabl
Hi,
This is a simple patch setting profile_count with according precision category
in
AutoFDO, as well as setting profile_count for exit basic block.
Bootstrap and test on x86_64 in patch set. Is it OK?
Thanks,
bin
2018-10-31 Bin Cheng
* auto-profile.c (afdo_calculate_branch_prob):
Hi,
This patch fixes AutoFDO breakage on trunk. The main reason for breakage is
AutoFDO
relies on standalone edge count computing and propagating profile
count/probability info
on CFG, but in new infra, edge count is actually computed from probability,
which leads
to chicken-egg problem and cor
On Wed, Oct 31, 2018 at 5:11 PM Richard Biener
wrote:
>
> On Wed, Oct 31, 2018 at 7:30 AM bin.cheng wrote:
> >
> > Hi,
> > In new profile probability/count infra, we have different precision quality
> > categories,
> > and probabilities/counts of differe
On Wed, Oct 31, 2018 at 10:36 PM Jeff Law wrote:
>
> On 10/31/18 12:30 AM, bin.cheng wrote:
> > Hi,
> > In new profile probability/count infra, we have different precision quality
> > categories,
> > and probabilities/counts of different categories are not s
--
Sender:Richard Biener
Sent at:2018 Oct 31 (Wed) 17:11
To:bin.cheng ; Jan Hubicka
Cc:GCC Patches
Subject:Re: [PATCH AutoFDO/2]Treat ZERO as common profile probability/count
>
>
> On Wed, Oct 31, 2018 at 7:30 AM bin.che
Hi,
This patch fixes PR84648 by adjusting exit conditions for loop-until-wrap cases.
It only handles simple cases in which IV.base are constants because we rely on
current niter analyzer which doesn't handle parameterized bound in wrapped
case. It could be relaxed in the future.
Bootstrap and tes
On Sun, Nov 11, 2018 at 7:20 PM Bernhard Reutner-Fischer
wrote:
>
> On Sun, 11 Nov 2018 16:02:33 +0800
> "bin.cheng" wrote:
>
> Quick observation unrelated to the real patch.
>
> I think the coding style mandates to use the type itself and not the
> underlyi
On Mon, Nov 5, 2018 at 10:40 PM Jan Hubicka wrote:
>
> diff --git a/gcc/profile-count.h b/gcc/profile-count.h
> index 4289bc5a004..2b5e3269250 100644
> --- a/gcc/profile-count.h
> +++ b/gcc/profile-count.h
> @@ -218,6 +218,11 @@ public:
> }
>
>
> + /* Return true if value is zero. */
> + b
--
Sender:Richard Biener
Sent at:2018 Nov 13 (Tue) 23:03
To:bin.cheng
Cc:GCC Patches
Subject:Re: [PATCH PR84648]Adjust loop exit conditions for loop-until-wrap
cases.
>
> On Sun, Nov 11, 2018 at 9:02 AM bin.cheng
On Mon, Nov 19, 2018 at 9:17 PM Christophe Lyon
wrote:
>
> On Wed, 14 Nov 2018 at 11:10, bin.cheng wrote:
> >
> > --
> > Sender:Richard Biener
> > Sent at:2018 Nov 13 (Tue) 23:03
> > To:bin.cheng
Sender:Jan Hubicka
Sent at:2018 Nov 5 (Mon) 22:21
To:Richard Biener
Cc:bin.cheng ; GCC Patches
Subject:Re: [PATCH AutoFDO/2]Treat ZERO as common profile probability/count
>
> > On Wed, Oct 31, 2018 at 7:30 AM bin.cheng
> > wrote:
> > >
> > > Hi,
>
On Sat, Jul 28, 2018 at 7:36 AM Kugan Vivekanandarajah
wrote:
>
> Hi,
>
> On 28 July 2018 at 01:13, Richard Biener wrote:
> > On July 27, 2018 3:33:59 PM GMT+02:00, "Martin Liška"
> > wrote:
> >>On 07/11/2018 02:31 PM, Richard Biener wrote:
> >>> Why not simply make popcountdi available in the
On Fri, Jul 12, 2019 at 8:11 PM Richard Biener wrote:
>
> On Wed, 10 Jul 2019, Kewen.Lin wrote:
>
> > Hi all,
> >
> > I'd like to gentle ping the below patch:
> > https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01225.html
> >
> > The previous version for more context/background:
> > https://gcc.gnu.
Hi,
This patch fixes PR91137 by finding base objects with walk_tree utility. Note
we specially return
integer_zero_node when a tree expression contains multiple base objects. This
works since the
special node is compared unequal to any real base object, thus skipped in
candidate selection.
Thi
On Wed, Jun 19, 2019 at 7:47 PM Kewen.Lin wrote:
>
> Hi all,
>
> This is the following patch after
> https://gcc.gnu.org/ml/gcc-patches/2019-06/msg00910.html
>
> Main steps:
> 1) Identify the doloop cmp type iv use and record its bind_cand (explain it
> later).
> 2) Set zero cost for pairs b
On Fri, Feb 15, 2019 at 6:52 AM Jakub Jelinek wrote:
>
> Hi!
>
> The following testcase ICEs, because we try to gimplify a complex expression
> that with -ftrapv wants to emit multiple bbs. Fixed by using
> rewrite_to_non_trapping_overflow. Bootstrapped/regtested on x86_64-linux
So with what con
On Fri, Feb 15, 2019 at 3:48 PM Jakub Jelinek wrote:
>
> On Fri, Feb 15, 2019 at 08:33:44AM +0100, Jakub Jelinek wrote:
> > On Fri, Feb 15, 2019 at 03:25:33PM +0800, Bin.Cheng wrote:
> > > So with what condition we can safely rewrite trapping operations into
> > &g
Hi,
This patch fixes PR89487 by following comments in PR. It simply avoid checking
runtime
alias by versioning in loop distribution if address of register variable may
need to be taken.
One thing I am not sure is if we should avoid generating data reference in the
first place:
Creating dr for
On Wed, Mar 13, 2019 at 3:58 AM Richard Biener wrote:
>
>
> This makes an attempt at fixing the most annoying parts of the GIMPLE
> FE unit testing - the lack of proper CFG preservation and hoops you
> need to jump through to make the CFG and SSA builders happy.
>
> Due to this the __GIMPLE specif
On Thu, Mar 21, 2019 at 12:57 PM JunMa wrote:
>
> Hi
> For now, gcc can not fold code like:
>
> const char a[5] = "123"
> __builtin_memchr (a, '7', sizeof a)
>
> It tries to avoid folding out of string length although length of a is 5.
> This is a bit conservative, it's safe to folding memchr/bcmp
On Thu, Mar 21, 2019 at 8:24 PM Richard Biener
wrote:
>
> On Mon, Dec 18, 2017 at 1:37 PM Richard Biener
> wrote:
> >
> > On Fri, Dec 15, 2017 at 7:39 PM, Bin.Cheng wrote:
> > > On Fri, Dec 15, 2017 at 1:19 PM, Richard Biener
> > > wrote:
> >
On Tue, Mar 26, 2019 at 8:56 AM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Fri, Mar 22, 2019 at 7:12 AM Bin.Cheng wrote:
> >>
> >> On Thu, Mar 21, 2019 at 8:24 PM Richard Biener
> >> wrote:
> >> >
> >> &g
Hi,
As described in comments of PR89725, this patch fixes out-of-bound access during
computing classic dist/dir vector for DDR. Basically it does two things: A)
Handle
relevant chrec of outer loop in multivariate access function as invariant
symbol during
DDR analysis; B) Bypass relevant univar
loop_nest
>
>
> On Mon, Apr 1, 2019 at 5:10 AM bin.cheng wrote:
> >
> > Hi,
> >
> > As described in comments of PR89725, this patch fixes out-of-bound access
> > during
> > computing classic dist/dir vector for DDR. Basically it does two things:
Hi,
This patch fixes ICE reported by PR90021. The issue has been there since loop
interchange
and recently exposed by patch for PR89725. As PR comment suggests, we have
equal access
function {{1, +, 1}_6, +, 1}_4 and _6 is of loop_nest's outer loop. This patch
introduces
new parameter loopnum
Hi,
As discussed in PR90078, this patch checks possible infinite_cost overflow in
ivopts.
Also as discussed, overflow happens mostly because of cost scaling wrto
bb_freq/loop_freq.
For the moment, we only implement capping in comp_cost operators, while in next
stage1, we may instead implement cap
On Wed, Apr 17, 2019 at 3:10 PM Jakub Jelinek wrote:
>
> On Wed, Apr 17, 2019 at 02:13:12PM +0800, bin.cheng wrote:
> > Hi,
> > As discussed in PR90078, this patch checks possible infinite_cost overflow
> > in ivopts.
> > Also as discussed, overflow happens mostl
Thanks very much for working on this.
On Wed, Apr 24, 2019 at 4:41 PM Kewen.Lin wrote:
>
> Hi all,
>
> As PR80791 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80791, on
> some targets which support low-overhead loop, the related compare
> type ivs use is possible to become dead and removed eventu
On Fri, Apr 26, 2019 at 2:44 PM Kewen.Lin wrote:
>
> Hi Segher,
>
> Thanks a lot for your comments!
>
> on 2019/4/25 下午8:16, Segher Boessenkool wrote:
>
> > Does it create worse code now? What we have before your patch isn't
> > so super either (it has an sldi in the loop, it has two mtctr too).
Hi,
This is the draft patch avoiding scaling cost overflow by introducing a scaling
bound
in IVOPTs. For now the bound is 20, and scaling factor will be further scaled
wrto
this bound. For example, scaling factor like 1, 1000, 2000(max) would be
scaled to
1, 10, 20 correspondingly.
HI Martin
On Mon, Apr 29, 2019 at 8:01 PM Richard Biener
wrote:
>
> On Sat, Apr 27, 2019 at 6:13 AM bin.cheng wrote:
> >
> > Hi,
> >
> > This is the draft patch avoiding scaling cost overflow by introducing a
> > scaling bound
> > in IVOPTs. For now the bound
On Sun, May 5, 2019 at 11:23 AM Kewen.Lin wrote:
>
> Hi Bin,
>
> Sorry for late response (just back from vacation).
>
> Thanks very much for your comments.
>
> on 2019/4/27 上午11:20, Bin.Cheng wrote:
> > For such non-trivial patch, we can improve review process by sp
gt;
>
> On Sat, Apr 27, 2019 at 6:13 AM bin.cheng wrote:
> >
> > > Hi,
> >
> > This is the draft patch avoiding scaling cost overflow by introducing a
> > scaling bound
> > in IVOPTs. For now the bound is 20, and scaling factor will be further
>
ed, Apr 17, 2019 at 07:14:05PM +0800, Bin.Cheng wrote:
> > > As
> > > #define INFTY 1000
> > > what is the reason to keep the previous condition as well?
> > > I mean, if cost1.cost == INFTY or cost2.cost == INFTY,
> > > cost1.cost + cost2.cost >=
low by introducing
> scaling bound
>
>
> On Sat, Apr 27, 2019 at 6:13 AM bin.cheng wrote:
> >
> > > Hi,
> >
> > This is the draft patch avoiding scaling cost overflow by introducing a
> > scaling bound
> > in IVOPTs. For now the bound is 20, and scaling
On Sun, May 5, 2019 at 2:02 PM Kewen.Lin wrote:
>
> on 2019/5/5 下午12:04, Bin.Cheng wrote:
> > On Sun, May 5, 2019 at 11:23 AM Kewen.Lin wrote:
> >>>> + /* Some compare iv_use is probably useless once the doloop
> >>>> optimization
> >&g
On Mon, May 6, 2019 at 6:11 PM Richard Biener
wrote:
>
> On Sun, May 5, 2019 at 8:03 AM bin.cheng wrote:
> >
> > > --
> > > Sender:Jakub Jelinek
> > > Sent At:2019 Apr. 17 (Wed.) 19:27
> &
On Thu, May 9, 2019 at 5:31 AM Jeff Law wrote:
>
> On 5/8/19 6:28 AM, Richard Biener wrote:
> > On Wed, May 8, 2019 at 12:09 PM JunMa wrote:
> >>
> >> Hi
> >>
> >> As PR90106 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106),
> >> when gcc meets builtin function call like:
> >>
> >>y = sqr
Hi,
While working on other PR, I noticed that we can save lots of if-then-else in
accessing
cand_vec by placing an additional NULL element at front of it.
Bootstrap and test on x86_64. Is it OK?
Thanks,
bin
2019-05-13 Bin Cheng
* gimple-ssa-strength-reduction.c (lookup_cand): Adjus
I wonder if you can factor out generic part into GIMPLE and leave
target hook as specific as possible?
On Tue, May 14, 2019 at 11:10 AM wrote:
>
> From: Kewen Lin
>
> Previous version link for background:
> https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00912.html
>
> This hook is to predict whet
Hi,
As noted in PR57534 comment #33, SLSR currently doesn't strength reduce memory
references in reported cases, which conflicts with its comment at the beginning
of file.
The main reason is in functions slsr_process_ref and restructure_reference which
rejects MEM_REF by handled_compoenent_p in th
Hi,
I noticed that slsr_process_copy and slsr_process_cast are almost identical
and called only once. This patch refactor the two functions into one.
For copies, it also passes lhs' type to creation of new cand assuming that
lhs, rhs and base_cand have the same/compatible type. I will keep an eye
Hi,
I noticed that cand_chain (first_interp/next_interp) is not maintained correctly
in slsr_process_copy/slsr_process_cast (now slsr_process_copycast). This one
fixes the issue, as well as records the "first" cand in stmt_cand_map.
Hi Bill, is this correct or I misunderstood the code? Bootstrap
On Wed, May 15, 2019 at 1:20 PM Kewen.Lin wrote:
>
> on 2019/5/15 上午11:34, Kewen.Lin wrote:
> >
> > on 2019/5/15 上午10:40, Bin.Cheng wrote:
> >> I wonder if you can factor out generic part into GIMPLE and leave
> >> target hook as specific as possible?
> &
On Wed, May 15, 2019 at 4:38 PM Kewen.Lin wrote:
>
> on 2019/5/15 上午10:11, Kewen.Lin wrote:
> >
> > on 2019/5/14 下午3:18, Richard Biener wrote:
> >> Hum. The function is somewhat of a hack, trying to produce
> >> "reasonable" DECL_RTL, exposing it in expr.[ch] with this
> >> name is eventually mis
On Wed, May 15, 2019 at 5:51 PM Kewen.Lin wrote:
>
> on 2019/5/15 下午4:50, Bin.Cheng wrote:
> > On Wed, May 15, 2019 at 4:38 PM Kewen.Lin wrote:
> >>
> >> on 2019/5/15 上午10:11, Kewen.Lin wrote:
> >>>
> >>> on 2019/5/14 下午3:18, Richard Biener
e.
Thanks,
bin
>
> Bill
>
>
> On 5/16/19 6:37 AM, Richard Biener wrote:
> > On Wed, May 15, 2019 at 6:30 AM bin.cheng
> > wrote:
> >> Hi,
> >> As noted in PR57534 comment #33, SLSR currently doesn't strength reduce
> >> memory
On Tue, May 21, 2019 at 1:50 PM Kewen.Lin wrote:
>
> on 2019/5/20 下午10:43, Jeff Law wrote:
> > On 5/20/19 4:24 AM, Segher Boessenkool wrote:
> >> Let me try to answer a bit here...
> >>
> >> On Mon, May 20, 2019 at 11:28:26AM +0200, Richard Biener wrote:
> >>> On Thu, 16 May 2019, li...@linux.ibm.
On Mon, Jan 14, 2019 at 4:07 PM Andi Kleen wrote:
>
> Bin Cheng,
>
> I did some testing on this now. The attached patch automatically increases
> the iterations
> for autofdo profiles.
Hi Andi, thanks very much for tuning these.
>
> But even with even more iterations I still have stable failures
On Mon, Jan 14, 2019 at 4:20 PM Andi Kleen wrote:
>
> From: Andi Kleen
>
> autoprofiledbootstrap fails currently with
>
> In file included from ../../gcc/gcc/hash-table.h:236,
> from ../../gcc/gcc/coretypes.h:440,
> from ../../gcc/gcc/ipa-devirt.c:110:
> In stati
Hi,
This simple patch fixes the ICE by getting loop bbs in dominance order and
sorting
chain references against it. Previously it didn't take dominance in
consideration for
loop thus resulted in use-before-def issue.
After looking at the code closer, I think sorting references isn't necessary,
On Tue, Jan 15, 2019 at 1:10 AM Andi Kleen wrote:
>
> On Mon, Jan 14, 2019 at 04:15:20PM +0800, Bin.Cheng wrote:
> > On Mon, Jan 14, 2019 at 4:07 PM Andi Kleen wrote:
> > >
> > > Bin Cheng,
> > >
> > > I did some testing on this now. The a
On Wed, Aug 3, 2016 at 11:17 PM, Jeff Law wrote:
> On 08/03/2016 10:35 AM, Bin Cheng wrote:
>>
>> Hi,
>> When I introduced parameter STOP for expand_simple_operations, I also
>> added it for simplify_using_initial_conditions. The STOP argument is also
>> passed to simplify_using_initial_condition
On Thu, Aug 4, 2016 at 1:48 PM, Richard Biener
wrote:
> On Thu, Aug 4, 2016 at 10:40 AM, Bin.Cheng wrote:
>> On Wed, Aug 3, 2016 at 11:17 PM, Jeff Law wrote:
>>> On 08/03/2016 10:35 AM, Bin Cheng wrote:
>>>>
>>>> Hi,
>>>> When I introduc
On Mon, Aug 8, 2016 at 11:40 AM, James Greenhalgh
wrote:
> On Mon, Aug 01, 2016 at 01:18:53PM +, Bin Cheng wrote:
>> Hi,
>> This is the 3rd version patch implementing vcond_mask and vec_cmp patterns on
>> AArch64. Bootstrap and test along with next patch on AArch64, is it OK?
>
> OK, with a c
On Fri, Aug 5, 2016 at 11:48 AM, Richard Biener wrote:
>
> This fixes PR72772 by avoing placing a degenerate PHI in each
> forwarder block loop init creates when creating simple preheaders.
> The solution is to simply split the single loop entry edge which
> is also way cheaper than using the forw
On Sat, Aug 6, 2016 at 9:20 PM, Andreas Schwab wrote:
> On Mi, Jul 13 2016, "Bin.Cheng" wrote:
>
>> Patch re-tested/applied on trunk as r238301.
>
> This breaks gcc.dg/vect/vect-117.c on powerpc.
Hi Andreas,
Sorry for the inconvenience, I will have a lo
On Thu, Aug 11, 2016 at 8:08 AM, Andreas Schwab wrote:
> ../../gcc/config/aarch64/aarch64-simd.md: In function 'rtx_def*
> gen_vec_cmpv2sfv2si(rtx, rtx, rtx, rtx)':
> ../../gcc/config/aarch64/aarch64-simd.md:2498:17: error: 'comparison' may be
> used uninitialized in this function [-Werror=maybe
On Thu, Aug 11, 2016 at 9:36 AM, Bin.Cheng wrote:
> On Thu, Aug 11, 2016 at 8:08 AM, Andreas Schwab wrote:
>> ../../gcc/config/aarch64/aarch64-simd.md: In function 'rtx_def*
>> gen_vec_cmpv2sfv2si(rtx, rtx, rtx, rtx)':
>> ../../gcc/config/aarch64/aarch64-simd.md:2
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,
>> Due to some reasons, tree-if-conv.c now factors floating point comparison
>> out of cond_expr,
>> resulting in mixed types in it. This does help CSE on common comparison
>> ope
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 Tue, Aug 9, 2016 at 4:43 PM, Bin.Cheng wrote:
> On Sat, Aug 6, 2016 at 9:20 PM, Andreas Schwab wrote:
>> On Mi, Jul 13 2016, "Bin.Cheng" wrote:
>>
>>> Patch re-tested/applied on trunk as r238301.
>>
>> This breaks gcc.dg/vect/vect-117.c on powerp
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
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 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, May 27, 2016 at 11:45 AM, Richard Biener
wrote:
> On Wed, May 25, 2016 at 1:22 PM, Bin Cheng wrote:
>> Hi,
>> As analyzed in PR68303 and PR69710, vectorizer generates duplicated
>> computations in loop's pre-header basic block when creating base address for
>> vector reference to the sa
On Fri, May 27, 2016 at 12:56 PM, Richard Biener
wrote:
> On Fri, May 27, 2016 at 1:11 PM, Bin.Cheng wrote:
>> On Fri, May 27, 2016 at 11:45 AM, Richard Biener
>> wrote:
>>> On Wed, May 25, 2016 at 1:22 PM, Bin Cheng wrote:
>>>> Hi,
>>>> As analy
On Fri, Jun 17, 2016 at 3:33 PM, Ilya Enkovich wrote:
> 2016-06-16 9:00 GMT+03:00 Jeff Law :
>> On 05/19/2016 01:39 PM, Ilya Enkovich wrote:
>>>
>>> Hi,
>>>
>>> This patch introduces changes required to run vectorizer on loop epilogue.
>>> This also enables epilogue vectorization using a vector of
On Fri, Jun 17, 2016 at 4:37 PM, Jeff Law wrote:
> On 06/17/2016 08:48 AM, Bin.Cheng wrote:
>>>>
>>>>
>>>>> + /* FORNOW: Currently alias checks are not inherited for epilogues.
>>>>> + Don't try to vectorize epilog
On Mon, Jun 20, 2016 at 9:18 AM, Christophe Lyon
wrote:
> On 18 June 2016 at 10:59, Andreas Schwab wrote:
>> Bin Cheng writes:
>>
>>> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr71347.c
>>> b/gcc/testsuite/gcc.dg/tree-ssa/pr71347.c
>>> new file mode 100644
>>> index 000..7e5ad49
>>> --- /d
On Mon, Jun 20, 2016 at 9:20 AM, Bin.Cheng wrote:
> On Mon, Jun 20, 2016 at 9:18 AM, Christophe Lyon
> wrote:
>> On 18 June 2016 at 10:59, Andreas Schwab wrote:
>>> Bin Cheng writes:
>>>
>>>> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr71347.c
>
On Tue, Jun 14, 2016 at 1:57 PM, Richard Biener
wrote:
> On Mon, Jun 13, 2016 at 12:01 PM, Bin Cheng wrote:
>> Hi,
>> GCC vectorizer generates many unnecessary runtime alias checks known at
>> compilation time. For some data-reference pairs, alias relation can be
>> resolved at compilation tim
On Thu, Oct 12, 2017 at 2:43 PM, Richard Biener
wrote:
> On Thu, Oct 5, 2017 at 3:17 PM, Bin Cheng wrote:
>> Hi,
>> This patch merges adjacent memset builtin partitions if possible. It is
>> a useful special case optimization transforming below code:
>>
>> #define M (256)
>> #define N (512)
>>
>
401 - 500 of 919 matches
Mail list logo
