Richard Biener <richard.guent...@gmail.com> 于2023年10月20日周五 21:33写道：
>
> On Fri, Oct 20, 2023 at 1:48 PM Hanke Zhang via Gcc <gcc@gcc.gnu.org> wrote:
> >
> > Hi, I'm trying to make pass_fre work better for me. But I got a
> > problem. Like the code below:
> >
> > int glob;
> >
> > void __attribute__((oninline))
> > foo() {
> > // do nothing meaningful
> > }
> >
> > int main() {
> > if (glob) {
> > foo();
> > } else {
> > // do something that won't change glob
> > }
> >
> > if (glob) {
> > foo();
> > } else {
> > // do something that won't change glob
> > }
> > }
> >
> > I'm trying to merge the two if blocks. And of course it won't work. I
> > see the code in tree-ssa-structalias.cc, it will do this check:
> >
> > static bool
> > pt_solution_includes_1 (struct pt_solution *pt, const_tree decl) {
> > // xxxx
> > if (pt->nonlocal
> > && is_global_var (decl))
> > return true;
> > // xxxx
> > }
> >
> > So the pt->nonlocal will prevent the merge. I would like to ask if I
> > can make this check less rigid by providing more information about
> > function foo(). Because obviously the foo function does not change the
> > value of glob here, but it is caused by the fact that it is noinline.
> >
> > So if I can prove that foo won't change glob and pass this infomation
> > to this check, my goal was achieved. Is this possible?
>
> In case 'glob' were static IPA reference has this info and we'd already
> use it from call_may_clobber_ref_p. There's IPA mod-ref which is
> a bit more powerful than IPA reference but I think it does not record
> this precise info.
>
> Note that the problem with non-static globals is that we do not know
> whether they get modified indirectly because they might have their
> address take in another TU and that address passed back into the TU.
> Usually using LTO helps here and we can promote the decl to hidden
> visibility.
Hi Richard:
Thanks for your replying.
Yeah, I know that. (We do not know whether they get modified
indirectly because they might have their address take in another TU
and that address passed back into the TU.)
But I think in my case, I think I have to let go of some security
concerns. And LTO is enabled already in my case, but that doesn't
help.
So I can understand that the information includes whether Foo uses
glob directly is actually used, but for security reasons, GCC does not
use it as a basis here (pt_solution_includes_1). Right?
So if I want to change the default behavior of GCC, can I use
call_may_clobber_ref_p to check out and make it merge here?
Thanks
Hanke Zhang
>
> Richard.
>
> >
> > Thanks
> > Hanke Zhang
