ments.
> > >
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > > trunk stage3 or perhaps for stage1?
>
> OK for stage 1.
Thanks, I just pushed this along with a drive-by change to
cp_walk_subtrees to use cp_unevaluated instead
of
On 12/5/22 06:09, Prathamesh Kulkarni wrote:
On Mon, 5 Dec 2022 at 09:51, Patrick Palka via Gcc-patches
wrote:
These functions currently repeatedly dereference tp during the subtree
walk, dereferences which the compiler can't CSE because it can't
guarantee that the subtree walking doesn't
On Mon, 5 Dec 2022, Prathamesh Kulkarni wrote:
> On Mon, 5 Dec 2022 at 09:51, Patrick Palka via Gcc-patches
> wrote:
> >
> > These functions currently repeatedly dereference tp during the subtree
> > walk, dereferences which the compiler can't CSE because it can't
> > guarantee that the subtree
On Mon, 5 Dec 2022 at 09:51, Patrick Palka via Gcc-patches
wrote:
>
> These functions currently repeatedly dereference tp during the subtree
> walk, dereferences which the compiler can't CSE because it can't
> guarantee that the subtree walking doesn't modify *tp.
>
> But we already implicitly
These functions currently repeatedly dereference tp during the subtree
walk, dereferences which the compiler can't CSE because it can't
guarantee that the subtree walking doesn't modify *tp.
But we already implicitly require that TREE_CODE (*tp) remains the same
throughout the subtree walks, so
