[PATCH] D105440: [RFC] Implement support for __builtin_memcmp_inline

Eli Friedman via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jul 5 11:54:05 PDT 2021


efriedma added a comment.

The motivation here seems weaker than it was for memcpy.  memcmp is much less fundamental to LLVM optimizations.  It looks like the primary motivation here is to avoid duplicating the logic in llvm/lib/CodeGen/ExpandMemCmp.cpp ?  But really, it isn't very much target-independent logic, and the only target-specific bit is the heuristic for load widths.

> I'm split on what to do for when the memcmp size is large enough to hit the maximum number of loads. I think there are three options: a) We ignore the maximum number of loads and just generate a lot of code... (kind of the same strategy with memcpy) b) We use a call to memcmp (and issue a diagnostic saying we did so?) c) Error out I'm not keen on (c), I suspect (a) would probably make the most sense and hope that users of the builtin are sensible?

Or (d) generate a loop.  But it would be a bunch of work to implement that, and it's not clear the users of the function would want that.  (a) seems reasonable.



================
Comment at: llvm/include/llvm/IR/Intrinsics.td:625
 
+// Memcpy semantic that is guaranteed to be inlined.
+// In particular this means that the generated code is not allowed to call any
----------------
memcmp


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

https://reviews.llvm.org/D105440



More information about the llvm-commits mailing list