getObjectSize() is based on ObjectSizeOffsetVisitor, which has become very expensive over time. The implementation is geared towards computing as-good-as-possible results for the objectsize intrinsics and similar. However, we also use it in BasicAA, which is very hot, and really only cares about the base cases like alloca/malloc/global, not any of the analysis for GEPs, phis, or loads. Add a new getBaseObjectSize() API for this use case, which only handles the non-recursive cases. As a bonus, this API can easily return a TypeSize and thus support scalable vectors. For now, I'm explicitly discarding the scalable sizes in BasicAA just to avoid unnecessary behavior changes during this refactor.
…generating empty location Fix the regression detected by https://github.com/llvm/llvm-test-suite/pull/188
…nd malloc parameters bound Using a naive expression walker, it is possible to compute valuable information for allocation functions, GEP and alloca, even in the presence of some dynamic information. We don't rely on computeConstantRange to avoid taking advantage of undefined behavior, which would be counter-productive wrt. usual llvm.objectsize usage. llvm.objectsize plays an important role in _FORTIFY_SOURCE definitions, so improving its diagnostic in turns improves the security of compiled application. As a side note, as a result of recent optimization improvements, clang no longer passes https://github.com/serge-sans-paille/builtin_object_size-test-suite This commit restores the situation and greatly improves the scope of code handled by the static version of __builtin_object_size. This is a recommit of https://github.com/llvm/llvm-project/pull/115522 with fix applied.
…ve offset In Exact mode, the approximation of returning (0,0) is invalid. It only holds in min/max mode.
Reverts llvm/llvm-project#115522 This caused UBSan errors in multi-stage clang build: https://lab.llvm.org/buildbot/#/builders/25/builds/4241/steps/10/logs/stdio
Using a naive expression walker, it is possible to compute valuable
information for
allocation functions, GEP and alloca, even in the presence of some
dynamic
information.
We don't rely on computeConstantRange to avoid taking advantage of
undefined behavior, which would be counter-productive wrt. usual
llvm.objectsize usage.
llvm.objectsize plays an important role in _FORTIFY_SOURCE definitions,
so improving its diagnostic in turns improves the security of compiled
application.
As a side note, as a result of recent optimization improvements, clang
no
longer passes
https://github.com/serge-sans-paille/builtin_object_size-test-suite
This commit restores the situation and greatly improves the scope of
code handled by the static version of __builtin_object_size.
The internal structure used to carry intermediate computations hold
signed values. If an object size happens to overflow signed values, we
can get invalid result, so make sure this situation never happens.
This is not very limitative as static allocation of such large values
should scarcely happen.
This reverts commit 5f342816efe1854333f2be41a03fdd25fa0db433. This seems to break various builders, such as https://lab.llvm.org/buildbot/#/builders/41/builds/3259 https://lab.llvm.org/buildbot/#/builders/76/builds/4298
Using LazyValueInfo, it is possible to compute valuable information for allocation functions, GEP and alloca, even in the presence of dynamic information. llvm.objectsize plays an important role in _FORTIFY_SOURCE definitions, so improving its diagnostic in turns improves the security of compiled application. As a side note, as a result of recent optimization improvements, clang no longer passes https://github.com/serge-sans-paille/builtin_object_size-test-suite This commit restores the situation and greatly improves the scope of code handled by the static version of __builtin_object_size.