This is an archive of the discontinued LLVM Phabricator instance.

[asan] Restore dead-code-elimination optimization for Fuchsia
ClosedPublic

Authored by mcgrathr on Aug 7 2017, 2:43 PM.

Details

Summary

r310244 fixed a bug introduced by r309914 for non-Fuchsia builds.
In doing so it also reversed the intended effect of the change for
Fuchsia builds, which was to allow all the AllocateFromLocalPool
code and its variables to be optimized away entirely.

This change restores that optimization for Fuchsia builds, but
doesn't have the original change's bug because the comparison
arithmetic now takes into account the size of the elements.

Diff Detail

Repository
rL LLVM

Event Timeline

mcgrathr created this revision.Aug 7 2017, 2:43 PM
vitalybuka added inline comments.
lib/asan/asan_malloc_linux.cc
35 ↗(On Diff #110094)

Maybe just to guard #if !defined(SANITIZER_FUCHSIA)
from line 29 to 64, and create empty implementation in #else section

mcgrathr added inline comments.Aug 7 2017, 3:46 PM
lib/asan/asan_malloc_linux.cc
35 ↗(On Diff #110094)

So, you mean exactly what I had originally in https://reviews.llvm.org/D36190?id=109395 before you asked me to change it to avoid #if tests? Really?

I'll change it back if you want. But you actually did convince me that avoiding #if here was better.
If you are concerned about the correctness of this change (which I don't think you should be), then I can add a simple "&& !SANITIZER_FUCHSIA" short-circuit instead of this change.

vitalybuka edited edge metadata.Aug 7 2017, 4:42 PM

LGTM

lib/asan/asan_malloc_linux.cc
35 ↗(On Diff #110094)

I know, and actually now sure.
I don't like #ifs and I don't like multiple branches where they are not needed.

Correctness looks good to me, but all this hassle for optimization which can be omitted by compiler.

So I don't like all three approaches in the same degree :-)
Aleksey WDYT?

alekseyshl accepted this revision.Aug 7 2017, 4:50 PM
alekseyshl added inline comments.
lib/asan/asan_malloc_linux.cc
35 ↗(On Diff #110094)

I guess it's fine, the extra multiplication should not be a problem (it should be compiled into shift anyway). If it is going to cause any issues, we will convert it into actual offset, not an index.

This revision is now accepted and ready to land.Aug 7 2017, 4:50 PM

Thanks! Please land it for me.

This revision was automatically updated to reflect the committed changes.