RISC-V 64-bit doesn’t have legal 32-bit integers. When the frontend emits a call to memcmp, the call is annotated with a signext return attribute. This tells the backend the result is always sign extended to 64 bits.
If LibCallSimplifier sees that the memcmp is only used by an equality comparison with 0, it will convert it to bcmp. Unfortunately, the signext attribute is not preserved.
This causes the backend to sign extend the bcmp result to 64 bits in order to compare it to 0. This sign extend would not be needed if the signext attribute was present.
Would it be legal to preserve this attribute during the conversion?
I don’t think you ought to look at this as “preserve” – if signext is needed for “int” return values, it should be set by llvm::emitBCmp – and the same for any other libcall builder for a function returning “int”.
BuildLibCalls.cpp already handles the addition of appropriate signext/zeroext for arguments of type “int”, via asking TLI.getExtAttrForI32Param. We also have an TLI.getExtAttrForI32Return API, though, oddly, nothing has ever called it since it was added in 5ae2c526db3f5a4d3c8e0c07cbcac49a3bb9fd0a, back in 2016. ISTM BuildLibCalls should be calling it (And it should return the proper value for riscv64.)