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

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

[andi-gcc at firstfloor dot 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.

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
           Keywords|                            |inline-asm

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
There are better ways of solving this. One way is to have top level inline-asm
accept input operands and use that.

Plus if I read this code, it only works with x86 inlineasm but it is generic
part of the compiler, a huge issue. Amd no documentation either. Inline-asm is
already not well documented and now adding even more is not helping.

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=41045

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #1)
> There are better ways of solving this. One way is to have top level
> inline-asm accept input operands and use that.
See PR 41045 for that option.

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

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
I think we'd need a target hook for the attempt to handle legacy code patterns
and we should rewrite the asm text in a way properly using (added) input
constraints to support symbol renaming.  I would also suggest to diagnose any
such "fixups" by default.

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

[andi-gcc at firstfloor dot org]

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

--- Comment #4 from Andi Kleen <andi-gcc at firstfloor dot org> ---
This whole manual annotation idea (which is equivalent to marking the symbols
global and visible and that is what a large part of the kernel LTO patchkit) is
dead on arrival because the kernel people already rejected it. Their argument
is that they don't need it for LLVM why should they be forced to it for GCC. In
LLVM it is just done by the assembler, and it works without any extra program
changes.

Since gcc is not the only game in town anymore they have a point.

It's either heuristics or integrating the assembler.