On Tue, Jul 2, 2019 at 2:58 PM Thomas Gleixner <t...@linutronix.de> wrote: > On Tue, 2 Jul 2019, Nick Desaulniers wrote: > > TL;DR > > LLVM currently has a bug when unrolling loops containing asm goto and > > we have a fix in hand. > > > > Conservatively, we can block loop unrolling when we see asm goto in a loop: > > Makes sense in order to make progress.
I have the conservative fix posted for review: https://reviews.llvm.org/D64101. I've modified the test case there for what it should look like when we can and do inline it: https://gist.github.com/nickdesaulniers/7216f6e5a17c7064285190440cb88f1d I feel like I'm pretty close to just fixing the block duplication in unrolling outright and can probably have a working fix in the next day or two. > > This causes objtool to not find any issues in > > arch/x86/kernel/cpu/mtrr/generic.o. I don't observe any duplication > > in the __jump_table section of the resulting .o file. It also cuts > > down the objtool warnings I observe in a defconfig (listed at the > > beginning of the email) from 4 to 2. (platform-quirks.o predates asm > > goto, > > It does not have asm goto inside :) I think you're conflating arch/x86/kernel/cpu/mtrr/generic.o with arch/x86/kernel/platform-quirks.o. > platform-quirks.o: > > if (x86_platform.set_legacy_features) > 74: 4c 8b 1d 00 00 00 00 mov 0x0(%rip),%r11 # 7b > <x86_early_init_platform_quirks+0x7b> > 7b: 4d 85 db test %r11,%r11 > 7e: 0f 85 00 00 00 00 jne 84 > <x86_early_init_platform_quirks+0x84> > x86_platform.set_legacy_features(); > } > 84: c3 retq > > That jne jumps to __x86_indirect_thunk_r11, aka. ratpoutine. As an American with 100% French Canadian ancestry, I approve of the term ratpoutine over retpoline. > No idea why objtool thinks that the instruction at 0x84 is not > reachable. Josh? -- Thanks, ~Nick Desaulniers