|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, 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, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, 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, llvmorg-17.0.6, 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, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init |
|
| #
90e5a8ac |
| 13-Jul-2022 |
Mitch Phillips <[email protected]> |
Remove 'no_sanitize_memtag'. Add 'sanitize_memtag'.
For MTE globals, we should have clang emit the attribute for all GV's that it creates, and then use that in the upcoming AArch64 global tagging IR
Remove 'no_sanitize_memtag'. Add 'sanitize_memtag'.
For MTE globals, we should have clang emit the attribute for all GV's that it creates, and then use that in the upcoming AArch64 global tagging IR pass. We need a positive attribute for this sanitizer (rather than implicit sanitization of all globals) because it needs to interact with other parts of LLVM, including:
1. Suppressing certain global optimisations (like merging), 2. Emitting extra directives by the ASM writer, and 3. Putting extra information in the symbol table entries.
While this does technically make the LLVM IR / bitcode format non-backwards-compatible, nobody should have used this attribute yet, because it's a no-op.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D128950
show more ...
|
| #
26f36939 |
| 07-Jul-2022 |
Denis Antrushin <[email protected]> |
[IR][OpaquePointers] Properly print cmpxchg with pointer operands.
With opaque pointers address of pointer variable and its value have same type (`ptr`). As a result, cmpxchg is printed without valu
[IR][OpaquePointers] Properly print cmpxchg with pointer operands.
With opaque pointers address of pointer variable and its value have same type (`ptr`). As a result, cmpxchg is printed without values types in LLVM assembly and cannot be read back. Add AtomicCmpXchg to the list of instructions which always have operand types printed.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D129276
show more ...
|
| #
7283f48a |
| 28-Jun-2022 |
Nikita Popov <[email protected]> |
[IR] Remove support for insertvalue constant expression
This removes the insertvalue constant expression, as part of https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179. This is
[IR] Remove support for insertvalue constant expression
This removes the insertvalue constant expression, as part of https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179. This is very similar to the extractvalue removal from D125795. insertvalue is also not supported in bitcode, so no auto-ugprade is necessary.
ConstantExpr::getInsertValue() can be replaced with IRBuilder::CreateInsertValue() or ConstantFoldInsertValueInstruction(), depending on whether a constant result is required (with the latter being fallible).
The ConstantExpr::hasIndices() and ConstantExpr::getIndices() methods also go away here, because there are no longer any constant expressions with indices.
Differential Revision: https://reviews.llvm.org/D128719
show more ...
|
|
Revision tags: llvmorg-14.0.6 |
|
| #
129b531c |
| 19-Jun-2022 |
Kazu Hirata <[email protected]> |
[llvm] Use value_or instead of getValueOr (NFC)
|
| #
b254d671 |
| 18-Jun-2022 |
Kazu Hirata <[email protected]> |
[llvm] Call *set::insert without checking membership first (NFC)
|
| #
8db981d4 |
| 10-Jun-2022 |
Mitch Phillips <[email protected]> |
Add sanitizer-specific GlobalValue attributes.
Plan is the migrate the global variable metadata for sanitizers, that's currently carried around generally in the 'llvm.asan.globals' section, onto the
Add sanitizer-specific GlobalValue attributes.
Plan is the migrate the global variable metadata for sanitizers, that's currently carried around generally in the 'llvm.asan.globals' section, onto the global variable itself.
This patch adds the attribute and plumbs it through the LLVM IR and bitcode formats, but is a no-op other than that so far.
Reviewed By: vitalybuka, kstoimenov
Differential Revision: https://reviews.llvm.org/D126100
show more ...
|
|
Revision tags: llvmorg-14.0.5 |
|
| #
e0039b8d |
| 05-Jun-2022 |
Kazu Hirata <[email protected]> |
Use llvm::less_second (NFC)
|
|
Revision tags: llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2 |
|
| #
e6f44a3c |
| 14-Apr-2022 |
Chris Bieneman <[email protected]> |
Add PointerType analysis for DirectX backend
As implemented this patch assumes that Typed pointer support remains in the llvm::PointerType class, however this could be modified to use a different su
Add PointerType analysis for DirectX backend
As implemented this patch assumes that Typed pointer support remains in the llvm::PointerType class, however this could be modified to use a different subclass of llvm::Type that could be disallowed from use in other contexts.
This does not rely on inserting typed pointers into the Module, it just uses the llvm::PointerType class to track and unique types.
Fixes #54918
Reviewed By: kuhar
Differential Revision: https://reviews.llvm.org/D122268
show more ...
|
|
Revision tags: llvmorg-14.0.1 |
|
| #
eab6e94f |
| 06-Apr-2022 |
Chih-Ping Chen <[email protected]> |
[DebugInfo] Add a TargetFuncName field in DISubprogram for specifying DW_AT_trampoline as a string. Also update the signature of DIBuilder::createFunction to reflect this addition.
Differential Revi
[DebugInfo] Add a TargetFuncName field in DISubprogram for specifying DW_AT_trampoline as a string. Also update the signature of DIBuilder::createFunction to reflect this addition.
Differential Revision: https://reviews.llvm.org/D123697
show more ...
|
|
Revision tags: llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1 |
|
| #
3a3cb929 |
| 07-Feb-2022 |
Kazu Hirata <[email protected]> |
[llvm] Use = default (NFC)
|
|
Revision tags: llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3 |
|
| #
28bfa57a |
| 18-Jan-2022 |
Chih-Ping Chen <[email protected]> |
[DebugInfo] Add stringLocationExp field to DIStringType
DIStringType is used to encode the debug info of a character object in Fortran. A Fortran deferred-length character object is typically implem
[DebugInfo] Add stringLocationExp field to DIStringType
DIStringType is used to encode the debug info of a character object in Fortran. A Fortran deferred-length character object is typically implemented as a pair of the following two pieces of info: An address of the raw storage of the characters, and the length of the object. The stringLocationExp field contains the DIExpression to get to the raw storage.
This patch also enables the emission of DW_AT_data_location attribute in a DW_TAG_string_type debug info entry based on stringLocationExp in DIStringType.
A test is also added to ensure that the bitcode reader is backward compatible with the old DIStringType format.
Differential Revision: https://reviews.llvm.org/D117586
show more ...
|
| #
aa97bc11 |
| 21-Jan-2022 |
Nikita Popov <[email protected]> |
[NFC] Remove uses of PointerType::getElementType()
Instead use either Type::getPointerElementType() or Type::getNonOpaquePointerElementType().
This is part of D117885, in preparation for deprecatin
[NFC] Remove uses of PointerType::getElementType()
Instead use either Type::getPointerElementType() or Type::getNonOpaquePointerElementType().
This is part of D117885, in preparation for deprecating the API.
show more ...
|
|
Revision tags: llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2 |
|
| #
5dc8aaac |
| 10-Aug-2021 |
Sami Tolvanen <[email protected]> |
[llvm][IR] Add no_cfi constant
With Control-Flow Integrity (CFI), the LowerTypeTests pass replaces function references with CFI jump table references, which is a problem for low-level code that need
[llvm][IR] Add no_cfi constant
With Control-Flow Integrity (CFI), the LowerTypeTests pass replaces function references with CFI jump table references, which is a problem for low-level code that needs the address of the actual function body.
For example, in the Linux kernel, the code that sets up interrupt handlers needs to take the address of the interrupt handler function instead of the CFI jump table, as the jump table may not even be mapped into memory when an interrupt is triggered.
This change adds the no_cfi constant type, which wraps function references in a value that LowerTypeTestsModule::replaceCfiUses does not replace.
Link: https://github.com/ClangBuiltLinux/linux/issues/1353
Reviewed By: nickdesaulniers, pcc
Differential Revision: https://reviews.llvm.org/D108478
show more ...
|
| #
1172712f |
| 08-Dec-2021 |
Arthur Eubanks <[email protected]> |
[NFC] Replace some deprecated getAlignment() calls with getAlign()
Reviewed By: gchatelet
Differential Revision: https://reviews.llvm.org/D115370
|
| #
c23ebf17 |
| 09-Dec-2021 |
Kazu Hirata <[email protected]> |
[llvm] Use range-based for loops (NFC)
|
| #
262dd1e4 |
| 02-Dec-2021 |
Kazu Hirata <[email protected]> |
[llvm] Use range-based for loops (NFC)
|
| #
99107401 |
| 03-Nov-2021 |
Rosie Sumpter <[email protected]> |
[LoopVectorize] Propagate fast-math flags for VPInstruction
In-loop vector reductions which use the llvm.fmuladd intrinsic involve the creation of two recipes; a VPReductionRecipe for the fadd and a
[LoopVectorize] Propagate fast-math flags for VPInstruction
In-loop vector reductions which use the llvm.fmuladd intrinsic involve the creation of two recipes; a VPReductionRecipe for the fadd and a VPInstruction for the fmul. If the call to llvm.fmuladd has fast-math flags these should be propagated through to the fmul instruction, so an interface setFastMathFlags has been added to the VPInstruction class to enable this.
Differential Revision: https://reviews.llvm.org/D113125
show more ...
|
| #
7ca14f60 |
| 18-Nov-2021 |
Kazu Hirata <[email protected]> |
[llvm] Use range-based for loops (NFC)
|
| #
05963a3d |
| 09-Nov-2021 |
Arthur Eubanks <[email protected]> |
Revert "[DebugInfo] Enforce implicit constraints on `distinct` MDNodes"
This reverts commit ee7652569854af567ba83e5255d70e80cc8619a1.
Causes crashes, see comments in D104827.
|
| #
ee765256 |
| 04-Nov-2021 |
Scott Linder <[email protected]> |
[DebugInfo] Enforce implicit constraints on `distinct` MDNodes
Add UNIQUED and DISTINCT properties in Metadata.def and use them to implement restrictions on the `distinct` property of MDNodes:
* DI
[DebugInfo] Enforce implicit constraints on `distinct` MDNodes
Add UNIQUED and DISTINCT properties in Metadata.def and use them to implement restrictions on the `distinct` property of MDNodes:
* DIExpression can currently be parsed from IR or read from bitcode as `distinct`, but this property is silently dropped when printing to IR. This causes accepted IR to fail to round-trip. As DIExpression appears inline at each use in the canonical form of IR, it cannot actually be `distinct` anyway, as there is no syntax to describe it. * Similarly, DIArgList is conceptually always uniqued. It is currently restricted to only appearing in contexts where there is no syntax for `distinct`, but for consistency it is treated equivalently to DIExpression in this patch. * DICompileUnit is already restricted to always being `distinct`, but along with adding general support for the inverse restriction I went ahead and described this in Metadata.def and updated the parser to be general. Future nodes which have this restriction can share this support.
The new UNIQUED property applies to DIExpression and DIArgList, and forbids them to be `distinct`. It also implies they are canonically printed inline at each use, rather than via MDNode ID.
The new DISTINCT property applies to DICompileUnit, and requires it to be `distinct`.
A potential alternative change is to forbid the non-inline syntax for DIExpression entirely, as is done with DIArgList implicitly by requiring it appear in the context of a function. For example, we would forbid:
!named = !{!0} !0 = !DIExpression()
Instead we would only accept the equivalent inlined version:
!named = !{!DIExpression()}
This essentially removes the ability to create a `distinct` DIExpression by construction, as there is no syntax for `distinct` inline. If this patch is accepted as-is, the result would be that the non-canonical version is accepted, but the following would be an error and produce a diagnostic:
!named = !{!0} ; error: 'distinct' not allowed for !DIExpression() !0 = distinct !DIExpression()
Also update some documentation to consistently use the inline syntax for DIExpression, and to describe the restrictions on `distinct` for nodes where applicable.
Reviewed By: StephenTozer, t-tye
Differential Revision: https://reviews.llvm.org/D104827
show more ...
|
| #
08ed2160 |
| 20-Oct-2021 |
Itay Bookstein <[email protected]> |
[IR] Refactor GlobalIFunc to inherit from GlobalObject, Remove GlobalIndirectSymbol
As discussed in: * https://reviews.llvm.org/D94166 * https://lists.llvm.org/pipermail/llvm-dev/2020-September/1450
[IR] Refactor GlobalIFunc to inherit from GlobalObject, Remove GlobalIndirectSymbol
As discussed in: * https://reviews.llvm.org/D94166 * https://lists.llvm.org/pipermail/llvm-dev/2020-September/145031.html
The GlobalIndirectSymbol class lost most of its meaning in https://reviews.llvm.org/D109792, which disambiguated getBaseObject (now getAliaseeObject) between GlobalIFunc and everything else. In addition, as long as GlobalIFunc is not a GlobalObject and getAliaseeObject returns GlobalObjects, a GlobalAlias whose aliasee is a GlobalIFunc cannot currently be modeled properly. Creating aliases for GlobalIFuncs does happen in the wild (e.g. glibc). In addition, calling getAliaseeObject on a GlobalIFunc will currently return nullptr, which is undesirable because it should return the object itself for non-aliases.
This patch refactors the GlobalIFunc class to inherit directly from GlobalObject, and removes GlobalIndirectSymbol (while inlining the relevant parts into GlobalAlias and GlobalIFunc). This allows for calling getAliaseeObject() on a GlobalIFunc to return the GlobalIFunc itself, making getAliaseeObject() more consistent and enabling alias-to-ifunc to be properly modeled in the IR.
I exercised some judgement in the API clients of GlobalIndirectSymbol: some were 'monomorphized' for GlobalAlias and GlobalIFunc, and some remained shared (with the type adapted to become GlobalValue).
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D108872
show more ...
|
| #
e6e29831 |
| 04-Oct-2021 |
Kazu Hirata <[email protected]> |
[IR] Migrate from getNumArgOperands to arg_size (NFC)
Note that arg_operands is considered a legacy name. See llvm/include/llvm/IR/InstrTypes.h for details.
|
| #
a9bceb2b |
| 30-Sep-2021 |
Jay Foad <[email protected]> |
[APInt] Stop using soft-deprecated constructors and methods in llvm. NFC.
Stop using APInt constructors and methods that were soft-deprecated in D109483. This fixes all the uses I found in llvm, exc
[APInt] Stop using soft-deprecated constructors and methods in llvm. NFC.
Stop using APInt constructors and methods that were soft-deprecated in D109483. This fixes all the uses I found in llvm, except for the APInt unit tests which should still test the deprecated methods.
Differential Revision: https://reviews.llvm.org/D110807
show more ...
|
| #
475de8da |
| 12-Sep-2021 |
Min-Yih Hsu <[email protected]> |
[IR]PATCH 2/2: Add MDNode::printTree and dumpTree
This patch adds the functionalities to print MDNode in tree shape. For example, instead of printing a MDNode like this: ``` <0x5643e1166888> = !DILo
[IR]PATCH 2/2: Add MDNode::printTree and dumpTree
This patch adds the functionalities to print MDNode in tree shape. For example, instead of printing a MDNode like this: ``` <0x5643e1166888> = !DILocalVariable(name: "foo", arg: 2, scope: <0x5643e11c9740>, file: <0x5643e11c6ec0>, line: 8, type: <0x5643e11ca8e0>, flags: DIFlagPublic | DIFlagFwdDecl, align: 8) ``` The printTree/dumpTree functions can give you: ``` <0x5643e1166888> = !DILocalVariable(name: "foo", arg: 2, scope: <0x5643e11c9740>, file: <0x5643e11c6ec0>, line: 8, type: <0x5643e11ca8e0>, flags: DIFlagPublic | DIFlagFwdDecl, align: 8) <0x5643e11c9740> = distinct !DISubprogram(scope: null, spFlags: 0) <0x5643e11c6ec0> = distinct !DIFile(filename: "file.c", directory: "/path/to/dir") <0x5643e11ca8e0> = distinct !DIDerivedType(tag: DW_TAG_pointer_type, baseType: <0x5643e11668d8>, size: 1, align: 2) <0x5643e11668d8> = !DIBasicType(tag: DW_TAG_unspecified_type, name: "basictype") ``` Which is useful when using it in debugger. Where sometimes printing the whole module to see all MDNodes is too expensive.
Differential Revision: https://reviews.llvm.org/D110113
show more ...
|
| #
b2d078fb |
| 12-Sep-2021 |
Min-Yih Hsu <[email protected]> |
[IR]PATCH 1/2: Add AsmWriterContext into AsmWriter
AsmWriterContext is a simple compound that stores TypePrinting, SlotTracker (i.e. "Machine" in AsmWriter), and Module instances -- three of the mos
[IR]PATCH 1/2: Add AsmWriterContext into AsmWriter
AsmWriterContext is a simple compound that stores TypePrinting, SlotTracker (i.e. "Machine" in AsmWriter), and Module instances -- three of the most commonly used objects in the AsmWriter infrastructure. Previously these three objects are passed as separate function arguments to most of the printer functions in this file. Tidying them up can bring easier code refactoring on printer functions in the future (e.g. when we want to pass additional objects to all printer functions).
NOTE: Theoritically, this patch should be NFC.
Differential Revision: https://reviews.llvm.org/D110112
show more ...
|