[Bug tree-optimization/95786] New: Too aggressive target indirection elimination

[Bug tree-optimization/95786] New: Too aggressive target indirection elimination

[yyc1992 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95786

            Bug ID: 95786
           Summary: Too aggressive target indirection elimination
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: yyc1992 at gmail dot com
  Target Milestone: ---

I realize this issue when debugging PR95778 and PR95780 (ref
https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548631.html)

It seems that the indirection elimination logic does not take into account the
linkage and visibility of the callee and will eliminate the indirection even in
cases where a function without target attribute would have use a PLT and, for
example, allows a override from a different library.

The following code generates a direct call beween g2 and f2 without going
through PLT.

```
__attribute__((target_clones("default,avx2"))) int f2(int *p)
{
    asm volatile ("" :: "r"(p) : "memory");
    return *p;
}

__attribute__((target_clones("default,avx2"))) int g2(int *p)
{
    return f2(p);
}
```

but removing the target_clones attribute uses the PLT.

[Bug ipa/95786] Too aggressive target indirection elimination

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95786

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
          Component|tree-optimization           |ipa
                 CC|                            |marxin at gcc dot gnu.org

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
I guess bypassing the dispatcher is also not OK here.  Maybe the initial
cgraph looks semantically wrong already.