On 09/04/14 14:22, Jakub Jelinek wrote:
On Thu, Sep 04, 2014 at 04:04:17PM -0400, David Malcolm wrote:
--- a/gcc/rtl.h
+++ b/gcc/rtl.h
@@ -195,6 +195,7 @@ union rtunion
unsigned int rt_uint;
const char *rt_str;
rtx rt_rtx;
+ rtx_insn *rt_insn;
rtvec rt_rtvec;
enum
On 09/04/14 15:19, David Malcolm wrote:
I suppose so, but I don't see an easy way of locating such XEXP users
beyond building with ENABLE_RTL_CHECKING, and checking on every
configuration, and trying to exercise all code paths. Can we consider
that a *long-term* followup?
Well, XEXP isn't
On 09/04/14 14:04, David Malcolm wrote:
On Tue, 2014-09-02 at 19:50 +0200, Andi Kleen wrote:
I suspect the bulk of them currently are coming from the safe_as_a
rtx_insn * calls within NEXT_INSN and PREV_INSN; do you happen to have
information handy on that?
Yes that's right:
- 1.03% lto1
On Fri, 2014-09-05 at 12:45 -0600, Jeff Law wrote:
On 09/04/14 14:04, David Malcolm wrote:
On Tue, 2014-09-02 at 19:50 +0200, Andi Kleen wrote:
I suspect the bulk of them currently are coming from the safe_as_a
rtx_insn * calls within NEXT_INSN and PREV_INSN; do you happen to have
On Thu, Sep 4, 2014 at 5:58 AM, Andi Kleen a...@firstfloor.org wrote:
Anyway, removing !optimize checks in favor of flag_no_inline checks
and initializing that properly is a cleanup as well.
Patch looks good to me.
Unfortunately it doesn't pass bootstrap (inline-summary re-use
between IPA
On Thu, Sep 4, 2014 at 5:58 AM, Andi Kleen a...@firstfloor.org wrote:
Anyway, removing !optimize checks in favor of flag_no_inline checks
and initializing that properly is a cleanup as well.
Patch looks good to me.
Unfortunately it doesn't pass bootstrap (inline-summary re-use
On Tue, 2014-09-02 at 19:50 +0200, Andi Kleen wrote:
I suspect the bulk of them currently are coming from the safe_as_a
rtx_insn * calls within NEXT_INSN and PREV_INSN; do you happen to have
information handy on that?
Yes that's right:
- 1.03% lto1[.] bool
On Thu, Sep 04, 2014 at 04:04:17PM -0400, David Malcolm wrote:
--- a/gcc/rtl.h
+++ b/gcc/rtl.h
@@ -195,6 +195,7 @@ union rtunion
unsigned int rt_uint;
const char *rt_str;
rtx rt_rtx;
+ rtx_insn *rt_insn;
rtvec rt_rtvec;
enum machine_mode rt_type;
addr_diff_vec_flags
On Thu, 2014-09-04 at 22:22 +0200, Jakub Jelinek wrote:
On Thu, Sep 04, 2014 at 04:04:17PM -0400, David Malcolm wrote:
--- a/gcc/rtl.h
+++ b/gcc/rtl.h
@@ -195,6 +195,7 @@ union rtunion
unsigned int rt_uint;
const char *rt_str;
rtx rt_rtx;
+ rtx_insn *rt_insn;
rtvec
On Tue, Sep 2, 2014 at 6:52 PM, Andi Kleen a...@linux.intel.com wrote:
Or we simply should make -finline work at -O0 (I suppose it might already
work?) and use it.
Yes that's probably better. There are more hot inlines in the stage 1 profile
(like wi::storage_ref or vec::length)
I suspect
On Tue, Sep 2, 2014 at 6:52 PM, Andi Kleen a...@linux.intel.com wrote:
Or we simply should make -finline work at -O0 (I suppose it might already
work?) and use it.
Yes that's probably better. There are more hot inlines in the stage 1 profile
(like wi::storage_ref or vec::length)
I suspect
Anyway, removing !optimize checks in favor of flag_no_inline checks
and initializing that properly is a cleanup as well.
Patch looks good to me.
-Andi
From: Andi Kleen a...@linux.intel.com
I noticed that with the trunk compiler a range of the new rtl
inlines show up as hot in a profiler during stage1. I think
that happens because stage1 is not using optimization
and does not inline plain inline. And these rtl inlines
are very frequently
On Tue, Sep 2, 2014 at 12:03 AM, Andi Kleen a...@firstfloor.org wrote:
From: Andi Kleen a...@linux.intel.com
I noticed that with the trunk compiler a range of the new rtl
inlines show up as hot in a profiler during stage1. I think
that happens because stage1 is not using optimization
and
there have been bugs in the past in the area of always_inline too.
You're arguing for my patch. It would find those bugs.
-Andi
On Tue, Sep 2, 2014 at 12:20 AM, Andi Kleen a...@firstfloor.org wrote:
there have been bugs in the past in the area of always_inline too.
You're arguing for my patch. It would find those bugs.
No I am arguing against it since the older versions of GCC we cannot change.
Thanks,
Andrew
On Tue, Sep 2, 2014 at 9:22 AM, Andrew Pinski wrote:
On Tue, Sep 2, 2014 at 12:20 AM, Andi Kleen wrote:
there have been bugs in the past in the area of always_inline too.
You're arguing for my patch. It would find those bugs.
No I am arguing against it since the older versions of GCC we
On Sep 2, 2014, at 1:36 AM, Steven Bosscher stevenb@gmail.com wrote:
On Tue, Sep 2, 2014 at 9:22 AM, Andrew Pinski wrote:
On Tue, Sep 2, 2014 at 12:20 AM, Andi Kleen wrote:
there have been bugs in the past in the area of always_inline too.
You're arguing for my patch. It would
On Tue, Sep 2, 2014 at 10:36 AM, Steven Bosscher stevenb@gmail.com wrote:
On Tue, Sep 2, 2014 at 9:22 AM, Andrew Pinski wrote:
On Tue, Sep 2, 2014 at 12:20 AM, Andi Kleen wrote:
there have been bugs in the past in the area of always_inline too.
You're arguing for my patch. It would find
On Tue, 2014-09-02 at 00:03 -0700, Andi Kleen wrote:
From: Andi Kleen a...@linux.intel.com
I noticed that with the trunk compiler a range of the new rtl
inlines show up as hot in a profiler during stage1. I think
that happens because stage1 is not using optimization
and does not inline
Or we simply should make -finline work at -O0 (I suppose it might already
work?) and use it.
Yes that's probably better. There are more hot inlines in the stage 1 profile
(like wi::storage_ref or vec::length)
I suspect with the ongoing C++'ification that will get worse.
-Andi
--
I suspect the bulk of them currently are coming from the safe_as_a
rtx_insn * calls within NEXT_INSN and PREV_INSN; do you happen to have
information handy on that?
Yes that's right:
- 1.03% lto1[.] bool
is_a_helperrtx_insn*::testrtx_def(rtx_def*)
22 matches
Mail list logo
