[PATCH] D78662: [builtins] Support architectures with 16-bit int

[Eli Friedman via Phabricator via llvm-commits]

efriedma added a comment.

> In summary: I think using int is fine as LLVM internally passes an i8

That doesn't seem quite right.  Consider, for example, `long long a(long long a, int b) { return a << (char)(b); }`.  To generate correct code, you need to clear the high bits of b.  If we just model the argument as an anyext i8, we'll skip clearing those bits, and the compiler-rt C implementations will have undefined behavior.  It looks like LLVM does actually extend the value to "int", though.  (It doesn't choose between sign/zero extend consistently, but it doesn't actually matter here).

I tried to gather some other relevant evidence from building some examples with gcc.  Apparently popcount and count leading/trailing zeros do actually return "int", always.  This change is consistent with that; we probably should fix LLVM.  (LLVM doesn't usually use the libcalls for those, but it can in some cases, I think.)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D78662/new/

https://reviews.llvm.org/D78662