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.