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

[Richard Smith via cfe-dev]

This makes sense to me.

On 20 June 2017 at 17:58, George Burgess IV via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> Hi,
>
> > 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
>
> Yup. The object-size sanitizer lowers directly to @llvm.objectsize
> (bypassing clang's __builtin_object_size evaluator, which is the
> right thing to do here), and the only places we try to lower
> @llvm.objectsize to a non-default value, to my knowledge, are
> in InstCombine and CodeGenPrepare. Looks like both of those
> are disabled on -O0.
>
> As you mentioned, if we did decide that we should try to
> lower @llvm.objectsize calls more aggressively in -O0, I'd
> imagine we'd still end up handing back -1 in ~99% of cases.
> (With the remaining 1% looking something like:
>
> struct Foo {int i;};
> char c;
> int bar() { return reinterpret_cast<Foo *>(&c)->i; } // error: c is
> too small, ...
> )
>
> So, unless I'm missing something, I think this is a pure win for
> ubsan in -O0. I'm in favor of it.
>
> Thank you!
> George
>
> On Tue, Jun 20, 2017 at 4:57 PM, Vedant Kumar via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
> > 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
> >
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170620/671631c2/attachment.html>