[PATCH] D23799: [ESan][MIPS] Adds support for MIPS64

Derek Bruening via llvm-commits llvm-commits at lists.llvm.org
Wed Aug 31 22:25:13 PDT 2016

bruening accepted this revision.
This revision is now accepted and ready to land.

Comment at: lib/esan/esan_shadow.h:240
@@ +239,3 @@
+    case 40: return appToShadowImpl<ShadowMapping::ShadowMemoryMask40>(App);
+    case 47: return appToShadowImpl<ShadowMapping::ShadowMemoryMask47>(App);
+    default: {
I think the prevailing LLVM style is to not indent the cases, though an if..else is always faster than a switch for so few cases.  However, given that the associated compiler instrumentation is hardcoded for one target, do we need to pay a runtime cost when a different library is going to picked for MIPS vs x86?  I.e., is there a reason not to hardcode the library in the same way as the compiler instru?

I don't want to drag this out, and maybe this should be measured before over-thinking it, though with all of the memsets and memcpys coming here intuition says that appToShadow is going to be a bottleneck.  I'm fine with either the prior diff or sthg like this one with a comment about making the mask static.  The offset and scale are already loaded and not constants unfortunately.



More information about the llvm-commits mailing list