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
>
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
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
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 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).
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 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
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
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
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,
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
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
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 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 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
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 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
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 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
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 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
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 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 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 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 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
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
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
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
>
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 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 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 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
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 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: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 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
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
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
--
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
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
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
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
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,
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 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,
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,
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
On Thu, Sep 20, 2018 at 6:43 PM Jan Hubicka wrote:
>
> > On Thu, Sep 20, 2018 at 5:26 PM Jan Hubicka wrote:
> > >
> > > > On Thu, Sep 20, 2018 at 2:11 AM Martin Liška wrote:
> > > > >
> > > > > Hello.
> > > > >
> > > > > I've been working for some time on a patch that simplifies how we set
> > >
On Thu, Sep 20, 2018 at 5:26 PM Jan Hubicka wrote:
>
> > On Thu, Sep 20, 2018 at 2:11 AM Martin Liška wrote:
> > >
> > > Hello.
> > >
> > > I've been working for some time on a patch that simplifies how we set
> > > the hotness threshold of basic blocks. Currently, we calculate so called
> > > ar
On Thu, Sep 20, 2018 at 2:11 AM Martin Liška wrote:
>
> Hello.
>
> I've been working for some time on a patch that simplifies how we set
> the hotness threshold of basic blocks. Currently, we calculate so called
> arc profile histograms that should identify edges that cover 99.9% of all
> branchin
On Thu, Aug 30, 2018 at 2:47 AM Richard Sandiford
wrote:
>
> Joey Ye writes:
> > diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> > index 07c55b1..9e965ab 100644
> > --- a/gcc/config/aarch64/aarch64.c
> > +++ b/gcc/config/aarch64/aarch64.c
> > @@ -5674,9 +5674,6 @@ aarch
On Tue, Aug 21, 2018 at 9:59 PM Richard Sandiford
wrote:
>
> David Edelsohn writes:
> > I am pleased to announce that the GCC Steering Committee has
> > appointed Richard Sandiford as a Global Reviewer.
> >
> > Please join me in congratulating Richard on his new role.
> > Richard, ple
al optimizations?
I am not aware of one for unsigned integer, and I guess it won't be
introduced in the future either?
Thanks,
bin
>
>
>
> On 7/13/18 9:14 PM, Bin.Cheng wrote:
>> On Fri, Jul 13, 2018 at 6:04 AM, Kelvin Nilsen
>> wrote:
>>> A somewhat old
On Fri, Jun 29, 2018 at 9:54 PM, Martin Liška wrote:
> On 06/22/2018 10:35 PM, Jeff Law wrote:
>> On 05/16/2018 05:53 AM, Martin Liška wrote:
>>> On 12/21/2017 10:13 AM, Martin Liška wrote:
On 12/20/2017 06:45 PM, Jakub Jelinek wrote:
> Another thing is that the "/" in there is wrong, so
On Fri, Jul 13, 2018 at 6:04 AM, Kelvin Nilsen wrote:
> A somewhat old "issue report" pointed me to the code generated for a 4-fold
> manually unrolled version of the following loop:
>
>> while (++len != len_limit) /* this is loop */
>> if (pb[l
On Mon, Jun 25, 2018 at 1:50 PM, Kugan Vivekanandarajah
wrote:
> Hi Bin,
>
> On 25 June 2018 at 13:56, Bin.Cheng wrote:
>> On Mon, Jun 25, 2018 at 11:37 AM, Kugan Vivekanandarajah
>> wrote:
>>> Hi Bin,
>>>
>>> Thanks for your comments.
>>>
On Mon, Jun 25, 2018 at 11:37 AM, Kugan Vivekanandarajah
wrote:
> Hi Bin,
>
> Thanks for your comments.
>
> On 25 June 2018 at 11:15, Bin.Cheng wrote:
>> On Fri, Jun 22, 2018 at 5:11 PM, Kugan Vivekanandarajah
>> wrote:
>>> When we set niter with maybe_ze
On Fri, Jun 22, 2018 at 5:11 PM, Kugan Vivekanandarajah
wrote:
> When we set niter with maybe_zero, currently final_value_relacement
> will not happen due to expression_expensive_p not handling. Patch 1
> adds this.
>
> With that we have the following optimized gimple.
>
>[local count: 1181116
Hi,
I've updated my email address in MAINTAINERS file.
I don't have FSF copyright assignment record for am...@gcc.gnu.org but
will sort it out before next commit to GCC.
Thanks,
bin
--- trunk/ChangeLog 2018/06/01 18:46:23 261078
+++ trunk/ChangeLog 2018/06/01 19:53:31 261079
@@ -1,3 +1,7 @@
+2018
On Fri, Jun 1, 2018 at 9:56 AM, Kugan Vivekanandarajah
wrote:
> Hi Bin,
>
> Thanks a lo for the review.
>
> On 1 June 2018 at 03:45, Bin.Cheng wrote:
>> On Thu, May 31, 2018 at 3:51 AM, Kugan Vivekanandarajah
>> wrote:
>>> Hi Bin,
>>>
>>>
On Thu, May 31, 2018 at 3:51 AM, Kugan Vivekanandarajah
wrote:
> Hi Bin,
>
> Thanks for the review. Please find the revised patch based on the
> review comments.
>
> Thanks,
> Kugan
>
> On 17 May 2018 at 19:56, Bin.Cheng wrote:
>> On Thu, May 17, 2018 at 2:39 AM,
On Tue, May 29, 2018 at 6:18 PM, David Malcolm wrote:
> On Tue, 2018-05-29 at 17:04 +0100, Bin.Cheng wrote:
>> On Fri, May 4, 2018 at 5:24 PM, Bin Cheng wrote:
>> > Hi,
>> > This patch restricts predcom pass using register pressure
>> > information.
>> &
On Fri, May 4, 2018 at 5:24 PM, Bin Cheng wrote:
> Hi,
> This patch restricts predcom pass using register pressure information.
> In case of high register pressure, we now prune additional chains as well
> as disable unrolling in predcom. In generally, I think this patch set is
> useful.
>
> Boot
On Mon, May 28, 2018 at 12:22 PM, Richard Biener
wrote:
> On Fri, May 18, 2018 at 1:57 PM Bin.Cheng wrote:
>
>> On Fri, May 4, 2018 at 5:23 PM, Bin Cheng wrote:
>> > Hi,
>> > Based on previous patch, this one implements live range, reg pressure
> computation
&g
On Thu, May 24, 2018 at 11:55 PM, Jeff Law wrote:
> On 05/18/2018 02:40 AM, Bin.Cheng wrote:
>> On Fri, May 4, 2018 at 5:21 PM, Bin Cheng wrote:
>>> Hi,
>>> This is the updated version patch set computing register pressure on TREE
>>> SSA
>>>
On Wed, May 23, 2018 at 12:12 PM, Richard Biener
wrote:
> On Wed, May 23, 2018 at 1:10 PM Bin.Cheng wrote:
>
>> On Wed, May 23, 2018 at 12:01 PM, Richard Sandiford
>> wrote:
>> > "Bin.Cheng" writes:
>> >> On Wed, May 23, 2018 at 11:19 AM, R
On Wed, May 23, 2018 at 12:01 PM, Richard Sandiford
wrote:
> "Bin.Cheng" writes:
>> On Wed, May 23, 2018 at 11:19 AM, Richard Biener
>> wrote:
>>> On Tue, May 22, 2018 at 2:11 PM Richard Sandiford <
>>> richard.sandif...@linaro.org> wrote:
>&
On Wed, May 23, 2018 at 11:19 AM, Richard Biener
wrote:
> On Tue, May 22, 2018 at 2:11 PM Richard Sandiford <
> richard.sandif...@linaro.org> wrote:
>
>> Richard Biener writes:
>> > On Mon, May 21, 2018 at 3:14 PM Bin Cheng wrote:
>> >
>> >> Hi,
>> >> As reported in PR85804, bump step is wrongly
On Fri, May 4, 2018 at 5:23 PM, Bin Cheng wrote:
> Hi,
> Based on previous patch, this one implements live range, reg pressure
> computation
> class in tree-ssa-live.c. The user would only need to instantiate the class
> and
> call the computation interface as in next patch.
> During the work,
On Fri, May 4, 2018 at 5:21 PM, Bin Cheng wrote:
> Hi,
> This is the second patch computing available/clobber registers for register
> classes.
> It's the same as the original patch posted
> @https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01022.html
>
> Bootstrap and test on x86_64 and AArch64 on
On Fri, May 4, 2018 at 5:21 PM, Bin Cheng wrote:
> Hi,
> This is the updated version patch set computing register pressure on TREE SSA
> and use that information to direct other loop optimizers (predcom only for
> now).
> This version of change is to follow Jeff's comment that we should reuse
>
On Thu, May 17, 2018 at 3:04 PM, Richard Biener
wrote:
> On Tue, May 15, 2018 at 5:44 PM Bin.Cheng wrote:
>
>> On Fri, May 11, 2018 at 1:53 PM, Richard Biener
>> wrote:
>> > On Fri, May 4, 2018 at 6:23 PM, Bin Cheng wrote:
>> >> Hi,
>> >> F
On Thu, May 17, 2018 at 11:07 AM, Richard Biener
wrote:
> On Wed, May 16, 2018 at 5:13 PM Bin Cheng wrote:
>
>> Hi,
>> This patch fixes ICE by loading vector(1) scalar_type if it's 1
> element-wise for VMAT_ELEMENTWISE.
>> Bootstrap and test on x86_64 and AArch64 ongoing. Is it OK?
>
> OK.
Boots
On Thu, May 17, 2018 at 2:39 AM, Kugan Vivekanandarajah
wrote:
> Hi Richard,
>
> On 6 March 2018 at 02:24, Richard Biener wrote:
>> On Thu, Feb 8, 2018 at 1:41 AM, Kugan Vivekanandarajah
>> wrote:
>>> Hi Richard,
>>>
>>> On 1 February 2018 at 23:21, Richard Biener
>>> wrote:
On Thu, Feb 1
On Fri, May 11, 2018 at 1:53 PM, Richard Biener
wrote:
> On Fri, May 4, 2018 at 6:23 PM, Bin Cheng wrote:
>> Hi,
>> Following Jeff's suggestion, I am now using existing tree-ssa-live.c and
>> tree-ssa-coalesce.c to compute register pressure, rather than inventing
>> another live range solver.
>>
On Thu, Mar 22, 2018 at 11:07 AM, Bin.Cheng wrote:
> On Sat, Mar 17, 2018 at 8:54 AM, Richard Sandiford
> wrote:
>> Kyrill Tkachov writes:
>>> Hi Bin,
>>>
>>> On 16/03/18 11:42, Bin Cheng wrote:
>>>> Hi,
>>>> This simple patch fix
On Wed, Apr 11, 2018 at 10:46 AM, Richard Biener
wrote:
> On Tue, Apr 10, 2018 at 6:28 PM, Bin.Cheng wrote:
>> On Tue, Apr 10, 2018 at 3:58 PM, Bin.Cheng wrote:
>>> On Tue, Apr 10, 2018 at 2:26 PM, Jakub Jelinek wrote:
>>>> On Tue, Apr 10, 2018 at 09:55:35AM +0
On Tue, Apr 10, 2018 at 5:28 PM, Bin.Cheng wrote:
> On Tue, Apr 10, 2018 at 3:58 PM, Bin.Cheng wrote:
>> On Tue, Apr 10, 2018 at 2:26 PM, Jakub Jelinek wrote:
>>> On Tue, Apr 10, 2018 at 09:55:35AM +, Bin Cheng wrote:
>>>> Hi Rainer, could you please help me
On Tue, Apr 10, 2018 at 3:58 PM, Bin.Cheng wrote:
> On Tue, Apr 10, 2018 at 2:26 PM, Jakub Jelinek wrote:
>> On Tue, Apr 10, 2018 at 09:55:35AM +, Bin Cheng wrote:
>>> Hi Rainer, could you please help me double check that this solves the issue?
>>>
>>> T
On Tue, Apr 10, 2018 at 2:26 PM, Jakub Jelinek wrote:
> On Tue, Apr 10, 2018 at 09:55:35AM +, Bin Cheng wrote:
>> Hi Rainer, could you please help me double check that this solves the issue?
>>
>> Thanks,
>> bin
>>
>> gcc/testsuite
>> 2018-04-10 Bin Cheng
>>
>> PR testsuite/85190
>>
On Wed, Apr 4, 2018 at 8:08 AM, Gerald Pfeifer wrote:
> On Tue, 3 Apr 2018, Bin Cheng wrote:
>> Option -ftree-loop-distribution is improved and enabled by default at
>> -O3 for GCC8. This patch describes the change, is it OK?
>
> Index: htdocs/gcc-8/changes.html
> =
On Sat, Mar 17, 2018 at 8:54 AM, Richard Sandiford
wrote:
> Kyrill Tkachov writes:
>> Hi Bin,
>>
>> On 16/03/18 11:42, Bin Cheng wrote:
>>> Hi,
>>> This simple patch fixes test case failure for pr84682-2.c by returning
>>> false on wrong mode rtx in aarch64_classify_address, rather than assert.
On Wed, Mar 21, 2018 at 3:06 PM, Tom de Vries wrote:
> On 03/12/2018 01:14 PM, Richard Biener wrote:
>>
>> On Thu, 22 Feb 2018, Tom de Vries wrote:
>>
>>> Hi,
>>>
>>> this patch fixes an ICE in the parloops pass.
>>>
>>> The ICE (when compiling the test-case in attached patch) follows from the
>>>
On Tue, Mar 20, 2018 at 5:56 PM, Richard Biener
wrote:
> On March 20, 2018 6:11:53 PM GMT+01:00, "Bin.Cheng"
> wrote:
>>On Mon, Mar 19, 2018 at 5:08 PM, Aldy Hernandez
>>wrote:
>>> Hi Richard.
>>>
>>> As discussed in the PR, the problem he
On Mon, Mar 19, 2018 at 5:08 PM, Aldy Hernandez wrote:
> Hi Richard.
>
> As discussed in the PR, the problem here is that we have two different
> iterations of an IV live outside of a loop. This inhibits us from using
> autoinc/dec addressing on ARM, and causes extra lea's on x86.
>
> An abbrevia
On Mon, Mar 19, 2018 at 11:57 AM, Jakub Jelinek wrote:
> On Fri, Mar 16, 2018 at 03:08:17PM +0100, Richard Biener wrote:
>> Bootstrapped and tested on x86_64-unknown-linux-gnu, ok?
>
> Ok, thanks.
Hi Richard,
This change causes below test failure on aarch64/arm linux:
FAIL: libgomp.graphite/force
On Thu, Mar 15, 2018 at 1:32 AM, Paul Hua wrote:
> Hi:
>
> The fixits-pr84852-1.c fails on mips64el target.
Hi,
It fails on aarch64/arm bare-metal cross toolchains with different message like:
ERROR: gcc.dg/fixits-pr84852-1.c: bad option "-812156810": must be
-exact, -glob, -regexp, or -- for " dg
On Thu, Mar 15, 2018 at 1:07 PM, Jakub Jelinek wrote:
> On Thu, Mar 15, 2018 at 01:56:16PM +0100, Richard Biener wrote:
>> The following fixes the C familiy gimplification langhook to not
>> introduce tree sharing which isn't valid during gimplification.
>> For the specific case the tree sharing i
On Thu, Mar 15, 2018 at 3:54 PM, Jakub Jelinek wrote:
> On Thu, Mar 15, 2018 at 03:45:47PM +0000, Bin.Cheng wrote:
>> FYI, both your patches fix the compilation issue.
>
> It isn't just a compilation problem, it really can't work at all.
> Without the patch, if the fu
On Thu, Mar 15, 2018 at 3:08 PM, Jakub Jelinek wrote:
> On Thu, Mar 15, 2018 at 07:10:26AM -0700, Steve Kargl wrote:
>> On Thu, Mar 15, 2018 at 01:35:23PM +0100, Richard Biener wrote:
>> > >
>> > > extern GFC_INTEGER_4 kill (GFC_INTEGER_4, GFC_INTEGER_4);
>> > > extern __typeof(kill) kill __asm__(
On Fri, Feb 16, 2018 at 5:18 PM, wrote:
> From: Vladimir Mezentsev
>
> Ramana Radhakrishnan made a workaround in gcc/config/aarch64/aarch64.c to
> resolve
> bootstrap comparison failure (2015-11-10, commit
> bc443a71dafa2e707bae4b2fa74f83b05dea37ab).
> The real bug is in gcc/varasm.c.
> hash_s
On Thu, Mar 15, 2018 at 12:11 PM, Bin.Cheng wrote:
> On Thu, Mar 15, 2018 at 10:18 AM, Bin.Cheng wrote:
>> On Wed, Mar 14, 2018 at 12:57 AM, Steve Kargl
>> wrote:
>>> On Tue, Mar 13, 2018 at 09:49:10PM +0200, Janne Blomqvist wrote:
>>>>
>>>> int
On Thu, Mar 15, 2018 at 10:18 AM, Bin.Cheng wrote:
> On Wed, Mar 14, 2018 at 12:57 AM, Steve Kargl
> wrote:
>> On Tue, Mar 13, 2018 at 09:49:10PM +0200, Janne Blomqvist wrote:
>>>
>>> int val = kill (pid, signal);
>>> return (val == 0): 0 ? errno;
>&g
On Wed, Mar 14, 2018 at 12:57 AM, Steve Kargl
wrote:
> On Tue, Mar 13, 2018 at 09:49:10PM +0200, Janne Blomqvist wrote:
>>
>> int val = kill (pid, signal);
>> return (val == 0): 0 ? errno;
>>
>> like it already does for the optional status argument for kill_sub.
>>
>
> Committed as r258511 with yo
On Wed, Mar 14, 2018 at 8:03 AM, Alexandre Oliva wrote:
> On Mar 12, 2018, "Bin.Cheng" wrote:
>
>> internal compiler error: in aarch64_classify_address, at
>> config/aarch64/aarch64.c:5678
>> 0xfe3c29 aarch64_classify_address
>> /.../build/s
On Fri, Mar 9, 2018 at 6:45 AM, Alexandre Oliva wrote:
> LRA gets very confused when non-addresses are passed as operands to
> asms with address contraints. Even if other constraints are
> available, and the operand is a perfect fit for them, we'd still
> attempt to process the operand as an addr
into when/why it
is triggered in vect_peeling only for some targets.
Honza asked couple questions about my patch offline, I will revisit
the patch, see how to address
his concern.
Thanks,
bin
>
> Thanks.
>
> On Mon, Feb 26, 2018 at 8:02 PM, Bin.Cheng wrote:
>> Ping^2
>>
On Wed, Feb 28, 2018 at 6:17 AM, Alexandre Oliva wrote:
> On Feb 21, 2018, Alexandre Oliva wrote:
>
>> On Feb 15, 2018, Szabolcs Nagy wrote:
>>> i see assembler slow downs with these location view patches
>>> i opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84408
>
>
>> [LVU] reset view at
101 - 200 of 919 matches
Mail list logo
