[PATCH] avoid false positives due to compute_objsize (PR 95353)

Jakub Jelinek jakub@redhat.com
Wed Jun 17 22:39:41 GMT 2020


On Wed, Jun 17, 2020 at 04:37:54PM -0600, Jeff Law wrote:
> On Wed, 2020-06-17 at 10:04 +0200, Jakub Jelinek via Gcc-patches wrote:
> > On Wed, Jun 17, 2020 at 09:13:25AM +0200, Richard Biener via Gcc-patches wrote:
> > > > Not doing the transformation I suggest at all, or not doing it in
> > > > cases when the member does match the source?
> > > 
> > > We are currently not treating different fields at the same offset as
> > > "equal" before inlining completed for objsize to "work", thus leaving
> > > optimizations on the plate.
> > 
> > As the first objsz pass runs quite early (the second one in
> > pass_all_early_optimizations), we could just add a property for that
> > and use it instead of the cfun->after_inlining check.
> > And after that pass, we should be remembering the field limits in the IL
> > explicitly as a MIN/MAX_EXPR for the bos call.
> Right.  And that's part of the reason why I was suggesting we attach original
> type information to the calls (and perhaps other *_REF nodes) as early in the
> pipeline as possible -- the earlier in the pipeline we are, the closer the IL is
> to the source and the more likely that type information will be correct.
> 
> I'm not wed to that idea, but I do think we need to start moving away from
> walking the use-def chains to find an address computation which may have a type
> with little/no relation to the object we're modifying.  I think it's become clear
> that's ultimately a losing battle.

Complete agreement.

	Jakub



More information about the Gcc-patches mailing list