[llvm-bugs] [Bug 120034] [NEON] Load Multiple Increment After Skipped in Inlined Code
Issue
120034
Summary
[NEON] Load Multiple Increment After Skipped in Inlined Code
Labels
new issue
Assignees
Reporter
ytw16
The function add_arrays() is directly compiled using the Load Multiple Increment After instructions (e.g., vldmia and vstmia). However, when add_arrays() is inlined into the parent function during compilation, the corresponding loop in the parent function does not utilize Load Multiple Increment After instructions. Instead, it generates individual adds and vldr/vstr instructions, resulting in less efficient code.
Example:
```
#define SIZE 100
double c[SIZE];
void add_arrays(double *a, double *b, double *c, int size) {
for (int i = 0; i < size; i++) {
c[i] = a[i] + b[i];
}
}
int main() {
double a[SIZE];
double b[SIZE];
for (int i = 0; i < SIZE; i++) {
a[i] = i * 1.0;
b[i] = i * 2.0;
}
add_arrays(a, b, c, SIZE);
return 0;
}
```
The disassemble codes:
```
:
0: 2b01cmp r3, #1
2: bfb8 it lt
4: 4770bxltlr
6: ecf1 0b02 vldmia r1!, {d16}
a: 3b01subsr3, #1
c: ecf0 1b02 vldmia r0!, {d17}
10: ee71 0ba0 vadd.f64d16, d17, d16
14: ece2 0b02 vstmia r2!, {d16}
18: d1f5 bne.n 6
1a: 4770bx lr
001c :
1c: b5b0push{r4, r5, r7, lr}
1e: af02 add r7, sp, #8
20: f5ad 0d74 sub.w sp, sp, #15990784 @ 0xf4
24: f5ad 5d10 sub.w sp, sp, #9216 @ 0x2400
28: efc0 1010 vmov.i32d17, #0 @ 0x
2c: f241 2e00 movwlr, #4608 @ 0x1200
30: f50d 5090 add.w r0, sp, #4608 @ 0x1200
34: 2300movsr3, #0
36: f2c0 0e7a movtlr, #122@ 0x7a
3a: f500 01f4 add.w r1, r0, #7995392@ 0x7a
3e: 466amov r2, sp
40: eef7 0b00 vmov.f64d16, #112 @ 0x3f80 1.0
44: ee71 3ba0 vadd.f64d19, d17, d16
48: 18c8 addsr0, r1, r3
4a: ee71 2ba1 vadd.f64d18, d17, d17
4e: edc0 1b00 vstrd17, [r0]
52: 18d0addsr0, r2, r3
54: 3308addsr3, #8
56: 459ecmp lr, r3
58: eef0 1b63 vmov.f64d17, d19
5c: edc0 2b00 vstrd18, [r0]
60: d1f0bne.n 44
62: f240 0c00 movwip, #0
66: 2300movsr3, #0
68: f2c0 0c00 movtip, #0
6c: 18d0adds r0, r2, r3
6e: edd0 0b00 vldrd16, [r0]
72: 18c8 addsr0, r1, r3
74: edd0 1b00 vldrd17, [r0]
78: eb0c 0003 add.w r0, ip, r3
7c: 3308addsr3, #8
7e: ee71 0ba0 vadd.f64d16, d17, d16
82: 459ecmp lr, r3
84: edc0 0b00 vstrd16, [r0]
88: d1f0 bne.n 6c
8a: 2000movsr0, #0
8c: f50d 0d74 add.w sp, sp, #15990784 @ 0xf4
90: f50d 5d10 add.w sp, sp, #9216 @ 0x2400
94: bdb0pop {r4, r5, r7, pc}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120048] Request Triage Access For Emilyaxe
Issue 120048 Summary Request Triage Access For Emilyaxe Labels new issue Assignees Reporter Emilyaxe I am currently investigating bugs in MLIR and plan to report more issues. I would like to request triage access, which will enable me to add better label(s) and set type of issues. Here are the issues that I have reported. [Issues](https://github.com/llvm/llvm-project/issues?q=is%3Aissue%20state%3Aopen%20author%3AEmilyaxe) ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120003] LLVM build is completely broken is LLVM_USE_SANITIZER is set to "Undefined" and g++ is the host compiler
Issue 120003 Summary LLVM build is completely broken is LLVM_USE_SANITIZER is set to "Undefined" and g++ is the host compiler Labels build-problem Assignees Reporter chestnykh The documentation says nothing about restrictions of LLVM_USE_SANITIZER variables (e.g the host compiler has to be clang) "**LLVM_USE_SANITIZER**:STRING Define the sanitizer used to build LLVM binaries and tests. Possible values are ``Address``, ``Memory``, ``MemoryWithOrigins``, ``Undefined``, ``Thread``, ``DataFlow``, and ``Address;Undefined``. Defaults to empty string." I attach the file with all errors that i got during configure and compilation stages [llvm_errs_sanitizer_undefined_gcc.log](https://github.com/user-attachments/files/18140824/llvm_errs_sanitizer_undefined_gcc.log) cmake command i use: ``` cmake -G "Unix Makefiles" \ -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_INSTALL_PREFIX=/usr \ -DLLVM_BINUTILS_INCDIR=/usr/include \ -DLLVM_HOST_TRIPLE="x86_64-unknown-linux-gnu" \ -DLLVM_USE_SANITIZER="Undefined" \ -DLLVM_BUILD_LLVM_DYLIB=ON \ -DLLVM_LINK_LLVM_DYLIB=ON \ -DLLVM_INSTALL_UTILS=ON \ -DLLVM_ENABLE_RTTI=ON \ -DLLVM_ENABLE_FFI=ON \ -DLLVM_ENABLE_PROJECTS="clang;compiler-rt;lld;bolt" \ -DCLANG_LINK_CLANG_DYLIB=ON \ -DLLDB_USE_SYSTEM_SIX=1 \ -DLIBOMP_INSTALL_ALIASES=OFF \ -DLLVM_TARGETS_TO_BUILD="X86;ARM" \ -DLLVM_ENABLE_RUNTIMES="libcxx;libcxxabi;libunwind" \ -DPOLLY_ENABLE_GPGPU_CODEGEN=ON \ ../llvm ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120009] [c++] Crash at type deductions of static member.
Issue
120009
Summary
[c++] Crash at type deductions of static member.
Labels
new issue
Assignees
Reporter
cassioneri
## Code
```
template
struct a {
static const int b = 0;
static constexpr decltype(&b) c = &b;
};
auto x = a::c;
```
## Stack dump
```
0. Program arguments: clang++ -emit-llvm -Xclang -disable-llvm-passes -c main.cpp
1. parser at end of file
2. main.cpp:7:6: LLVM IR generation of declaration 'x'
3. main.cpp:7:6: Generating code for declaration 'x'
#0 0x7941e87fcd90 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /usr/src/debug/llvm/llvm-18.1.8.src/lib/Support/Unix/Signals.inc:723:22
#1 0x7941e87fa26d llvm::sys::RunSignalHandlers() /usr/src/debug/llvm/llvm-18.1.8.src/lib/Support/Signals.cpp:105:20
#2 0x7941e87fa26d llvm::sys::CleanupOnSignal(unsigned long) /usr/src/debug/llvm/llvm-18.1.8.src/lib/Support/Unix/Signals.inc:367:31
#3 0x7941e86e08e9 HandleCrash /usr/src/debug/llvm/llvm-18.1.8.src/lib/Support/CrashRecoveryContext.cpp:73:5
#4 0x7941e86e08e9 CrashRecoverySignalHandler /usr/src/debug/llvm/llvm-18.1.8.src/lib/Support/CrashRecoveryContext.cpp:390:62
#5 0x7941e7bfe1d0 (/usr/lib/libc.so.6+0x3d1d0)
#6 0x7941e8a2eae6 llvm::Type::isIntegerTy(unsigned int) const /usr/src/debug/llvm/llvm-18.1.8.src/lib/IR/Type.cpp:57:24
#7 0x7941f28868c6 clang::CodeGen::CodeGenTypes::ConvertTypeForMem(clang::QualType, bool) (.constprop.0) /usr/src/debug/clang/clang-18.1.8.src/lib/CodeGen/CodeGenTypes.cpp:113:0
#8 0x7941f1829ebe tryEmit /usr/src/debug/clang/clang-18.1.8.src/lib/CodeGen/CGExprConstant.cpp:1880:49
#9 0x7941f1829ebe clang::CodeGen::ConstantEmitter::tryEmitPrivate(clang::APValue const&, clang::QualType) /usr/src/debug/clang/clang-18.1.8.src/lib/CodeGen/CGExprConstant.cpp:2094:65
#10 0x7941f182aeb1 clang::CodeGen::ConstantEmitter::tryEmitPrivateForMemory(clang::APValue const&, clang::QualType) /usr/src/debug/clang/clang-18.1.8.src/lib/CodeGen/CGExprConstant.cpp:1731:26
#11 0x7941f182b225 clang::CodeGen::ConstantEmitter::markIfFailed(llvm::Constant*) /usr/src/debug/clang/clang-18.1.8.src/lib/CodeGen/ConstantEmitter.h:165:5
#12 0x7941f182b225 clang::CodeGen::ConstantEmitter::tryEmitForInitializer(clang::VarDecl const&) /usr/src/debug/clang/clang-18.1.8.src/lib/CodeGen/CGExprConstant.cpp:1472:22
#13 0x7941f1a0de16 clang::CodeGen::CodeGenModule::EmitGlobalVarDefinition(clang::VarDecl const*, bool) /usr/src/debug/clang/clang-18.1.8.src/lib/CodeGen/CodeGenModule.cpp:5334:5
#14 0x7941f1a223e5 clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl, llvm::GlobalValue*) /usr/src/debug/clang/clang-18.1.8.src/lib/CodeGen/CodeGenModule.cpp:4101:60
#15 0x7941f1a22dc3 clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl) /usr/src/debug/clang/clang-18.1.8.src/lib/CodeGen/CodeGenModule.cpp:3824:27
#16 0x7941f1a2b6ad clang::Decl::getKind() const /usr/src/debug/clang/clang-18.1.8.src/include/clang/AST/DeclBase.h:447:0
#17 0x7941f1a2b6ad clang::DecompositionDecl::classof(clang::Decl const*) /usr/src/debug/clang/clang-18.1.8.src/include/clang/AST/DeclCXX.h:4197:0
#18 0x7941f1a2b6ad llvm::isa_impl::doit(clang::Decl const&) /usr/include/llvm/Support/Casting.h:64:0
#19 0x7941f1a2b6ad llvm::isa_impl_cl::doit(clang::Decl const*) /usr/include/llvm/Support/Casting.h:110:0
#20 0x7941f1a2b6ad llvm::isa_impl_wrap::doit(clang::Decl const* const&) /usr/include/llvm/Support/Casting.h:137:0
#21 0x7941f1a2b6ad llvm::isa_impl_wrap::doit(clang::Decl* const&) /usr/include/llvm/Support/Casting.h:129:0
#22 0x7941f1a2b6ad llvm::CastIsPossible::isPossible(clang::Decl* const&) /usr/include/llvm/Support/Casting.h:257:0
#23 0x7941f1a2b6ad llvm::CastInfo::doCastIfPossible(clang::Decl* const&) /usr/include/llvm/Support/Casting.h:493:0
#24 0x7941f1a2b6ad decltype(auto) llvm::dyn_cast(clang::Decl*) /usr/include/llvm/Support/Casting.h:663:0
#25 0x7941f1a2b6ad clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) /usr/src/debug/clang/clang-18.1.8.src/lib/CodeGen/CodeGenModule.cpp:6753:0
#26 0x7941f1a88853 HandleTopLevelDecl /usr/src/debug/clang/clang-18.1.8.src/lib/CodeGen/ModuleBuilder.cpp:189:0
#27 0x7941f19a1597 clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) /usr/src/debug/clang/clang-18.1.8.src/lib/CodeGen/CodeGenAction.cpp:208:3
#28 0x7941f067c022 clang::ParseAST(clang::Sema&, bool, bool) /usr/src/debug/clang/clang-18.1.8.src/lib/Parse/ParseAST.cpp:167:17
#29 0x7941f2147451 clang::FrontendAction::Execute() /usr/src/debug/clang/clang-18.1.8.src/lib/Frontend/FrontendAction.cpp:1069:21
#30 0x7941f20e8097 llvm::Error::getPtr() const /usr/include/llvm/Support/Error.h:279:0
#31 0x7941f20e8097 llvm::Error::operator bool() /u
[llvm-bugs] [Bug 120001] [Mlir][affine] --lower-affine crashes in AffineOps.cpp:foldLoopBounds
Issue
120001
Summary
[Mlir][affine] --lower-affine crashes in AffineOps.cpp:foldLoopBounds
Labels
mlir
Assignees
Reporter
Emilyaxe
git version: ff939b06a5
system: `Ubuntu 18.04.6 LTS`
reproduce with: `/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt a.mlir --lower-affine`
a.mlir:
```
#map = affine_map<() -> ()>
module {
llvm.mlir.global private constant @__constant_1x10x7xi32_1(dense<7267> : tensor<1x10x7xi32>) {addr_space = 0 : i32, alignment = 64 : i64} : !llvm.array<1 x array<10 x array<7 x i32>>>
func.func @main() {
%0 = llvm.mlir.addressof @__constant_1x10x7xi32_1 : !llvm.ptr
%1 = llvm.mlir.constant(0 : index) : i64
%2 = llvm.mlir.undef : !llvm.struct<(ptr, ptr, i64, array<3 x i64>, array<3 x i64>)>
%3 = llvm.mlir.constant(3735928559 : index) : i64
%4 = llvm.mlir.constant(1 : index) : i64
%5 = llvm.mlir.constant(10 : index) : i64
%6 = llvm.mlir.constant(7 : index) : i64
%7 = llvm.mlir.constant(70 : index) : i64
%8 = llvm.getelementptr %0[0, 0, 0, 0] : (!llvm.ptr) -> !llvm.ptr, !llvm.array<1 x array<10 x array<7 x i32>>>
%9 = llvm.inttoptr %3 : i64 to !llvm.ptr
%10 = llvm.insertvalue %9, %2[0] : !llvm.struct<(ptr, ptr, i64, array<3 x i64>, array<3 x i64>)>
%11 = llvm.insertvalue %8, %10[1] : !llvm.struct<(ptr, ptr, i64, array<3 x i64>, array<3 x i64>)>
%12 = llvm.insertvalue %1, %11[2] : !llvm.struct<(ptr, ptr, i64, array<3 x i64>, array<3 x i64>)>
%13 = llvm.insertvalue %4, %12[3, 0] : !llvm.struct<(ptr, ptr, i64, array<3 x i64>, array<3 x i64>)>
%14 = llvm.insertvalue %5, %13[3, 1] : !llvm.struct<(ptr, ptr, i64, array<3 x i64>, array<3 x i64>)>
%15 = llvm.insertvalue %6, %14[3, 2] : !llvm.struct<(ptr, ptr, i64, array<3 x i64>, array<3 x i64>)>
%16 = llvm.insertvalue %7, %15[4, 0] : !llvm.struct<(ptr, ptr, i64, array<3 x i64>, array<3 x i64>)>
%17 = llvm.insertvalue %6, %16[4, 1] : !llvm.struct<(ptr, ptr, i64, array<3 x i64>, array<3 x i64>)>
%18 = llvm.insertvalue %4, %17[4, 2] : !llvm.struct<(ptr, ptr, i64, array<3 x i64>, array<3 x i64>)>
%19 = builtin.unrealized_conversion_cast %18 : !llvm.struct<(ptr, ptr, i64, array<3 x i64>, array<3 x i64>)> to memref<1x10x7xi32>
%alloc = memref.alloc() : memref<1x10x7xi32>
affine.for %arg0 = max #map() to min #map() {
affine.for %arg1 = 0 to 7 {
%20 = affine.load %19[0, %arg0, %arg1] : memref<1x10x7xi32>
affine.store %20, %alloc[0, %arg0, %arg1] : memref<1x10x7xi32>
}
}
return
}
}
```
stack trace:
```
mlir-opt: /data/szy/MLIR/llvm-release/llvm-project/mlir/lib/Dialect/Affine/IR/AffineOps.cpp:2201: auto foldLoopBounds(AffineForOp)::(anonymous class)::operator()(bool) const: Assertion `boundMap.getNumResults() >= 1 && "bound maps should have at least one result"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: /data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt a.mlir --lower-affine
#0 0x55dc725e3348 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x111f348)
#1 0x55dc725e0e5e llvm::sys::RunSignalHandlers() (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x111ce5e)
#2 0x55dc725e3cdd SignalHandler(int) Signals.cpp:0:0
#3 0x7f02fb714420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
#4 0x7f02fad5100b raise /build/glibc-LcI20x/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
#5 0x7f02fad30859 abort /build/glibc-LcI20x/glibc-2.31/stdlib/abort.c:81:7
#6 0x7f02fad30729 get_sysdep_segment_value /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:509:8
#7 0x7f02fad30729 _nl_load_domain /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:970:34
#8 0x7f02fad41fd6 (/lib/x86_64-linux-gnu/libc.so.6+0x33fd6)
#9 0x55dc726afb93 foldLoopBounds(mlir::affine::AffineForOp)::$_0::operator()(bool) const AffineOps.cpp:0:0
#10 0x55dc72683251 mlir::affine::AffineForOp::fold(mlir::affine::AffineForOpGenericAdaptor>, llvm::SmallVectorImpl&) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x11bf251)
#11 0x55dc726bfca2 llvm::LogicalResult mlir::Op::Impl, mlir::OpTrait::OpInvariants, mlir::BytecodeOpInterface::Trait, mlir::OpTrait::AutomaticAllocationScope, mlir::ConditionallySpeculatable::Trait, mlir::OpTrait::HasRecursiveMemoryEffects, mlir::LoopLikeOpInterface::Trait, mlir::RegionBranchOpInterface::Trait>::foldHook(mlir::Operation*, llvm::ArrayRef, llvm::SmallVectorImpl&) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x11fbca2)
#12 0x55dc726bd810 mlir::RegisteredOperationName::Model::foldHook(mlir::Operation*, llvm::ArrayRef, llvm::SmallV
[llvm-bugs] [Bug 120000] [Bolt] question: error on recursive function with suffix .localalias/1
Issue 12 Summary [Bolt] question: error on recursive function with suffix .localalias/1 Labels BOLT Assignees Reporter miz2019 I have a program got LTO+PGO, when instrumented by BOLT, the code is genereated , but the program can not run correctly and no data is generated. Given the normal mangled name A, the function will getname as A.localalias/1, the name is get from BinaryFunction::getOneName(). 1: the function has suffix .localalias 2: the function will call itself, i.e. recursively. Does anyone know why localalias is generated? and any clue on solving this error . The program under test is very huge and complicated. Thanks. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120029] [X86][CodeGen][GlobalISel] Crash: Unable to copy EFLAGS physical register!
Issue
120029
Summary
[X86][CodeGen][GlobalISel] Crash: Unable to copy EFLAGS physical register!
Labels
new issue
Assignees
Reporter
nmosier
`llc`'s X86 backend crashes (branch release/19.x) when Global ISel is enabled for the following LLVM IR (reduced using bugpoint):
```
define dso_local void @bitmap_clear_range(i32 %0) local_unnamed_addr #0 {
br label %.critedge
.critedge: ; preds = %21, %1
%2 = getelementptr inbounds i8, ptr null, i64 16
%3 = load i32, ptr %2, align 8
%4 = shl nuw i32 %3, 7
%5 = add i32 %4, 128
%6 = icmp ult i32 %4, %0
%7 = icmp ugt i32 %5, 0
%8 = or i1 %6, %7
br i1 %8, label %9, label %21
9: ; preds = %.critedge
%10 = icmp ugt i32 %4, %0
%11 = sub i32 %0, %4
%12 = lshr i32 %11, 6
%13 = select i1 %10, i32 0, i32 %12
%14 = select i1 %7, i32 0, i32 1
%15 = icmp eq i32 %13, %14
br i1 %15, label %17, label %16
16: ; preds = %9
store i64 poison, ptr null, align 8
br label %17
17: ; preds = %16, %9
%18 = phi i32 [ %14, %16 ], [ %13, %9 ]
%19 = zext nneg i32 %18 to i64
%20 = getelementptr inbounds [2 x i64], ptr null, i64 0, i64 %19
store i64 0, ptr %20, align 8
br label %21
21: ; preds = %17, %.critedge
%22 = icmp eq ptr null, null
br i1 %22, label %23, label %.critedge
23: ; preds = %21
ret void
}
```
Save the above file to `bug.ll`, then reproduce with the following command on an x86 host:
`llc --global-isel bug.ll`
This crashes with the following backtrace:
```
LLVM ERROR: Unable to copy EFLAGS physical register!
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: ./bin/llc --global-isel bug.ll
1. Running pass 'Function Pass Manager' on module 'bug.ll'.
2. Running pass 'Post-RA pseudo instruction expansion pass' on function '@bitmap_clear_range'
#0 0x55fb6b3bb510 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (./bin/llc+0x360b510)
#1 0x55fb6b3b8aee SignalHandler(int) Signals.cpp:0:0
#2 0x7f3df3d6e520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#3 0x7f3df3dc29fc __pthread_kill_implementation ./nptl/pthread_kill.c:44:76
#4 0x7f3df3dc29fc __pthread_kill_internal ./nptl/pthread_kill.c:78:10
#5 0x7f3df3dc29fc pthread_kill ./nptl/pthread_kill.c:89:10
#6 0x7f3df3d6e476 gsignal ./signal/../sysdeps/posix/raise.c:27:6
#7 0x7f3df3d547f3 abort ./stdlib/abort.c:81:7
#8 0x55fb683c6f59 llvm::DisplayGraph(llvm::StringRef, bool, llvm::GraphProgram::Name) (.cold) GraphWriter.cpp:0:0
#9 0x55fb6b30d0ae (./bin/llc+0x355d0ae)
#10 0x55fb69b65759 llvm::X86InstrInfo::copyPhysReg(llvm::MachineBasicBlock&, llvm::MachineInstrBundleIterator, llvm::DebugLoc const&, llvm::MCRegister, llvm::MCRegister, bool) const (./bin/llc+0x1db5759)
#11 0x55fb6a70294d llvm::TargetInstrInfo::lowerCopy(llvm::MachineInstr*, llvm::TargetRegisterInfo const*) const (./bin/llc+0x295294d)
#12 0x55fb6a3234b8 (anonymous namespace)::ExpandPostRA::runOnMachineFunction(llvm::MachineFunction&) ExpandPostRAPseudos.cpp:0:0
#13 0x55fb6a46660f llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (.part.0) MachineFunctionPass.cpp:0:0
#14 0x55fb6a9be29a llvm::FPPassManager::runOnFunction(llvm::Function&) (./bin/llc+0x2c0e29a)
#15 0x55fb6a9be424 llvm::FPPassManager::runOnModule(llvm::Module&) (./bin/llc+0x2c0e424)
#16 0x55fb6a9bee51 llvm::legacy::PassManagerImpl::run(llvm::Module&) (./bin/llc+0x2c0ee51)
#17 0x55fb684e986f compileModule(char**, llvm::LLVMContext&) llc.cpp:0:0
#18 0x55fb683d94e6 main (./bin/llc+0x6294e6)
#19 0x7f3df3d55d90 __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
#20 0x7f3df3d55e40 call_init ./csu/../csu/libc-start.c:128:20
#21 0x7f3df3d55e40 __libc_start_main ./csu/../csu/libc-start.c:379:5
#22 0x55fb684e0e25 _start (./bin/llc+0x730e25)
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120021] [lldb] Debugger::IOHandlerThread accessing invalid fd causes python crash
Issue 120021 Summary [lldb] Debugger::IOHandlerThread accessing invalid fd causes python crash Labels lldb Assignees Reporter slydiman Sometimes we got an unexpected fail of the test `UNRESOLVED: lldb-api::TestIOHandlerResizeNoEditline.py` on Windows host. https://lab.llvm.org/staging/#/builders/197/builds/1562 https://lab.llvm.org/staging/#/builders/197/builds/1541 https://lab.llvm.org/staging/#/builders/197/builds/1512 The exit code 0xC409 means an assert/exception inside the native python code. I already fixed the test `lldb-api::TestModuleLoadedNotifys.py` for Windows #92286. But this test still crashes sometimes on the last line `dbg.GetInputFile().Close()` with the following exception inside CRT: ``` Exception Code: 0x8003 #0 0x7ffb4842e03d (C:\WINDOWS\SYSTEM32\ucrtbased.dll+0x14e03d) #1 0x7ffb4842e4f5 (C:\WINDOWS\SYSTEM32\ucrtbased.dll+0x14e4f5) #2 0x7ffb28a29f09 lldb_private::NativeFile::GetStream(void) D:\llvm-project\lldb\source\Host\common\File.cpp:292:0 #3 0x7ffb289af668 lldb_private::IOHandler::GetInputFILE(void) D:\llvm-project\lldb\source\Core\IOHandler.cpp:92:0 #4 0x7ffb289b0988 lldb_private::IOHandlerEditline::GetLine(class std::basic_string, class std::allocator> &, bool &) D:\llvm-project\lldb\source\Core\IOHandler.cpp:385:0 #5 0x7ffb289b034e lldb_private::IOHandlerEditline::Run(void) D:\llvm-project\lldb\source\Core\IOHandler.cpp:596:0 #6 0x7ffb28887c68 lldb_private::Debugger::RunIOHandlers(void) D:\llvm-project\lldb\source\Core\Debugger.cpp:1118:0 #7 0x7ffb2888a644 lldb_private::Debugger::IOHandlerThread(void) D:\llvm-project\lldb\source\Core\Debugger.cpp:2052:0 #8 0x7ffb2888ebb7 `lldb_private::Debugger::StartIOHandlerThread'::`5'operator() D:\llvm-project\lldb\source\Core\Debugger.cpp:2163:0 #9 0x7ffb2889b7c4 std::invoke<`lldb_private::Debugger::StartIOHandlerThread'::`5':: &> C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.42.34433\include\type_traits:1696:0 #10 0x7ffb2888ef8b std::_Func_impl_no_alloc<`lldb_private::Debugger::StartIOHandlerThread'::`5'::,unsigned int>::_Do_call C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.42.34433\include\functional:878:0 #11 0x7ffb28a82f80 std::_Func_class::operator()(void) const C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.42.34433\include\functional:921:0 #12 0x7ffb28a82e0c lldb_private::HostNativeThreadBase::ThreadCreateTrampoline(void *) D:\llvm-project\lldb\source\Host\common\HostNativeThreadBase.cpp:62:0 #13 0x7ffb48393010 (C:\WINDOWS\SYSTEM32\ucrtbased.dll+0xb3010) #14 0x7ffb774c4cb0 (C:\WINDOWS\System32\KERNEL32.DLL+0x14cb0) #15 0x7ffb78a1edcb (C:\WINDOWS\SYSTEM32\ntdll.dll+0x7edcb) ``` It seems `Debugger::IOHandlerThread` is using an invalid (already closed) m_descriptor in the line `m_descriptor = ::_dup(m_descriptor);` inside `NativeFile::GetStream()` and python crashes handling a CRT exception (invalid fd). ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120019] lld reports undefined symbols
Issue 120019 Summary lld reports undefined symbols Labels lld Assignees Reporter stsp [lld.tar.gz](https://github.com/user-attachments/files/18142004/lld.tar.gz) Attached is a test-case. It has many objects and 2 scripts: test_bfd.sh and test_lld.sh. They are identical except for calling different linkers. test_bfd.sh doesn't print any errors or warnings. It links `kernel.elf` which actually works. test_lld.sh throws many unclear errors. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120028] [clang-format] Poorly formatted C++ initializers in a function call
Issue
120028
Summary
[clang-format] Poorly formatted C++ initializers in a function call
Labels
clang-format
Assignees
Reporter
corporateshark
Poor formatting [here](https://github.com/PacktPublishing/3D-Graphics-Rendering-Cookbook-Second-Edition/blob/4147bf9292114e87e1b8b83ec7a7446ea4254b1e/Chapter11/06_FinalDemo/src/main.cpp#L881). Config used [.clang-format](https://github.com/PacktPublishing/3D-Graphics-Rendering-Cookbook-Second-Edition/blob/4147bf9292114e87e1b8b83ec7a7446ea4254b1e/.clang-format).
```
buf.cmdDispatchThreadGroups(
{
1, 1, 1
},
{ .textures = {
lvk::TextureHandle(texLuminanceViews[0]),
lvk::TextureHandle(texAdaptedLuminance[0]),
lvk::TextureHandle(texAdaptedLuminance[1]),
} });
```
**Expected:**
```
buf.cmdDispatchThreadGroups(
{ 1, 1, 1 },
{ .textures = {
lvk::TextureHandle(texLuminanceViews[0]),
lvk::TextureHandle(texAdaptedLuminance[0]),
lvk::TextureHandle(texAdaptedLuminance[1]),
} });
```
or
```
buf.cmdDispatchThreadGroups(
{
1, 1, 1,
},
{ .textures = {
lvk::TextureHandle(texLuminanceViews[0]),
lvk::TextureHandle(texAdaptedLuminance[0]),
lvk::TextureHandle(texAdaptedLuminance[1]),
} });
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120033] Compilation Hang Issue with Deeply Nested Template Instantiation in LLVM-18 and Trunk
Issue
120033
Summary
Compilation Hang Issue with Deeply Nested Template Instantiation in LLVM-18 and Trunk
Labels
new issue
Assignees
Reporter
iamanonymouscs
This hang can be observed in both LLVM 18 and LLVM trunk versions.[https://godbolt.org/z/dKPhr395q](https://godbolt.org/z/dKPhr395q)
# Command
`clang++ bug.C`
# Code
```cpp
template class>
struct A;
template
struct B {
template
struct C {
template class TT>
using type = A;
};
};
template struct B<>;
template
struct C {
template
struct D : C::template C::type::template C::type::type::type::type::type::type::type::type::type::type::type::type::type::type::type::type::type::type::type::type::type::type::type::type::type::type::type::type::type::type::type::type>::C;
```
# Version
`clang++ --version`
```sh
Ubuntu clang version 18.1.8 (++20240731025011+3b5b5c1ec4a3-1~exp1~20240731145104.143)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120035] [MLIR][Tensor] tensor.extractOp adjustment when source is reshaped
Issue 120035 Summary [MLIR][Tensor] tensor.extractOp adjustment when source is reshaped Labels mlir Assignees Reporter hockyy Wondering if there's any adjustment if a source of a extractOp function is reshaped/collapsed/expanded is the logic of something like this correct: ``` // Process indices in the group from right to left. // if its dynamic then need to get mixes indices // Example: // indexing: 2 3 4 5 // oldMixedSize: 3| %dim2 | 8 | %dim1 // extractindices: %ex4 | 1 | 5 | %extract3 // newIndex = %extract3 + %dim1 * 5 + (8 * %dim1) * 1 + (%dim2 * 8 * // %dim1) * %ex4 Create computation using arith here // Accumulate indices from right to left ``` for expansion, we need to do modulo and div, for collapse we need to do mul and add ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120042] [Flang] Compilation error when two arguments of transfer intrinsic function have different kind type parameters
Issue 120042 Summary [Flang] Compilation error when two arguments of transfer intrinsic function have different kind type parameters Labels flang:frontend Assignees Reporter ohno-fj ``` Version of flang : 20.0.0(2b129dacdde667137b5012d52f1d96e0ab26c749)/AArch64 ``` When building [bigdft-chess Version 1.9.5](https://gitlab.com/l_sim/bigdft-suite/-/archive/1.9.5/bigdft-suite-1.9.5.tar.gz), a compilation error occurs. When two arguments (`source` and `mold`) of `transfer` intrinsic function have different `kind type parameters`, a compilation error occurs. Even if the `types` are the same or different, if the `kind type parameters` are the same (for example, kind=4 and kind=4), a compilation terminates normally, and if they are different (for example, kind=4 and kind=8), a compilation error occurs. The following are the test program, Flang, Gfortran and ifx compilation/execution result. test_2.f90: ```fortran program main integer(4), dimension(5) :: int_array real(8), dimension(5) :: real_array int_array = (/ 1, 2, 3, 4, 5 /) real_array = transfer(int_array, real_array) write(6,*) "real_array = ", real_array end program main ``` ``` $ flang test_2.f90 error: Semantic errors in test_2.f90 ./test_2.f90:5:3: error: Dimension 1 of left-hand side has extent 5, but right-hand side has extent 3 real_array = transfer(int_array, real_array) ^^ $ ``` ``` $ gfortran test_2.f90; ./a.out real_array = 4.2439915824246103E-314 8.4879831653432862E-314 2.4703282292062327E-323 3.4767205879998127E-310 3.4767205879660186E-310 $ ``` ``` $ ifx test_2.f90; ./a.out real_array = 4.243991582424610E-314 8.487983165343286E-314 2.470328229206233E-323 0.000E+000 0.000E+000 $ ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120015] AVX mem broadcasts are cached on the stack
Issue
120015
Summary
AVX mem broadcasts are cached on the stack
Labels
new issue
Assignees
Reporter
KyleSiefring
After exhausting registers inside of a loop, clang stores the results of a broadcast on the stack. This is inefficient, since broadcasting from memory is as fast as loading
Consider the following pseudo code:
```
float *restrict arr = ...; // prevent aliasing
loop {
exhaust vector registers
__mm256 x = _mm256_set1_ps(arr[0]);
use x
}
```
When clang compiles this, arr[0] is broadcasted outside the loop then x is stored on the stack.
```
vbroadcastssymm0, dword ptr [rdx]
vmovups ymmword ptr [rsp - 72], ymm0
loop:
...
load x from stack
use x
jmp loop
```
The expected behavior is:
```
loop:
...
vbroadcastssx, dword ptr [rdx]
use x
jmp loop
```
Obligatory Godbolt Sample: https://godbolt.org/z/v7MYcefxY (Sorry if my method of stressing register allocation results in too much asm/bytecode.)
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120031] Request Commit Access For liusy58
Issue 120031 Summary Request Commit Access For liusy58 Labels infra:commit-access-request Assignees Reporter liusy58 ### Why Are you requesting commit access ? I am currently working on BOLT project, and I want to contribute to BOLT. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
