[LLVMdev] Incorrect loop optimization when building the Linux kernel
david.majnemer at gmail.com
Mon Dec 8 02:03:28 PST 2014
(gdb) p &a
$1 = (char (*)) 0x60103c
(gdb) p &b
$2 = (char (*)) 0x60103c
Even if this is not safe at the C or C++ level, this comparison could
return equal or not equal depending on what the linker chooses to do.
Do we have a bug in the constant folder?
On Sun, Dec 7, 2014 at 11:16 PM, Nick Lewycky <nicholas at mxc.ca> wrote:
> Chengyu Song wrote:
>> It's difficult to say without a full example, but I'm very suspicious
>>> of those global declarations. I think the compiler would be entirely
>>> justified in assuming you could *never* get from __start_builtin_fw to
>>> __end_builtin_fw, let alone on the first iteration: they're distinct
>>> array objects and by definition (within C99) can't overlap.
>> I think this should be the root cause. Once I changed the declaration to
>> pointers (instead of arrays):
>> extern struct builtin_fw* __start_builtin_fw;
>> extern struct builtin_fw* __end_builtin_fw;
>> The generated code will not skip the first comparison.
>> Sadly, Linux kernel may contain more such declarations.
> That's a great point. Maybe clang could issue a warning on these, any for
> loop that declares a pointer to the address of a non-weak object, compares
> it to a different object, and increments only the pointer (without doing
> other changes to the pointer inside the loop body). We know that's a buggy
> pattern. Could you file a feature request for this on llvm.org/bugs ?
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev