Default cutoff is not usefull here. Decision to
enable or not sanitizer causes more significant
performance impact, than a typical optimizations
which rely on `profile-summary-cutoff-hot`.
This is the major rename patch that prior patches have built towards.
The DPValue class is being renamed to DbgVariableRecord, which reflects
the updated terminology for the "final" implementation of the RemoveDI
feature. This is a pure string substitution + clang-format patch. The
only manual component of this patch was determining where to perform
these string substitutions: `DPValue` and `DPV` are almost exclusively
used for DbgRecords, *except* for:
- llvm/lib/target, where 'DP' is used to mean double-precision, and so
appears as part of .td files and in variable names. NB: There is a
single existing use of `DPValue` here that refers to debug info, which
I've manually updated.
- llvm/tools/gold, where 'LDPV' is used as a prefix for symbol
visibility enums.
Outside of these places, I've applied several basic string
substitutions, with the intent that they only affect DbgRecord-related
identifiers; I've checked them as I went through to verify this, with
reasonable confidence that there are no unintended changes that slipped
through the cracks. The substitutions applied are all case-sensitive,
and are applied in the order shown:
```
DPValue -> DbgVariableRecord
DPVal -> DbgVarRec
DPV -> DVR
```
Following the previous rename patches, it should be the case that there
are no instances of any of these strings that are meant to refer to the
general case of DbgRecords, or anything other than the DPValue class.
The idea behind this patch is therefore that pure string substitution is
correct in all cases as long as these assumptions hold.
llvm.dbg.assign intrinsics have 2 {value, expression} pairs; fix hwasan to
update the second expression.
Fixes#76545. This is #78606 rebased and with the addition of DPValue handling.
Note the addition of --try-experimental-debuginfo-iterators in the tests and
some shuffling of code in MemoryTaggingSupport.cpp.
This patch extends HWASAN to support maintenance of debug-info that
isn't stored as intrinsics, but is instead in a DPValue object. This is
straight-forwards: we collect any such objects in StackInfoBuilder, and
apply the same operations to them as we would to dbg.value and similar
intrinsics.
I've also replaced some calls to getNextNode with debug-info skipping
next calls, and use iterators for instruction insertion rather than
instruction pointers. This avoids any difference in output between
intrinsic / non-intrinsic debug-info, but also means that any debug-info
comes before code inserted by HWAsan, rather than afterwards. See the
test modifications, where the variable assignment (presented as a
dbg.value) jumps up over all the code inserted by HWAsan. Seeing how the
code inserted by HWAsan is always (AFAIUI) given the source-location of
the instruction being instrumented, I don't believe this will have any
effect on which lines variable assignments become visible on; it may
extend the number of instructions covered by the assignments though.
If `Type::getPointerTo` is called solely to support an unnecessary
pointer-cast, remove the call entirely.
Otherwise, replace with IRB.getPtrTy().
Clean-up work towards removing method `Type::getPointerTo`.
The other 3 sanitizers (ASAN, TSAN and MSAN) all use
maybeMarkSanitizerLibraryCallNoBuiltin to make disable optimizations
which inline functions like memcmp for example. The lack of this
optimization was allowing ExpandMemCmpPass to convert a memcmp call to
inlined assembly and cause a false negative in HWASAN.
HWAddressSanitizerPass::run sanitizes functions one by one. The
sanitization of each function - which may split blocks via
insertShadowTagCheck - may result in some cached analyses are invalid.
This matters because sanitizeFunction(F', FAM) may indirectly call the
global stack safety analysis, hence we need to make sure the analyses of
F are up to date.
Bug report: https://github.com/llvm/llvm-project/issues/66934
Usually pointer tag will match tag in the shadow, so we can keep
inlining this check keeping the rest in outlined part.
It imroves performance by about 25%, but increases code size by 30%.
Existing outlining reduces performance by 30%, but saves code size by 80%.
So we still significantly reduce code size with minimal performance loss.
Reviewed By: fmayer
Differential Revision: https://reviews.llvm.org/D159172
