MemoryBuiltins: remove malloc-family funcs from list

We no longer need specialized knowledge of these allocator functions in
this file since we have the correct attributes available now.

As far as

MemoryBuiltins: remove malloc-family funcs from list

We no longer need specialized knowledge of these allocator functions in
this file since we have the correct attributes available now.

As far as I can tell the changes in the attributor tests are due to
things getting more consistent on alloc-family once we remove the static
list entries.

The two test changes in NewGVN merit extra scrutiny: NewGVN appears to
be _extremely_ sensitive to the inaccessiblememonly for reasons that
are beyond me. As a result, I had-enumerated all the attributes on
allocation functions in those two tests instead of using -inferattrs.
I assumed that the two -disable-simplify-libcalls tests there no
longer are sensible since the function declaration now includes all the
relevant attributes.

Differential Revision: https://reviews.llvm.org/D130107

show more ...

MemoryBuiltins: accept non-TLI funcs with attribs as allocator funcs

This allows us to accept annotations from out-of-tree languages (the
example test is derived from Rust) so they can enjoy the ben

MemoryBuiltins: accept non-TLI funcs with attribs as allocator funcs

This allows us to accept annotations from out-of-tree languages (the
example test is derived from Rust) so they can enjoy the benefits of
LLVM's optimizations without requiring LLVM to have language-specific
knowledge.

Differential Revision: https://reviews.llvm.org/D123091

show more ...

MemoryBuiltins: start using properties of functions

Prior to this change, we relied on the hard-coded list for all of the
information performed by MemoryBuiltins. With this change, we're able to
sta

MemoryBuiltins: start using properties of functions

Prior to this change, we relied on the hard-coded list for all of the
information performed by MemoryBuiltins. With this change, we're able to
start relying on properites of functions described in attributes, which
opens the door to out-of-tree compilers being able to describe their
allocator functions to LLVM's optimizer logic without having to register
their implementation details with LLVM.

Differential Revision: https://reviews.llvm.org/D123090

show more ...

[MemoryBuiltins] Add getReallocatedOperand() function (NFC)

Replace the value-accepting isReallocLikeFn() overload with a
getReallocatedOperand() function, which returns which operand is
the one bei

[MemoryBuiltins] Add getReallocatedOperand() function (NFC)

Replace the value-accepting isReallocLikeFn() overload with a
getReallocatedOperand() function, which returns which operand is
the one being reallocated. Currently, this is always the first one,
but once allockind(realloc) is respected, the reallocated operand
will be determined by the allocptr parameter attribute.

show more ...

[MemoryBuiltins] Remove isFreeCall() function (NFC)

Remove isFreeCall() in favor of getFreedOperand(). Replace the
two remaining uses with a getFreedOperand() != nullptr check, as
they only care tha

[MemoryBuiltins] Remove isFreeCall() function (NFC)

Remove isFreeCall() in favor of getFreedOperand(). Replace the
two remaining uses with a getFreedOperand() != nullptr check, as
they only care that something is getting freed. (The usage in DSE
is correct as such. The allocator-related checks in CFLGraph look
rather questionable in general.)

show more ...

[MemoryBuiltins] Add getFreedOperand() function (NFCI)

We currently assume in a number of places that free-like functions
free their first argument. This is true for all hardcoded free-like
function

[MemoryBuiltins] Add getFreedOperand() function (NFCI)

We currently assume in a number of places that free-like functions
free their first argument. This is true for all hardcoded free-like
functions, but with the new attribute-based design, the freed
argument is supposed to be indicated by the allocptr attribute.

To make sure we handle this correctly once allockind(free) is
respected, add a getFreedOperand() helper which returns the freed
argument, rather than just indicating whether the call frees *some*
argument.

This migrates most but not all users of isFreeCall() to the new
API. The remaining users are a bit more tricky.

show more ...

[MemoryBuiltins] Default to trivial mapper in getAllocSize() (NFC)

Default getAllocSize() to use the trivial mapper. Also switch
from using std::function to function_ref.

Furthermore, update the do

[MemoryBuiltins] Default to trivial mapper in getAllocSize() (NFC)

Default getAllocSize() to use the trivial mapper. Also switch
from using std::function to function_ref.

Furthermore, update the doc comment to point out a subtle difference
between getAllocSize() and getObjectSize(): The latter may also
return something for calls that return their argument (via "returned"
attribute or special intrinsics like invariant groups).

show more ...

[MemoryBuiltins] Don't query TLI for non-pointer functions (NFC)

Fetching allocation data for calls is a rather hot operation, and
TLI lookups are slow. We can greatly reduce the number of calls
for

[MemoryBuiltins] Don't query TLI for non-pointer functions (NFC)

