[Bug lto/107779] New: Support implicit references from inline assembler to compiler symbols

["andi-gcc at firstfloor dot org" <gcc-bugzilla@gcc.gnu.org>]

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

            Bug ID: 107779
           Summary: Support implicit references from inline assembler to
                    compiler symbols
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: andi-gcc at firstfloor dot org
                CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org,
                    mliska at suse dot cz
  Target Milestone: ---

Created attachment 53933
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53933&action=edit
prototype patch

So I looked into the problem the kernel people complained about: a
lot of assembler statements reference C symbols, which need externally_visible
and
    global for gcc LTO, otherwise they can end up in the wrong asm file
    and cause missing symbols.

I came up with the attached (hackish) patch that tries to solve the problem
very
partially: it parses the assembler strings and looks for anything that
could be an identifier, and then tries to mark it externally_visible.

It has the following open issues:

    - The parsing is very approximate and doesn't handle some obscure cases.
    With the approximation it's also impossible to give error messages,
    but hopefully the linker takes care of that.
    It also gives false positives with some assembler syntax,
    but in the worst case would just lose some optimization from unnecessary
    references.

    - It doesn't handle the case (which happens in the kernel) that the C
    declaration is after the asm statement. This could be fixed with some
    more effort.

    - It doesn't work for static which can get mangled (that's a lot of
    the kernel cases)
    static is a difficult problem because there could be conflicting names,
    so we cannot jut put it all in partition zero.

    This would need some special handling in the LTO partitioning code to
    create new partitions just for having unique name spaces, and then
    avoid mangling.  Related problem is also PR50676

    It's likely possible to create situations where it's impossible to
    solve, there could be circular dependencies etc. But I assume in this
    case the non LTO case would fail too.

    Or maybe do something with redefining symbols at the assembler level.

    This one is somewhat difficult and I don't have a simple solution
    currently. Unfortunately to solve the kernel issue would need a
    solution for static.