[llvm-bugs] [Bug 35542] New: [OpenMP] reduction on array section produces incorrect result after r316362

via llvm-bugs llvm-bugs at lists.llvm.org
Wed Dec 6 03:07:33 PST 2017


            Bug ID: 35542
           Summary: [OpenMP] reduction on array section produces incorrect
                    result after r316362
           Product: new-bugs
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: daniil.sizov at intel.com
                CC: llvm-bugs at lists.llvm.org


int printf(const char *, ...);

int main() {
    int total[3] = { 0 };
    int a[10] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };
#pragma omp parallel for reduction(+:total[1:2])
    for (int i = 0; i < 10; i++) {
        total[1 + i % 2] += a[i];

    printf("%d %d %d\n", total[0], total[1], total[2]);



$ clang -v
clang version 6.0.0 (trunk 316361)
Target: x86_64-unknown-linux-gnu
Thread model: posix
$ clang -O0 -fopenmp test.c
$ ./a.out
0 25 30



$ clang -v
clang version 6.0.0 (trunk 316362)
Target: x86_64-unknown-linux-gnu
Thread model: posix
$ clang -O0 -fopenmp test.c
$ ./a.out
0 30 0


r316362 | hahnfeld | 2017-10-23 21:01:35 +0200 (Mon, 23 Oct 2017) | 28 lines

[OpenMP] Avoid VLAs for some reductions on array sections

In some cases the compiler can deduce the length of an array section
as constants. With this information, VLAs can be avoided in place of
a constant sized array or even a scalar value if the length is 1.
int a[4], b[2];
pragma omp parallel reduction(+: a[1:2], b[1:1])
{ }

For chained array sections, this optimization is restricted to cases
where all array sections except the last have a constant length 1.
This trivially guarantees that there are no holes in the memory region
that needs to be privatized.
int c[3][4];
pragma omp parallel reduction(+: c[1:1][1:2])
{ }

This relands commit r316229 that I reverted in r316235 because it
failed on some bots. During investigation I found that this was because
Clang and GCC evaluate the two arguments to emplace_back() in
ReductionCodeGen::emitSharedLValue() in a different order, hence
leading to a different order of generated instructions in the final
LLVM IR. Fix this by passing in the arguments from temporary variables
that are evaluated in a defined order.

Differential Revision: https://reviews.llvm.org/D39136

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/20171206/490ef1a1/attachment.html>

More information about the llvm-bugs mailing list