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 ...
|