[llvm-bugs] [Bug 45101] New: Wrong optimization: conditional equivalence vs. values with several representations

via llvm-bugs llvm-bugs at lists.llvm.org
Wed Mar 4 09:50:49 PST 2020


https://bugs.llvm.org/show_bug.cgi?id=45101

            Bug ID: 45101
           Summary: Wrong optimization: conditional equivalence vs. values
                    with several representations
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: ch3root at openwall.com
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org

The problem happens when:
- conditional equivalence propagation replaces an expression with a variable or
a constant that has the same value but a different representation, and
- this happens in a computation where representation is accessed.

Example with a pseudo-denormal in long double:

----------------------------------------------------------------------
#include <stdio.h>

__attribute__((noipa,optnone)) // imagine it in a separate TU
static void *opaque(void *p) { return p; }

int main()
{
    long double x, y;

    unsigned char *px = (unsigned char *)&x;
    unsigned char *py = (unsigned char *)&y;

    // make x pseudo-denormal
    x = 0;
    px[7] = 0x80;
    opaque(&x); // hide it from the optimizer

    y = x;

    if (y == 0x1p-16382l)
        printf("py[8] = %d\n", py[8]);
    printf("py[8] = %d\n", py[8]);
}
----------------------------------------------------------------------
$ clang -std=c11 -Weverything -Wno-unknown-attributes -O3 test.c && ./a.out
py[8] = 1
py[8] = 0
----------------------------------------------------------------------
clang x86-64 version: clang version 11.0.0
(https://github.com/llvm/llvm-project 9284abd0040afecfd619dbcf1b244a8b533291c9)
----------------------------------------------------------------------

The value 0x1p-16382l admits two representations:

00 00 80 00 00 00 00 00 00 00  pseudo-denormal
00 01 80 00 00 00 00 00 00 00  normalized value

So both 0 and 1 for py[8] are fine but the testcase should print the same value
both times, i.e. the representation of y should be stable.

DR 260 Q1 allows for unstable representation but IMO this is wrong.

gcc bug -- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94035

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200304/2c197e48/attachment-0001.html>


More information about the llvm-bugs mailing list