Some Keylocker intrinsics will set Zero flag if run error, in this case, we will zero the output of their intrinsic.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
"x64 debian build failed" should has no relation with this patch, PLS ignore it.
I checked the log of "x64 debian failed": (And another patch "https://reviews.llvm.org/D104773" also has the same build fail.)
tools/flang/include/flang/Optimizer/Dialect/FIROps.h.inc:1480:32: error: functions that differ only in their return type cannot be overloaded static constexpr StringRef calleeAttrName() { return "callee"; } ~~~~~~~~~ ^ tools/flang/include/flang/Optimizer/Dialect/FIROps.h.inc:1452:22: note: previous definition is here ::mlir::Identifier calleeAttrName() {
To keep the same style of the old code, PLS ignore the tools clang-tidy and clang format warning.
clang/lib/CodeGen/CGBuiltin.cpp | ||
---|---|---|
14744–14764 | Do we need to distinguish 128 and 256. Should it better just use "aesenc_error" etc.? | |
14851–14856 | Can we zero the memory in one-off? | |
clang/test/CodeGen/X86/keylocker.c | ||
2 | Can we use O2 to reduce the CHECKs or only check the buildin and branch instrcutions? |
clang/lib/CodeGen/CGBuiltin.cpp | ||
---|---|---|
14744–14764 | I didn't distinguish before, to let the symbol be more clear with their intrinsics, I distinguish them. | |
14851–14856 | Sorry, what is the "one-off" means ? | |
clang/test/CodeGen/X86/keylocker.c | ||
2 | clang_cc1 is default to O0, I think there is a beneafit to not bring into optimization changes in the future for CHECKs. |
LGTM.
clang/lib/CodeGen/CGBuiltin.cpp | ||
---|---|---|
14851–14856 | I mean you can clear the memory in one time, e.g. Builder.CreateMemSet(Ptr, Builder.getInt8(0), 16 * 8, 16) |
clang/lib/CodeGen/CGBuiltin.cpp | ||
---|---|---|
14834 | Sorry I'm late here. Instead of having 3 separate strings for each intrinsic can you do something like createBasicBlock(BaseName + "_no_error"...) here. I believe createBasicBlock takes a Twine. |
clang/lib/CodeGen/CGBuiltin.cpp | ||
---|---|---|
14834 | Hello Craig! Nice to meet you again :) , Sorry for not noticing you this patch before. I planned not to disturb you if not necessary. Yes, using Twine will more clear, let me refine it. Thanks a lot! |
Do we need to distinguish 128 and 256. Should it better just use "aesenc_error" etc.?