[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