Assertion on arithmetic with sve-vector-bits

[Quuxplusone]

Bugzilla Link	PR48016
Status	NEW
Importance	P enhancement
Reported by	Craig Topper (craig.topper@gmail.com)
Reported on	2020-10-29 16:35:59 -0700
Last modified on	2021-05-29 13:38:19 -0700
Version	unspecified
Hardware	PC All
CC	cullen.rhodes@arm.com, evandro.menezes@sifive.com, llvm-bugs@lists.llvm.org, matdzb@gmail.com, neeilans@live.com, richard-llvm@metafoo.co.uk
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also

This test case triggers an assertion in clang CodeGen. I don't know this is
valid code or not, but if it is invalid it should be diagnosed instead of
asserting.

clang -target aarch64-none-linux-gnu -march=armv8-a+sve -msve-vector-bits=128

#define N __ARM_FEATURE_SVE_BITS

typedef __SVInt8_t svint8_t;
typedef svint8_t fixed_int8_t __attribute__((arm_sve_vector_bits(N)));

svint8_t to_svint8_t(fixed_int8_t x) { return x * x; }

clang/lib/CodeGen/CGExpr.cpp:4902: clang::CodeGen::LValue
clang::CodeGen::CodeGenFunction::EmitBinaryOperatorLValue(const
clang::BinaryOperator*): Assertion `E->getOpcode() == BO_Assign && "unexpected
binary l-value"' failed.
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace, preprocessed source, and associated run script.
Stack dump:
0.      Program arguments: ./bin/clang -target aarch64-none-linux-gnu -
march=armv8-a+sve -msve-vector-bits=128 arm-casting.c -S -O2 -o -
1.      <eof> parser at end of file
2.      arm-casting.c:6:10: LLVM IR generation of declaration 'to_svint8_t'
3.      arm-casting.c:6:10: Generating code for declaration 'to_svint8_t'
#0 0x0000000002bd23ce llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
(./bin/clang+0x2bd23ce)
#1 0x0000000002bcfe4c llvm::sys::RunSignalHandlers() (./bin/clang+0x2bcfe4c)
#2 0x0000000002bd0102 llvm::sys::CleanupOnSignal(unsigned long)
(./bin/clang+0x2bd0102)
#3 0x0000000002b3ea28 CrashRecoverySignalHandler(int) (./bin/clang+0x2b3ea28)
#4 0x00007ff1691c0390 __restore_rt (/lib/x86_64-linux-
gnu/libpthread.so.0+0x11390)
#5 0x00007ff167f32438 raise /build/glibc-e6zv40/glibc-
2.23/signal/../sysdeps/unix/sysv/linux/raise.c:54:0
#6 0x00007ff167f3403a abort /build/glibc-e6zv40/glibc-2.23/stdlib/abort.c:91:0
#7 0x00007ff167f2abe7 __assert_fail_base /build/glibc-e6zv40/glibc-
2.23/assert/assert.c:92:0
#8 0x00007ff167f2ac92 (/lib/x86_64-linux-gnu/libc.so.6+0x2dc92)
#9 0x0000000003118075
clang::CodeGen::CodeGenFunction::EmitBinaryOperatorLValue(clang::BinaryOperator
const*) (./bin/clang+0x3118075)
#10 0x000000000310d09e clang::CodeGen::CodeGenFunction::EmitLValue(clang::Expr
const*) (./bin/clang+0x310d09e)
#11 0x00000000009d27c3 (anonymous
namespace)::ScalarExprEmitter::VisitCastExpr(clang::CastExpr*)
(./bin/clang+0x9d27c3)
#12 0x000000000314294d (anonymous
namespace)::ScalarExprEmitter::Visit(clang::Expr*) (./bin/clang+0x314294d)
#13 0x0000000003143086
clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool)
(./bin/clang+0x3143086)
#14 0x0000000002e904a5
clang::CodeGen::CodeGenFunction::EmitReturnStmt(clang::ReturnStmt const&)
(./bin/clang+0x2e904a5)
#15 0x0000000002e92359 clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt
const*, llvm::ArrayRef<clang::Attr const*>) (./bin/clang+0x2e92359)
#16 0x0000000002e93264
clang::CodeGen::CodeGenFunction::EmitCompoundStmtWithoutScope(clang::CompoundStmt
const&, bool, clang::CodeGen::AggValueSlot) (./bin/clang+0x2e93264)
#17 0x0000000002edeaa3
clang::CodeGen::CodeGenFunction::EmitFunctionBody(clang::Stmt const*)
(./bin/clang+0x2edeaa3)
#18 0x0000000002eee21b
clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl,
llvm::Function*, clang::CodeGen::CGFunctionInfo const&) (./bin/clang+0x2eee21b)
#19 0x0000000002f2a2b6
clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl,
llvm::GlobalValue*) (./bin/clang+0x2f2a2b6)
#20 0x0000000002f27d53
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl,
llvm::GlobalValue*) (./bin/clang+0x2f27d53)
#21 0x0000000002f2840b
clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl)
(./bin/clang+0x2f2840b)
#22 0x0000000002f2e74a
clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*)
(.part.5985.constprop.5989) (./bin/clang+0x2f2e74a)
#23 0x00000000039d7c9b (anonymous
namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef)
(./bin/clang+0x39d7c9b)
#24 0x00000000039ce0fb
clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef)
(./bin/clang+0x39ce0fb)
#25 0x00000000043aca10 clang::ParseAST(clang::Sema&, bool, bool)
(./bin/clang+0x43aca10)
#26 0x00000000039d5505 clang::CodeGenAction::ExecuteAction()
(./bin/clang+0x39d5505)
#27 0x00000000033cc7d9 clang::FrontendAction::Execute() (./bin/clang+0x33cc7d9)
#28 0x000000000338a570
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
(./bin/clang+0x338a570)
#29 0x0000000003474ef3
clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
(./bin/clang+0x3474ef3)
#30 0x0000000000b459e4 cc1_main(llvm::ArrayRef<char const*>, char const*,
void*) (./bin/clang+0xb459e4

[Quuxplusone]

Thanks for reporting this Craig.

I spent some time looking into it today and found the problem. The issue is the
CodeGen for casting between vector-length-agnostic (VLA) and vector-length-
specific (VLS) SVE types. This is done through memory and implemented with
(ScalarExprEmitter::VisitCastExpr):

      Address Addr = EmitLValue(E).getAddress(CGF);
      Addr = Builder.CreateElementBitCast(Addr, CGF.ConvertTypeForMem(DestTy));
      LValue DestLV = CGF.MakeAddrLValue(Addr, DestTy);
      DestLV.setTBAAInfo(TBAAAccessInfo::getMayAliasInfo());
      return EmitLoadOfLValue(DestLV, CE->getExprLoc());

Blindly calling EmitLValue seems wrong, I think we should check if the
expression is an r-value and store it to memory before bitcasting and then
loading. Although FWIW doing the bitcast through memory is a temporary
solution, we have work in the pipeline to re-implement this with insert/extract
subvector intrinsics which should improve the codegen and fix this issue.

The example you attached is defined by the ACLE but the use of binary operators
with VLS types is undefined unless __ARM_FEATURE_SVE_VECTOR_OPERATORS==1 is
set. We don't currently enable this feature macro under -msve-vector-bits since
support is ongoing, although as you say it shouldn't crash.

[Quuxplusone]

FWIW, it seems to work now and uses llvm.experimental.vector.insert:

-target aarch64-none-linux-gnu -march=armv8-a+sve -msve-vector-bits=128
https://clang.godbolt.org/z/vsGx8c4Y3

-target aarch64-none-linux-gnu -march=armv8-a+sve -msve-vector-bits=256
https://clang.godbolt.org/z/TdceYr7Y5

-target aarch64-none-linux-gnu -march=armv8-a+sve -msve-vector-bits=256 -mllvm -
aarch64-sve-vector-bits-min=256
https://clang.godbolt.org/z/EeYMdcKaG

(The latter two to generate SVE, otherwise resulting code uses Neon.)