User Details
- User Since
- Nov 6 2021, 11:04 AM (33 w, 1 d)
Thu, Jun 16
Wed, Jun 15
Indeed. The original patch that kicked this off was just to optimize bcmp so the LLVM optimization
would be meaningful. Cest la vie.
I don't think we can call __memcmpeq directly because this will not work on older versions of the glibc (as discussed above).
I have a patch here: https://reviews.llvm.org/D127461
I personally don't have a strong opinion, but I know that during the initial RFC some people were against adding a backend flag for this (https://reviews.llvm.org/D56248): see the discussion here: https://lists.llvm.org/pipermail/llvm-dev/2019-January/128827.html.
Sat, Jun 11
Thu, Jun 9
NB: Also have patch to add __memcmpeq as bonafide builtin in clang. Figure that's a bigger change but if people are interested LMK.
Nov 6 2021
So the version parsing doesn't appear to work out of the box for GLIBC and your right that it will miss cases (cross compilation as you pointed out) as well as free standing compilation or libraries like cpu-rt.
I was planing to add Triple::isGNUVersionLT and use it in a function hasMemcmpeq in a similar vein to hasBcmp. Will there be an issue with that?