On Tue, 17 Mar 2026, Jakub Jelinek wrote:

> On Tue, Mar 17, 2026 at 12:54:43PM +0100, Richard Biener wrote:
> > This decouples the PRE reference IL from the VN hash tables, following
> > the corresponding PR103037 fix for nary expressions in r12-7389 to avoid
> > correctness issues regarding to access paths when inserting expressions.
> > 
> > Unfortunately this makes existing workarounds for alignment and alias
> > mismatches ineffective so those have to be re-implemented.  Instead
> > of going back to implement canonexpr() during the ANTIC dataflow the
> > following does this at insertion time, hoping all relevant reaching
> > expressions will survive.  A convenient place to do this is
> > sorted_array_from_bitmap_set, the actual magic worker is 'prefer',
> > for the moment handling alignment and innermost access size only,
> > as those are the cases we have test coverage.  In particular the
> > access path difference seen in this PR is not covered - it is enough
> > to fix the AVAIL_OUT computation in compute_avail for this.
> > 
> > Where the old fixup code massaged the expressions the new code selects
> > from existing expressions or as fallback makes sure to not perform
> > code insertion when two incompatible expressions met.
> 
> Thanks for working on this.
> 
> > Bootstrapped and tested on x86_64-unknown-linux-gnu.  I've built a
> > set of applications looking for ICEs successfully, still I consider
> > this moderately risky at this point (but I'd also like to see
> > coverage rather than trying to hack the missing alias-set handling
> > in place without such coverage).  I'll try to come up with a GIMPLE FE
> > testcase for this but it's also that the later we're putting this in
> > the worse (IMO), defering to stage1 and backporting will also not
> > really result in better coverage.
> > 
> > So what's your opinion?
> > 
> > OK for trunk?
> 
> I'd put it on the trunk, we still have at least a month to find issues in it
> and it will be widely deployed till then to get real-world coverage.

OK, I'll be prepared to eventually revert though when there is larger
fallout that cannot be quickly addressed.

Thanks,
Richard.

Reply via email to