search

Quuxplusone / LLVMBugzillaTest

0 stars 0 forks source link

error when __attribute__((__always_inline__)) is not inline-able #42487

Open Quuxplusone opened 5 years ago

Quuxplusone commented 5 years ago
Bugzilla Link PR43517
Status CONFIRMED
Importance P enhancement
Reported by Nick Desaulniers (ndesaulniers@google.com)
Reported on 2019-09-30 15:31:20 -0700
Last modified on 2019-10-03 21:13:46 -0700
Version trunk
Hardware PC Linux
CC aaron@aaronballman.com, blitzrakete@gmail.com, dblaikie@gmail.com, dgregor@apple.com, erich.keane@intel.com, erik.pilkington@gmail.com, johannes@jdoerfert.de, jyknight@google.com, lebedev.ri@gmail.com, llvm-bugs@lists.llvm.org, miguel.ojeda.sandonis@gmail.com, notstina@gmail.com, richard-llvm@metafoo.co.uk, srhines@google.com
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also 
https://godbolt.org/z/_V5im1

__attribute__((always_inline))
void foo (void){}

static void (*bar)(void) = foo;

void baz(void) {
    bar();
}

warns in GCC but not Clang
Quuxplusone commented 5 years ago

via jdoerfert: https://godbolt.org/z/7tup8l

Clang does not error when it cannot inline. The Linux kernel is relying on this behavior in certain cases.

https://reviews.llvm.org/D68410 is the start of documentation of this feature.

Quuxplusone commented 5 years ago

Reposting from IRC:

three different cases where GCC and Clang differ:

  1. clang can inline indirect calls, GCC can't, doesn't error/warn, but documents that specifically.

example: https://godbolt.org/z/g5P2QR GCC doc: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html

  1. GCC warns is attribute((always_inline)) is applied to a function not marked inline via -Wattributes, clang does not.

example: https://godbolt.org/z/_V5im1

  1. GCC errors when it fails to inline an always inline an always_inline function (that's not an indirect call, ie. case 1)

example: https://godbolt.org/z/U9ZYuc

I think case 3 is the most important for this bug.

Quuxplusone commented 5 years ago

I'll try to take a look at it over the weekend unless someone else beats me to it.

And I agree regarding the importance, since so many low level things declare architecture-specific inline helper functions with this attribute (especially where, for example, instruction pointer may be of significance in a piece of inline assembly). Fundamentally the core idea is that bad code generation (the attribute itself having "inline-or-die" semantics) as a result of this will be much harder to debug than a compile time error.

As far as I understand it, part of the tests should also ensure always_inline functions never appear in the final, TU-level IR and should never reach the linker or interfere with other TUs (as they are typically declared in some forms of arch-specific headers) and essentially have no linkage type.

For case #2 however, I'm not entirely sure the warning is worth adding since it's somewhat ambiguous and doesn't actually convey anything meaningful.