> >
> > Actually on second thought, I think I can break this either by making
> > the wraping function to be thunk or alias or by moving it to different
> > compilation unit.
> > Also with LTO we will get body later.
> >
> > So I think we need to drop this optimization.
>
> It's the same conditi
On Fri, 24 Mar 2023, Jan Hubicka wrote:
> > From d438a0d84cafced85c90204cba81de0f60ad0073 Mon Sep 17 00:00:00 2001
> > From: Richard Biener
> > Date: Thu, 16 Mar 2023 13:51:19 +0100
> > Subject: [PATCH] tree-optimization/106912 - clear const attribute from
> > fntype
> > To: gcc-patches@gcc.gnu.
> From d438a0d84cafced85c90204cba81de0f60ad0073 Mon Sep 17 00:00:00 2001
> From: Richard Biener
> Date: Thu, 16 Mar 2023 13:51:19 +0100
> Subject: [PATCH] tree-optimization/106912 - clear const attribute from fntype
> To: gcc-patches@gcc.gnu.org
>
> The following makes sure that after clearing pu
> On Fri, 17 Mar 2023, Jakub Jelinek wrote:
>
> > On Fri, Mar 17, 2023 at 08:40:34PM +0100, Jan Hubicka wrote:
> > > > + /* Drop the const attribute from the call type (the pure
> > > > + attribute is not available on types). */
> > > > + tree fntype =
On Mon, 20 Mar 2023, Richard Biener wrote:
> On Fri, 17 Mar 2023, Jakub Jelinek wrote:
>
> > On Fri, Mar 17, 2023 at 08:40:34PM +0100, Jan Hubicka wrote:
> > > > + /* Drop the const attribute from the call type (the pure
> > > > + attribute is not available on types
On Fri, 17 Mar 2023, Jakub Jelinek wrote:
> On Fri, Mar 17, 2023 at 08:40:34PM +0100, Jan Hubicka wrote:
> > > + /* Drop the const attribute from the call type (the pure
> > > +attribute is not available on types). */
> > > + tree fntype = gimple_call_fntype (call);
>
On Fri, Mar 17, 2023 at 08:40:34PM +0100, Jan Hubicka wrote:
> > + /* Drop the const attribute from the call type (the pure
> > + attribute is not available on types). */
> > + tree fntype = gimple_call_fntype (call);
> > + if (fntype && TYPE_READONLY (fn
>
> The following is what I profile-bootstrapped and tested on
> x86_64-unknown-linux-gnu.
>
> Richard.
>
> From d438a0d84cafced85c90204cba81de0f60ad0073 Mon Sep 17 00:00:00 2001
> From: Richard Biener
> Date: Thu, 16 Mar 2023 13:51:19 +0100
> Subject: [PATCH] tree-optimization/106912 - clear
On Fri, Mar 17, 2023 at 08:09:17PM +0100, Jan Hubicka wrote:
> >
> > I have in the meantime briefly tested following.
> >
> > But if you want to the above way, then at least the testcase could be
> > useful. Though, not sure if the above is all that is needed. Shouldn't
> > set_const_flag_1 upo
>
> I have in the meantime briefly tested following.
>
> But if you want to the above way, then at least the testcase could be
> useful. Though, not sure if the above is all that is needed. Shouldn't
> set_const_flag_1 upon TREE_READONLY (node->decl) = 0; also adjust
> TREE_TYPE on the function
On Thu, Mar 16, 2023 at 02:11:01PM +, Richard Biener wrote:
> > Let's wait for Honzas opinion.
>
> The following is what I profile-bootstrapped and tested on
> x86_64-unknown-linux-gnu.
>
> Richard.
>
> >From d438a0d84cafced85c90204cba81de0f60ad0073 Mon Sep 17 00:00:00 2001
> From: Richard
On Thu, 16 Mar 2023, Richard Biener wrote:
> On Thu, 16 Mar 2023, Jakub Jelinek wrote:
>
> > On Thu, Mar 16, 2023 at 12:05:56PM +, Richard Biener wrote:
> > > On Thu, 16 Mar 2023, Jakub Jelinek wrote:
> > >
> > > > On Fri, Nov 25, 2022 at 09:26:34PM +0100, Richard Biener via
> > > > Gcc-pat
On Thu, 16 Mar 2023, Jakub Jelinek wrote:
> On Thu, Mar 16, 2023 at 12:05:56PM +, Richard Biener wrote:
> > On Thu, 16 Mar 2023, Jakub Jelinek wrote:
> >
> > > On Fri, Nov 25, 2022 at 09:26:34PM +0100, Richard Biener via Gcc-patches
> > > wrote:
> > > > > We could
> > > > > probably keep tra
On Thu, Mar 16, 2023 at 12:05:56PM +, Richard Biener wrote:
> On Thu, 16 Mar 2023, Jakub Jelinek wrote:
>
> > On Fri, Nov 25, 2022 at 09:26:34PM +0100, Richard Biener via Gcc-patches
> > wrote:
> > > > We could
> > > > probably keep tract if any instrumented code was ever inlined into a
> > >
On Thu, 16 Mar 2023, Jakub Jelinek wrote:
> On Fri, Nov 25, 2022 at 09:26:34PM +0100, Richard Biener via Gcc-patches
> wrote:
> > > We could
> > > probably keep tract if any instrumented code was ever inlined into a
> > > given function and perhaps just start ignoring attributes set on types?
> >
On Fri, Nov 25, 2022 at 09:26:34PM +0100, Richard Biener via Gcc-patches wrote:
> > We could
> > probably keep tract if any instrumented code was ever inlined into a
> > given function and perhaps just start ignoring attributes set on types?
>
> But ignoring attributes on types makes all indirect
On Fri, 25 Nov 2022, Jan Hubicka wrote:
On Fri, 25 Nov 2022, Jan Hubicka wrote:
Am 25.11.2022 um 11:05 schrieb Jan Hubicka via Gcc-patches
:
IPA profile instrumentation tries to clear the pure and const
flags of functions but that's quite hopeless in particular for
const since that
> On Fri, 25 Nov 2022, Jan Hubicka wrote:
>
> > >
> > >
> > > > Am 25.11.2022 um 11:05 schrieb Jan Hubicka via Gcc-patches
> > > > :
> > > >
> > > >
> > > >>
> > > >> IPA profile instrumentation tries to clear the pure and const
> > > >> flags of functions but that's quite hopeless in parti
On Fri, 25 Nov 2022, Jan Hubicka wrote:
> >
> >
> > > Am 25.11.2022 um 11:05 schrieb Jan Hubicka via Gcc-patches
> > > :
> > >
> > >
> > >>
> > >> IPA profile instrumentation tries to clear the pure and const
> > >> flags of functions but that's quite hopeless in particular for
> > >> const
>
>
> > Am 25.11.2022 um 11:05 schrieb Jan Hubicka via Gcc-patches
> > :
> >
> >
> >>
> >> IPA profile instrumentation tries to clear the pure and const
> >> flags of functions but that's quite hopeless in particular for
> >> const since that attribute prevails on the type and thus on each
>
> Am 25.11.2022 um 11:05 schrieb Jan Hubicka via Gcc-patches
> :
>
>
>>
>> IPA profile instrumentation tries to clear the pure and const
>> flags of functions but that's quite hopeless in particular for
>> const since that attribute prevails on the type and thus on each
>> call to the funct
> IPA profile instrumentation tries to clear the pure and const
> flags of functions but that's quite hopeless in particular for
> const since that attribute prevails on the type and thus on each
> call to the function leading to inconsistencies in the IL and
> eventual checking ICEs. There's no g
IPA profile instrumentation tries to clear the pure and const
flags of functions but that's quite hopeless in particular for
const since that attribute prevails on the type and thus on each
call to the function leading to inconsistencies in the IL and
eventual checking ICEs. There's no good reason
23 matches
Mail list logo
