[cfe-dev] Disabling ubsan's object size check at -O0

[Vedant Kumar via cfe-dev]

UBSan has an object size check (-fsanitize=object-size) which can determine when an object is not large enough to represent a value of its type. The check uses the @llvm.objectsize intrinsic to determine the size of objects.

AFAICT, and please let me know if I've missed something here, @llvm.objectsize always conservatively returns "I don't know" (i.e -1) at -O0, which means that it can't catch any issues at -O0. This is a problem because there is a substantial compile-time cost to enabling the object size check in debug builds. It seems unlikely that we can make @llvm.objectsize more precise at -O0 without regressing compile time and the debugging experience in other ways.

So, I'm proposing that we disable ubsan's object size check at -O0. This will speed up debug builds without compromising on diagnostic quality. E.g I measured a 26% decrease in the compile time for X86FastISel.cpp with this change, and a 32% decrease in the *.o size:

No ubsan [1]
-----------------
Average compile time: 5.27 s
X86FastISel.cpp.o size: 3.06 MB

Ubsan [2]
-------------
Average compile time: 9.49 s
X86FastISel.cpp.o size: 8.93 MB

Ubsan without the object size check [3]
----------------------------------------------------
Average compile time: 6.99 s
X86FastISel.cpp.o size: 6.06 MB

There's reason to expect similar compile-time / binary size savings with other *.cpp files. The object size check is in the same category of checks as the null check and the alignment check. This group of checks accounts for the vast majority of checks inserted by ubsan (over 90% in some macOS apps), so any savings here would be helpful.

Any objections? Anyone else in favor?

thanks,
vedant

[1] -O0 -g
[2] -O0 -g -fsanitize=undefined -fno-sanitize-recover=all -fno-sanitize=vptr,function
[3] -O0 -g -fsanitize=undefined -fno-sanitize-recover=all -fno-sanitize=vptr,function,object-size
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170620/09fc14e1/attachment.html>