[llvm-bugs] [Bug 50659] New: Difference in alloca naming/ordering between legacy and new pass manager

via llvm-bugs llvm-bugs at lists.llvm.org
Thu Jun 10 08:21:28 PDT 2021


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

            Bug ID: 50659
           Summary: Difference in alloca naming/ordering between legacy
                    and new pass manager
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: david.spickett at linaro.org
                CC: llvm-bugs at lists.llvm.org, neeilans at live.com,
                    richard-llvm at metafoo.co.uk

Created attachment 24937
  --> https://bugs.llvm.org/attachment.cgi?id=24937&action=edit
test file

This is following up on https://reviews.llvm.org/rGd69c4372bfbe.

I had a local build that had cmake ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=OFF and 
arm-bf16-convert-intrinsics.c failed for me once the test output was updated.

Disabling the legacy pass manager with -fno-legacy-pass-manager was suggested
and that fixed the issue.

Looking more closely, only one of the run lines in that file was failing:
// RUN: %clang_cc1 \
// RUN:   -triple armv8.6a-arm-none-eabi -target-feature +neon \
// RUN:   -target-feature +bf16 -mfloat-abi hard \
// RUN:   -disable-O0-optnone -emit-llvm -fno-legacy-pass-manager -o - %s \
// RUN:   | opt -S -mem2reg \
// RUN:   | FileCheck --check-prefixes=CHECK,CHECK-A32-HARDFP %s

By taking just that run and reducing the input down to just:
#include <arm_neon.h>

float32x4_t test_vcvtq_low_f32_bf16(bfloat16x8_t a) {
  return vcvtq_low_f32_bf16(a);
}

I saw that the order of the intial alloca, and the names assigned to them was
different. (the name change probably effects the output order somehow)

E.g.
Legacy PM: %__p0_150.i.i = alloca <4 x bfloat>, align 8
   New PM: %__p0_150.i = alloca <4 x bfloat>, align 8

With the two on different lines.

You can reproduce with the attached C file and the following command:
$ ./bin/clang -cc1 -internal-isystem ./lib/clang/13.0.0/include -nostdsysteminc
-triple armv8.6a-arm-none-eabi -target-feature +neon -target-feature +bf16
-mfloat-abi softfp -disable-O0-optnone -emit-llvm -o - -fno-legacy-pass-manager
/tmp/test_pm.c | ./bin/opt -S -mem2reg

Is this expected or indicative or something that should be the same across
both?

-- 
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/20210610/4df38efb/attachment.html>


More information about the llvm-bugs mailing list