<div dir="ltr">This makes sense to me.<br><div class="gmail_extra"><br><div class="gmail_quote">On 20 June 2017 at 17:58, George Burgess IV via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<span class=""><br>
> 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<br>
<br>
</span>Yup. The object-size sanitizer lowers directly to @llvm.objectsize<br>
(bypassing clang's __builtin_object_size evaluator, which is the<br>
right thing to do here), and the only places we try to lower<br>
@llvm.objectsize to a non-default value, to my knowledge, are<br>
in InstCombine and CodeGenPrepare. Looks like both of those<br>
are disabled on -O0.<br>
<br>
As you mentioned, if we did decide that we should try to<br>
lower @llvm.objectsize calls more aggressively in -O0, I'd<br>
imagine we'd still end up handing back -1 in ~99% of cases.<br>
(With the remaining 1% looking something like:<br>
<br>
struct Foo {int i;};<br>
char c;<br>
int bar() { return reinterpret_cast<Foo *>(&c)->i; } // error: c is<br>
too small, ...<br>
)<br>
<br>
So, unless I'm missing something, I think this is a pure win for<br>
ubsan in -O0. I'm in favor of it.<br>
<br>
Thank you!<br>
George<br>
<div><div class="h5"><br>
On Tue, Jun 20, 2017 at 4:57 PM, Vedant Kumar via cfe-dev<br>
<<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
> UBSan has an object size check (-fsanitize=object-size) which can determine<br>
> when an object is not large enough to represent a value of its type. The<br>
> check uses the @llvm.objectsize intrinsic to determine the size of objects.<br>
><br>
> AFAICT, and please let me know if I've missed something here,<br>
> @llvm.objectsize always conservatively returns "I don't know" (i.e -1) at<br>
> -O0, which means that it can't catch any issues at -O0. This is a problem<br>
> because there is a substantial compile-time cost to enabling the object size<br>
> check in debug builds. It seems unlikely that we can make @llvm.objectsize<br>
> more precise at -O0 without regressing compile time and the debugging<br>
> experience in other ways.<br>
><br>
> So, I'm proposing that we disable ubsan's object size check at -O0. This<br>
> will speed up debug builds without compromising on diagnostic quality. E.g I<br>
> measured a 26% decrease in the compile time for X86FastISel.cpp with this<br>
> change, and a 32% decrease in the *.o size:<br>
><br>
> No ubsan [1]<br>
> -----------------<br>
> Average compile time: 5.27 s<br>
> X86FastISel.cpp.o size: 3.06 MB<br>
><br>
> Ubsan [2]<br>
> -------------<br>
> Average compile time: 9.49 s<br>
> X86FastISel.cpp.o size: 8.93 MB<br>
><br>
> Ubsan without the object size check [3]<br>
> ------------------------------<wbr>----------------------<br>
> Average compile time: 6.99 s<br>
> X86FastISel.cpp.o size: 6.06 MB<br>
><br>
><br>
> There's reason to expect similar compile-time / binary size savings with<br>
> other *.cpp files. The object size check is in the same category of checks<br>
> as the null check and the alignment check. This group of checks accounts for<br>
> the vast majority of checks inserted by ubsan (over 90% in some macOS apps),<br>
> so any savings here would be helpful.<br>
><br>
> Any objections? Anyone else in favor?<br>
><br>
> thanks,<br>
> vedant<br>
><br>
> [1] -O0 -g<br>
> [2] -O0 -g -fsanitize=undefined -fno-sanitize-recover=all<br>
> -fno-sanitize=vptr,function<br>
> [3] -O0 -g -fsanitize=undefined -fno-sanitize-recover=all<br>
> -fno-sanitize=vptr,function,<wbr>object-size<br>
><br>
</div></div>> ______________________________<wbr>_________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
><br>
______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
</blockquote></div><br></div></div>