Fetching allocation data for calls is a rather hot operation, and
TLI lookups are slow. We can greatly reduce the number of calls
for which TLI is queried by checking that they return a pointer
value first, as this is a requirement for allocation functions
anyway.

show more ...

[MemoryBuiltins] Avoid isAllocationFn() call before checking removable alloc

Alloc directly checking whether a given call is a removable
allocation, instead of first checking whether it is an alloca

[MemoryBuiltins] Avoid isAllocationFn() call before checking removable alloc

Alloc directly checking whether a given call is a removable
allocation, instead of first checking whether it is an allocation
first.

show more ...

[llvm] Use value instead of getValue (NFC)

[NFC] Switch a few uses of undef to poison as placeholders for unreachble code

[llvm] Use Optional::has_value instead of Optional::hasValue (NFC)

This patch replaces x.hasValue() with x.has_value() where x is not
contextually convertible to bool.

[llvm] Don't use Optional::hasValue (NFC)

This patch replaces Optional::hasValue with the implicit cast to bool
in conditionals only.

Revert "Don't use Optional::hasValue (NFC)"

This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.

Don't use Optional::hasValue (NFC)

[MemoryBuiltins] Accept any value in getInitialValueOfAllocation() (NFC)

Drop the requirement that getInitialValueOfAllocation() must be
passed an allocator function, shifting the responsibility for

[MemoryBuiltins] Accept any value in getInitialValueOfAllocation() (NFC)

Drop the requirement that getInitialValueOfAllocation() must be
passed an allocator function, shifting the responsibility for
checking that into the function (which it does anyway). The
motivation is to avoid some calls to isAllocationFn(), which has
somewhat ill-defined semantics (given the number of
allocator-related attributes we have floating around...)

(For this function, all we eventually need is an allockind of
zeroed or uninitialized.)

Differential Revision: https://reviews.llvm.org/D127274

show more ...

[llvm] Don't use Optional::hasValue (NFC)

[Alignment] Remove alignTo version taking a MaybeAlign

[llvm] Use value_or instead of getValueOr (NFC)

[APInt] Remove all uses of zextOrSelf, sextOrSelf and truncOrSelf

Most clients only used these methods because they wanted to be able to
extend or truncate to the same bit width (which is a no-op).

[APInt] Remove all uses of zextOrSelf, sextOrSelf and truncOrSelf

Most clients only used these methods because they wanted to be able to
extend or truncate to the same bit width (which is a no-op). Now that
the standard zext, sext and trunc allow this, there is no reason to use
the OrSelf versions.

The OrSelf versions additionally have the strange behaviour of allowing
extending to a *smaller* width, or truncating to a *larger* width, which
are also treated as no-ops. A small amount of client code relied on this
(ConstantRange::castOp and MicrosoftCXXNameMangler::mangleNumber) and
needed rewriting.

Differential Revision: https://reviews.llvm.org/D125557

show more ...

BuildLibCalls: simplify switch statement slightly

Per feedback on D123086 after submit.

Also added a test for vec_malloc et al attribute inference to show it's
doing the right thing.

The new tests

BuildLibCalls: simplify switch statement slightly

Per feedback on D123086 after submit.

Also added a test for vec_malloc et al attribute inference to show it's
doing the right thing.

The new tests exposed a defect, corrected by adding vec_free to the list of
free functions in MemoryBuiltins.cpp, which had been overlooked all the
way back in D94710, over a year ago.

Differential Revision: https://reviews.llvm.org/D124859

show more ...

Revert "[ValueTracking] Make getStringLenth aware of strdup"

This reverts commit e810d558093cff40caaa1aff24d289c76c59916d.

The commit was not taken into account the fact that strduped string could

Revert "[ValueTracking] Make getStringLenth aware of strdup"

This reverts commit e810d558093cff40caaa1aff24d289c76c59916d.

The commit was not taken into account the fact that strduped string could be
modified. Checking if such modification happens would make the function very
costly, without a test case in mind it's not worth the effort.

show more ...

[ValueTracking] Make getStringLenth aware of strdup

During strlen compile-time evaluation, make it possible to track size of
strduped strings.

Differential Revision: https://reviews.llvm.org/D123497

[MemoryBuiltins] Remove unnecessary lambda capture (NFC)

[builtin_object_size] Basic support for posix_memalign

It actually implements support for seeing through loads, using alias analysis to
refine the result.

This is rather limited, but I didn't want

[builtin_object_size] Basic support for posix_memalign

It actually implements support for seeing through loads, using alias analysis to
refine the result.

This is rather limited, but I didn't want to rely on more than available
analysis at that point (to be gentle with compilation time), and it does seem to
catch common scenario, as showcased by the included tests.

Differential Revision: https://reviews.llvm.org/D122431

show more ...