The patch submitted in D129915 and subsequently committed in rG0dcfe7aa35cd exposes a number of assumptions in SimplifyLibcalls.cpp about int having 32 bits. Prior to the change the assumptions, although strictly unsafe, were benign even on 16-bit targets because the validation in TargetLibraryInfoImpl::isValidProtoForLibFunc enforced the corresponding restriction. The change has corrected the function to consider valid on 16-bit targets those functions in whose declarations the int return type or argument corresponds to i16, but it did not update the corresponding call handlers in SimplifyLibcalls.cpp. The end result is that some valid C code that compiled successfully before the change (albeit with suboptimal output) now causes an abort in the handler when targeting 16-bit environments (AVR or MSP430 in tree).
As a follow-up to D129915, this change removes these 32-bit assumptions to let the same code compile successfully even for 16-bit targets, and to also enable the same optimizing transformations for those targets as for 32-bit ones.
I've tested this patch on x86_64-linux.
I do not fully understand the part with "Putchar converts it to unsigned char regardless". Is that referring to the libc implementation , or llvm::emitPutChar, or what?
Not sure if we can deal with this better regardless of the answer. I guess this would work for in-tree targets and "normal" compiler hosts. But unsigned char on the host may have a different size compared to size of unsigned char in the runtime libc implementation for the target. Since the getConstantStringInfo call above assume that a char is 8 bits (at least the in-tree version of getConstantStringInfo) and the compiler probably is built for a host with 8 bit char, then at least the compiler code match up here.
(FWIW, our OOT target with 16-bit char is now guarded by getConstantStringInfo returning false, while in the past I think isValidProtoForLibFunc might have guarded from even calling LibCallSimplifier::optimizePuts and LibCallSimplifier::optimizePrintFString.)