On Sun, 3 Mar 2024, Jeff Law wrote:
>
>
> On 2/9/24 03:26, Richard Biener wrote:
> > The following allows a base term to be derived from an existing
> > MEM_EXPR, notably the points-to set of a MEM_REF base. For the
> > testcase in the PR this helps RTL DSE elide stores to a stack
> > temporary. This covers pointers to NONLOCAL which can be mapped
> > to arg_base_value, helping to disambiguate against other special
> > bases (ADDRESS) as well as PARM_DECL accesses.
> I like it and as you note later, it's extendable.
>
> >
> > Bootstrapped and tested on x86_64-unknown-linux-gnu.
> >
> > This is an attempt to recover some of the losses from dumbing down
> > find_base_{term,value}. I did give my ideas how to properly do
> > this during stage1 a start, I will post a short incomplete RFC series
> > later today.
> I saw those, but set them aside for gcc-15.
>
> >
> > OK for trunk?
> >
> > I've included all languages in testing and also tested with -m32 but
> > details of RTL alias analysis might escape me ...
> >
> > Thanks,
> > Richard.
> >
> > PR rtl-optimization/113597
> > * alias.cc (find_base_term): Add argument for the whole mem
> > and derive a base term from its MEM_EXPR.
> > (true_dependence_1): Pass down the MEMs to find_base_term.
> > (write_dependence_p): Likewise.
> > (may_alias_p): Likewise.
> I'd lean ever so slightly against including this. Not because I see anything
> wrong, more so because we don't have a lot of time for this to shake out if
> there are any problems. But I wouldn't go as far as to say I object to
> including it.
>
> So OK for the trunk if you want to go forward now. Or defer if you want to
> take the somewhat safer route of waiting to gcc-15 to tackle this.
There was fallout (arm bootstrap fail) reported, so I defer it to 15
for which I posted another RFC series. I do admit that I can't promise
to finish anything here. The reported fallout was not too bad
luckily, or maybe just nobody noticed yet.
Richard.
