On Tue, Nov 23, 2021 at 09:06:49PM +0530, Siddhesh Poyarekar wrote:
> On 11/23/21 20:42, Jakub Jelinek wrote:
> > On Wed, Nov 10, 2021 at 12:31:32AM +0530, Siddhesh Poyarekar wrote:
> > > (object_sizes_execute): Don't insert min/max for dynamic sizes.
> >
> > I'm worried about this.
> > I'd say what we might want to do is in the early pass for __bdos
> > compute actually __bos (i.e. the static one) and add MIN_EXPR/MAX_EXPR
> > for the result of the __bdos call from the second pass with the
> > statically computed value.
> >
> > The reason for the MIN_EXPR/MAX_EXPR stuff is that GIMPLE optimizations
> > can remove exact ADDR_EXPRs with detailed COMPONENT_REF etc. access paths
> > in it, so during the late objsz2 pass the subobject modes don't work
> > reliably anymore. But the subobject knowledge should be the same between
> > the static and dynamic evaluation...
>
> So in the dynamic case we almost always end up with the right expression in
> objsz1, except in cases where late optimizations make available information
> that wasn't available earlier. How about putting in a MIN_EXPR/MAX_EXPR if
> we *fail* to get the subobject size instead?
I don't think that is the case, perhaps for trivial testcases yes when early
inlining inlines the fortification always_inline functions and everything
appears in a single function.
The primary reason for objsz2 being done later is that it is after inlining,
IPA optimizations and some optimization passes that clean up after those.
But at the same time it is after too many optimizations that could have
broken the exact subobject details.
But very often in objsz1 you'll just see const char *p argument and only
inlining will reveal how that was allocated etc.
Evaluating __bdos in both passes is undesirable, certainly for the same
SSA_NAME, but even for different SSA_NAMEs, if everything is done in a
single pass it can easily share temporaries (object sizes for SSA_NAMEs it
uses), while if some __bdos is evaluated early and other late, we'll need to
hope further optimizations CSE those.
Jakub
