[PATCH] D81678: Introduce frozen attribute at call sites for stricter poison analysis

[Richard Smith - zygoloid via Phabricator via llvm-commits]

rsmith added inline comments.


================
Comment at: clang/lib/CodeGen/CGCall.cpp:2082
+  const Type *RetTyPtr = RetTy.getTypePtr();
+  if (!RetTy->isVoidType() && !RetTyPtr->isRecordType() &&
+      RetAI.getKind() != ABIArgInfo::Indirect) {
----------------
Other types that we should think about from a padding perspective:

 * `nullptr_t` (which has the same size and alignment as `void*` but is all padding)
 * 80-bit `long double` and `_Complex long double` (I don't know whether we guarantee to initialize the 6 padding bytes)
 * member pointers might contain padding under some ABI rules -- under the MS ABI, you get a struct containing N pointers followed by M ints, which could have 4 bytes of tail padding on 64-bit targets
 * vector types with tail padding (eg, a vector of 3 `char`s is sometimes passed as an `i32` with one byte `undef`)
 * matrix types (presumably the same concerns as for vector types apply here)
 * maybe Obj-C object types?
 * `_ExtInt` types (eg, returning an `_ExtInt(65)` initialized to 0 produces an `{i64, i64}` containing 7 bytes of `undef`)

It would be safer to list exactly those types for which we know this assumption is correct rather than assuming that it's correct by default -- I think more than half of the `Type` subclasses for concrete canonical types can have undef bits in their IR representation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81678