History log of /llvm-project/llvm/lib/IR/Value.cpp (Results 1 – 25 of 214)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-21-init
# 22637a87 17-Jan-2025 Florian Hahn <flo@fhahn.com>

[Loads] Respect UseDerefAtPointSemantics in isDerefAndAlignedPointer. (#123196)

If a pointer gets freed, it may not be dereferenceable any longer, even
though there is a dominating dereferenceable

[Loads] Respect UseDerefAtPointSemantics in isDerefAndAlignedPointer. (#123196)

If a pointer gets freed, it may not be dereferenceable any longer, even
though there is a dominating dereferenceable assumption. As first step,
only consider assumptions if the pointer value cannot be freed if
UseDerefAtPointSemantics is used.

PR: https://github.com/llvm/llvm-project/pull/123196

show more ...


# b7697580 16-Jan-2025 Florian Hahn <flo@fhahn.com>

[Options] Use UseDerefAtPointSemantics cl::opt<bool>. (#123192)

It is used as boolean option, use cl::opt<bool> instead of
vl::opt<unsigned>.

PR: https://github.com/llvm/llvm-project/pull/123192


Revision tags: llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init
# ebab1056 04-Jul-2024 Nikita Popov <npopov@redhat.com>

[IR] Don't strip through pointer to vector of pointer bitcasts

When using stripPointerCasts() and getUnderlyingObject(), don't
strip through a bitcast from ptr to <1 x ptr>, which is not a
no-op poi

[IR] Don't strip through pointer to vector of pointer bitcasts

When using stripPointerCasts() and getUnderlyingObject(), don't
strip through a bitcast from ptr to <1 x ptr>, which is not a
no-op pointer cast. Calling code is generally not prepared to
handle that situation, resulting in incorrect alias analysis
results for example.

Fixes https://github.com/llvm/llvm-project/issues/97600.

show more ...


Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3
# 75dfa58e 20-Mar-2024 Stephen Tozer <stephen.tozer@sony.com>

[RemoveDIs][NFC] Rename DPMarker->DbgMarker (#85931)

Another trivial rename patch, the last big one for now, which renamed
DPMarkers to DbgMarkers. This required the field `DbgMarker` in
`Instruct

[RemoveDIs][NFC] Rename DPMarker->DbgMarker (#85931)

Another trivial rename patch, the last big one for now, which renamed
DPMarkers to DbgMarkers. This required the field `DbgMarker` in
`Instruction` to be renamed to `DebugMarker` to avoid a clash, but
otherwise was a simple string substitution of `s/DPMarker/DbgMarker` and
a manual renaming of `DPM` to `DM` in the few places where that acronym
was used for debug markers.

show more ...


Revision tags: llvmorg-18.1.2
# ffd08c77 19-Mar-2024 Stephen Tozer <stephen.tozer@sony.com>

[RemoveDIs][NFC] Rename DPValue -> DbgVariableRecord (#85216)

This is the major rename patch that prior patches have built towards.
The DPValue class is being renamed to DbgVariableRecord, which re

[RemoveDIs][NFC] Rename DPValue -> DbgVariableRecord (#85216)

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.

show more ...


Revision tags: llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init
# 21a77e8a 14-Dec-2023 Reid Kleckner <rnk@google.com>

[IR] Reorder Value fields to put the SubclassID first (#53520)

Placing the class id at offset 0 should make `isa` and `dyn_cast` faster
by eliminating the field offset (previously 0x10) from the mem

[IR] Reorder Value fields to put the SubclassID first (#53520)

Placing the class id at offset 0 should make `isa` and `dyn_cast` faster
by eliminating the field offset (previously 0x10) from the memory
operand, saving encoding space on x86, and, in theory, an add micro-op.
You can see the load encodes one byte smaller here:
https://godbolt.org/z/Whvz4can9

The compile time tracker shows some modestly positive results in the
on the `cycle` metric and in the final clang binary size metric:
https://llvm-compile-time-tracker.com/compare.php?from=33b54f01fe32030ff60d661a7a951e33360f82ee&to=2530347a57401744293c54f92f9781fbdae3d8c2&stat=cycles
Clicking through to the per-library size breakdown shows that
instcombine size reduces by 0.68%, which is meaningful, and I believe
instcombine is known to be a hotspot.

It is, however, potentially noise. I still think we should do this,
because notionally, the class id really acts as the vptr of the Value,
and conventionally the vptr is always at offset 0.

show more ...


# 7954c571 04-Jan-2024 Jannik Silvanus <37809848+jasilvanus@users.noreply.github.com>

[IR] Fix GEP offset computations for vector GEPs (#75448)

Vectors are always bit-packed and don't respect the elements' alignment
requirements. This is different from arrays. This means offsets of

[IR] Fix GEP offset computations for vector GEPs (#75448)

Vectors are always bit-packed and don't respect the elements' alignment
requirements. This is different from arrays. This means offsets of
vector GEPs need to be computed differently than offsets of array GEPs.

This PR fixes many places that rely on an incorrect pattern
that always relies on `DL.getTypeAllocSize(GTI.getIndexedType())`.
We replace these by usages of `GTI.getSequentialElementStride(DL)`,
which is a new helper function added in this PR.

This changes behavior for GEPs into vectors with element types for which
the (bit) size and alloc size is different. This includes two cases:

* Types with a bit size that is not a multiple of a byte, e.g. i1.
GEPs into such vectors are questionable to begin with, as some elements
are not even addressable.
* Overaligned types, e.g. i16 with 32-bit alignment.

Existing tests are unaffected, but a miscompilation of a new test is fixed.

---------

Co-authored-by: Nikita Popov <github@npopov.com>

show more ...


Revision tags: llvmorg-17.0.6
# 510fb871 22-Nov-2023 Nikita Popov <npopov@redhat.com>

[IR][TLI] Cache getLibFunc() result on Function (NFC) (#72867)

Cache the result of the TLI libfunc lookup in the Function object. This
only caches the actual lookup of the LibFunc in the TLI map, b

[IR][TLI] Cache getLibFunc() result on Function (NFC) (#72867)

Cache the result of the TLI libfunc lookup in the Function object. This
only caches the actual lookup of the LibFunc in the TLI map, but not the
prototype validation, as that might differ between different TLI
instances.

This uses the existing mechanism for invalidating the intrinsic ID when
the function name changes. The libfunc will be invalidated in that case
as well.

I don't believe this increases the size of Function on 64bit (which
currently has a trailing `bool` member), and I don't think we would
particularly care if it did, as Functions are uncommon as Values go.

show more ...


Revision tags: llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6
# 4259198d 07-Jun-2023 Jeremy Morse <jeremy.morse@sony.com>

[DebugInfo][RemoveDIs] Support finding DPValues like dbg.values (#71952)

This patch extends findDbgValue and friends to optionally fill out a vector
of DPValue pointers, containing DPValues that ref

[DebugInfo][RemoveDIs] Support finding DPValues like dbg.values (#71952)

This patch extends findDbgValue and friends to optionally fill out a vector
of DPValue pointers, containing DPValues that refer to the sought Value.
This will allow us to incrementally add instrumentation to other
optimisation passes one-at-a-time, while un-instrumented passes will not
(yet) update DPValues.

Unit tests to check this behaves in the same way as dbg.values.

show more ...


# 5b83bd13 19-Oct-2023 Kazu Hirata <kazu@google.com>

[llvm] Use StringRef::contains (NFC)


Revision tags: llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3
# ca10e73b 19-Apr-2023 OCHyams <orlando.hyams@sony.com>

[NFC] Rename isPointerOffset to getPointerOffsetFrom and move to Value.h

Linking LLVMCore failed when building D148536 with shared libs enabled:
https://lab.llvm.org/buildbot/#/builders/121/builds/2

[NFC] Rename isPointerOffset to getPointerOffsetFrom and move to Value.h

Linking LLVMCore failed when building D148536 with shared libs enabled:
https://lab.llvm.org/buildbot/#/builders/121/builds/29766

Make isPointerOffset a Value method and rename it to getPointerOffsetFrom.

Reviewed By: jmorse

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

show more ...


Revision tags: llvmorg-16.0.2, llvmorg-16.0.1
# c53d8073 31-Mar-2023 Yevgeny Rouban <yrouban@azul.com>

[IR] Allow destruction of symbol table entries regardless of DiscardValueNames

Value::setNameImpl() is used both to set and reset name of the value.
In destructor of Function all arguments get reset

[IR] Allow destruction of symbol table entries regardless of DiscardValueNames

Value::setNameImpl() is used both to set and reset name of the value.
In destructor of Function all arguments get reset their names
(see Function::clearArguments()). If the arguments had their names set (e.g.
when the function was created with LLVMContex::DiscardValueNames == true)
then their ValueName entries referred by the function's symbol table must be
destructed. They are not destructed if LLVMContex::DiscardValueNames is set to
false because of the fast path in Value::setNameImpl(). See the new test cases
that demonstrate the problem. Without the fix they both crash in the function's
destructor.

In Value::setNameImpl() this patch narrows down the fast path return for
DiscardValueNames == true to allow destruction of ValueName entries if any.

Reviewed By: efriedma

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

show more ...


Revision tags: llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3
# a28b252d 20-Feb-2023 Kazu Hirata <kazu@google.com>

Use APInt::getSignificantBits instead of APInt::getMinSignedBits (NFC)

Note that getMinSignedBits has been soft-deprecated in favor of
getSignificantBits.


# f8f3db27 20-Feb-2023 Kazu Hirata <kazu@google.com>

Use APInt::count{l,r}_{zero,one} (NFC)


Revision tags: llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7
# 8fd5558b 11-Jan-2023 Guillaume Chatelet <gchatelet@google.com>

[NFC] Use TypeSize::geFixedValue() instead of TypeSize::getFixedSize()

This change is one of a series to implement the discussion from
https://reviews.llvm.org/D141134.


# 48f5d77e 11-Jan-2023 Guillaume Chatelet <gchatelet@google.com>

[NFC] Use TypeSize::getKnownMinValue() instead of TypeSize::getKnownMinSize()

This change is one of a series to implement the discussion from
https://reviews.llvm.org/D141134.


# 3284adf6 25-Dec-2022 Alexey Lapshin <a.v.lapshin@mail.ru>

[NFC][ADT] Rename StringMapEntry *Create() into StringMapEntry *create.


# ca23b7ca 02-Dec-2022 Fangrui Song <i@maskray.me>

[AsmPrinter] .addrsig_sym: remove isTransitiveUsedByMetadataOnly

With D135642 ignoring unregistered symbols, isTransitiveUsedByMetadataOnly added
by D101512 is no longer needed (the operation is pot

[AsmPrinter] .addrsig_sym: remove isTransitiveUsedByMetadataOnly

With D135642 ignoring unregistered symbols, isTransitiveUsedByMetadataOnly added
by D101512 is no longer needed (the operation is potentially slow). There is a
`.addrsig_sym` directive for an only-used-by-metadata symbol but it does not
emit an entry.

Reviewed By: rnk

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

show more ...


Revision tags: llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4
# a97eab7d 27-Oct-2022 Dmitry Sidorov <dmitry.sidorov@intel.com>

[IR] Allow typed pointers to be used in vector types

Reviewed By: nikic, jcranmer-intel

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


Revision tags: llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2
# de9d80c1 08-Aug-2022 Fangrui Song <i@maskray.me>

[llvm] LLVM_FALLTHROUGH => [[fallthrough]]. NFC

With C++17 there is no Clang pedantic warning or MSVC C5051.


# 2138c906 04-Aug-2022 Joshua Cranmer <joshua.cranmer@intel.com>

[IR] Move support for dxil::TypedPointerType to LLVM core IR.

This allows the construct to be shared between different backends. However, it
still remains illegal to use TypedPointerType in LLVM IR-

[IR] Move support for dxil::TypedPointerType to LLVM core IR.

This allows the construct to be shared between different backends. However, it
still remains illegal to use TypedPointerType in LLVM IR--the type is intended
to remain an auxiliary type, not a real LLVM type. So no support is provided for
LLVM-C, nor bitcode, nor LLVM assembly (besides the bare minimum needed to make
Type->dump() work properly).

Reviewed By: beanz, nikic, aeubanks

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

show more ...


Revision tags: llvmorg-15.0.0-rc1, llvmorg-16-init
# 643e022c 30-Jun-2022 Fraser Cormack <fraser@codeplay.com>

[IR] Fix typo in comment. NFC


Revision tags: llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1
# 982247dc 11-Apr-2022 Fangrui Song <i@maskray.me>

Value::isTransitiveUsedByMetadataOnly: Don't repeatedly add an element to the worklist. NFC


Revision tags: llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3
# ed98c1b3 09-Mar-2022 serge-sans-paille <sguelton@redhat.com>

Cleanup includes: DebugInfo & CodeGen

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D121332


# a9b03d9e 03-Mar-2022 Nikita Popov <npopov@redhat.com>

[Attributor] Remove function pointer restriction for AAAlign

This check is not compatible with opaque pointers. We can avoid
it by adjusting the getPointerAlignment() implementation to avoid
creatin

[Attributor] Remove function pointer restriction for AAAlign

This check is not compatible with opaque pointers. We can avoid
it by adjusting the getPointerAlignment() implementation to avoid
creating unnecessary ptrtoint expressions for bitcasted pointers.
The code already uses OnlyIfReduced to not create an expression
if it does not simplify, and this makes sure that folding a
bitcast and ptrtoint into a ptrtoint doesn't count as a
simplification.

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

show more ...


123456789