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
> >>> calls within NEXT_INSN and PREV_INSN; do you happen to have
> >>> inf
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
calls within NEXT_INSN and PREV_INSN; do you happen to have
information handy on that?
Yes that's right:
- 1.03% lto1
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 suppo
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 machine_mo
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;
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
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
> > 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
> On Thu, Sep 4, 2014 at 5:58 AM, Andi Kleen 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
On Thu, Sep 4, 2014 at 5:58 AM, Andi Kleen 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 passes is a ma
>
> 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
On Tue, Sep 2, 2014 at 6:52 PM, Andi Kleen 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 with the ongoin
On Tue, Sep 2, 2014 at 6:52 PM, Andi Kleen 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 with the ongoin
> I suspect the bulk of them currently are coming from the safe_as_a
> 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_helper::test(rtx_def*)
> 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
--
a...@linux.
On Tue, 2014-09-02 at 00:03 -0700, Andi Kleen wrote:
> From: Andi Kleen
>
> 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". An
On Tue, Sep 2, 2014 at 10:36 AM, Steven Bosscher 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 those
> On Sep 2, 2014, at 1:36 AM, Steven Bosscher 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, 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
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 cannot change.
Thanks,
Andrew
>
> -Andi
> 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:03 AM, Andi Kleen wrote:
> From: Andi Kleen
>
> 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
From: Andi Kleen
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 called.
Mark them all wi
22 matches
Mail list logo
