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