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
21 matches
Mail list logo
