[DebugInfo] Map VAM args to `poison` instead of `undef` [NFC] (#122756)

If an argument cannot be mapped in `Mapper::mapValue`, it can be mapped
to `poison` instead of `undef`.

[unittests] Use {} instead of std::nullopt to initialize empty ArrayRef (#109388)

Follow up to #109133.

[IR] Disallow ZeroInit for spirv.Image (#73887)

According to spirv spec, OpConstantNull's result type can't be image
type. So we can't generate zeroinitializer for spirv.Image.

[llvm] Drop some bitcasts and references related to typed pointers

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

[ValueMapper] allow mapping ConstantTargetNone to its layout type

zeroinitializer is allowed for spirv TargetExtType.
This PR allows ValueMapper to map TargetExtType ConstantTargetNone to '0' consta

[ValueMapper] allow mapping ConstantTargetNone to its layout type

zeroinitializer is allowed for spirv TargetExtType.
This PR allows ValueMapper to map TargetExtType ConstantTargetNone to '0' constant of its layout type.

Reviewed By: jcranmer-intel

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

show more ...

[ValueMapper] Preserve poison types during value mapping

Poison needs to be treated directly during type remap otherwise
it will be considered an instance of undef.

Reviewed By: dexonsmith

Differe

[ValueMapper] Preserve poison types during value mapping

Poison needs to be treated directly during type remap otherwise
it will be considered an instance of undef.

Reviewed By: dexonsmith

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

show more ...

[llvm/unittests] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the am

[llvm/unittests] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...

[DebugInfo] ValueMapper impl for DIArgList respects IgnoreMissingLocals

This patch fixes an issue in which SSA value reference within a
DIArgList would be unnecessarily dropped by llvm-link, even wh

[DebugInfo] ValueMapper impl for DIArgList respects IgnoreMissingLocals

This patch fixes an issue in which SSA value reference within a
DIArgList would be unnecessarily dropped by llvm-link, even when
invoking on a single file (which should be a no-op). The reason for the
difference is that the ValueMapper does not refer to the
RF_IgnoreMissingLocals flag for LocalAsMetadata contained within a
DIArgList; this flag is used for direct LocalAsMetadata uses to preserve
SSA references even when the ValueMapper does not have an explicit
mapping for the referenced SSA value, which appears to always be the
case when using llvm-link in this manner.

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

show more ...

ValueMapper: Rename RF_MoveDistinctMDs => RF_ReuseAndMutateDistinctMDs, NFC

Rename the `RF_MoveDistinctMDs` flag passed into `MapValue` and
`MapMetadata` to `RF_ReuseAndMutateDistinctMDs` in order t

ValueMapper: Rename RF_MoveDistinctMDs => RF_ReuseAndMutateDistinctMDs, NFC

Rename the `RF_MoveDistinctMDs` flag passed into `MapValue` and
`MapMetadata` to `RF_ReuseAndMutateDistinctMDs` in order to more
precisely describe its effect and clarify the header documentation.

Found this while helping to investigate PR48841, which pointed out an
unsound use of the flag in `CloneModule()`. For now I've just added a
FIXME there, but I'm hopeful that the new (more precise) name will
prevent other similar errors.

show more ...

[llvm] Migrate llvm::make_unique to std::make_unique

Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of

[llvm] Migrate llvm::make_unique to std::make_unique

Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.

llvm-svn: 369013

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

Re-sort #include lines for unittests. This uses a slightly modified
clang-format (https://reviews.llvm.org/D33932) to keep primary headers
at the top and handle new utility headers like 'gmock' consi

Re-sort #include lines for unittests. This uses a slightly modified
clang-format (https://reviews.llvm.org/D33932) to keep primary headers
at the top and handle new utility headers like 'gmock' consistently with
other utility headers.

No other change was made. I did no manual edits, all of this is
clang-format.

This should allow other changes to have more clear and focused diffs,
and is especially motivated by moving some headers into more focused
libraries.

llvm-svn: 304786

show more ...

ValueMapper: Stop memoizing ConstantAsMetadata

Stop memoizing ConstantAsMetadata in ValueMapper::mapMetadata. Now we
have to recompute it, but these metadata aren't particularly common, and
it rest

ValueMapper: Stop memoizing ConstantAsMetadata

Stop memoizing ConstantAsMetadata in ValueMapper::mapMetadata. Now we
have to recompute it, but these metadata aren't particularly common, and
it restricts the lifetime of the Metadata map unnecessarily.

(The motivation is that I have a patch which uses a single Metadata map
for the lifetime of IRMover. Mehdi profiled r266446 with the patch
applied and we saw a pretty big speedup in lib/Linker.)

llvm-svn: 266513

show more ...

Reapply "ValueMapper: Eliminate cross-file co-recursion, NFC"

This reverts commit r266507, reapplying r266503 (and r266505
"ValueMapper: Use API from r266503 in unit tests, NFC") completely
unchange

Reapply "ValueMapper: Eliminate cross-file co-recursion, NFC"

This reverts commit r266507, reapplying r266503 (and r266505
"ValueMapper: Use API from r266503 in unit tests, NFC") completely
unchanged.

I reverted because of a bot failure here:
http://lab.llvm.org:8011/builders/lld-x86_64-freebsd/builds/16810/

However, looking more closely, the failure was from a host-compiler
crash (clang 3.7.1) when building:
lib/CodeGen/AsmPrinter/CMakeFiles/LLVMAsmPrinter.dir/DwarfAccelTable.cpp.o

I didn't modify that file, or anything it includes, with that commit.

The next build (which hadn't picked up my revert) got past it:
http://lab.llvm.org:8011/builders/lld-x86_64-freebsd/builds/16811/

I think this was just unfortunate timing. I suppose the bot must be
flakey.

llvm-svn: 266510

show more ...

Revert "ValueMapper: Eliminate cross-file co-recursion, NFC"

This reverts commit r266503, in case it's the root cause of this bot
failure:

http://lab.llvm.org:8011/builders/lld-x86_64-freebsd/bui

Revert "ValueMapper: Eliminate cross-file co-recursion, NFC"

This reverts commit r266503, in case it's the root cause of this bot
failure:

http://lab.llvm.org:8011/builders/lld-x86_64-freebsd/builds/16810

I'm also reverting r266505 -- "ValueMapper: Use API from r266503 in unit
tests, NFC" -- since it's in the way.

llvm-svn: 266507

show more ...

ValueMapper: Use API from r266503 in unit tests, NFC

I'm not in a hurry to migrate all the users, but the unit tests at least
should use the new API.

llvm-svn: 266505

ValueMapper: Resolve cycles on the new nodes

Fix a major bug from r265456. Although it's now much rarer, ValueMapper
sometimes has to duplicate cycles. The
might-transitively-reference-a-temporary

ValueMapper: Resolve cycles on the new nodes

Fix a major bug from r265456. Although it's now much rarer, ValueMapper
sometimes has to duplicate cycles. The
might-transitively-reference-a-temporary counts don't decrement on their
own when there are cycles, and you need to call MDNode::resolveCycles to
fix it.

r265456 was checking the input nodes to see if they were unresolved.
This is useless; they should never be unresolved. Instead we should
check the output nodes and resolve cycles on them.

llvm-svn: 266258

show more ...

ValueMapper: Don't memoize metadata when RF_NoModuleLevelChanges

Prevent the Metadata side-table in ValueMap from growing unnecessarily
when RF_NoModuleLevelChanges. As a drive-by, make ValueMap::h

ValueMapper: Don't memoize metadata when RF_NoModuleLevelChanges

Prevent the Metadata side-table in ValueMap from growing unnecessarily
when RF_NoModuleLevelChanges. As a drive-by, make ValueMap::hasMD,
which apparently had no users until I used it here for testing, actually
compile.

llvm-svn: 265828

show more ...

ValueMapper: Stop memoizing MDStrings

Stop adding MDString to the Metadata section of the ValueMap in
MapMetadata. It blows up the size of the map for no benefit, since we
can always return quickly

ValueMapper: Stop memoizing MDStrings

Stop adding MDString to the Metadata section of the ValueMap in
MapMetadata. It blows up the size of the map for no benefit, since we
can always return quickly anyway.

There is a potential follow-up that I don't think I'll push on right
away, but maybe someone else is interested: stop checking for a
pre-mapped MDString, and move the `isa<MDString>()` checks in
Mapper::mapSimpleMetadata and MDNodeMapper::getMappedOp in front of the
`VM.getMappedMD()` calls. While this would preclude explicitly
remapping MDStrings it would probably be a little faster.

llvm-svn: 265827

show more ...

Reapply "ValueMapper: Treat LocalAsMetadata more like function-local Values"

This reverts commit r265765, reapplying r265759 after changing a call from
LocalAsMetadata::get to ValueAsMetadata::get (

Reapply "ValueMapper: Treat LocalAsMetadata more like function-local Values"

This reverts commit r265765, reapplying r265759 after changing a call from
LocalAsMetadata::get to ValueAsMetadata::get (and adding a unit test). When a
local value is mapped to a constant (like "i32 %a" => "i32 7"), the new debug
intrinsic operand may no longer be pointing at a local.

http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA_build/19020/

The previous coommit message follows:

--

This is a partial re-commit -- maybe more of a re-implementation -- of
r265631 (reverted in r265637).

This makes RF_IgnoreMissingLocals behave (almost) consistently between
the Value and the Metadata hierarchy. In particular:

- MapValue returns nullptr or "metadata !{}" for missing locals in
MetadataAsValue/LocalAsMetadata bridging paris, depending on
the RF_IgnoreMissingLocals flag.

- MapValue doesn't memoize LocalAsMetadata-related results.

- MapMetadata no longer deals with LocalAsMetadata or
RF_IgnoreMissingLocals at all. (This wasn't in r265631 at all, but
I realized during testing it would make the patch simpler with no
loss of generality.)

r265631 went too far, making both functions universally ignore
RF_IgnoreMissingLocals. This broke building (e.g.) compiler-rt.
Reassociate (and possibly other passes) don't currently maintain
dominates-use invariants for metadata operands, resulting in IR like
this:

define void @foo(i32 %arg) {
call void @llvm.some.intrinsic(metadata i32 %x)
%x = add i32 1, i32 %arg
}

If the inliner chooses to inline @foo into another function, then
RemapInstruction will call `MapValue(metadata i32 %x)` and assert that
the return is not nullptr.

I've filed PR27273 to add a Verifier check and fix the underlying
problem in the optimization passes.

As a workaround, return `!{}` instead of nullptr for unmapped
LocalAsMetadata when RF_IgnoreMissingLocals is unset. Otherwise, match
the behaviour of r265631.

Original commit message:

ValueMapper: Make LocalAsMetadata match function-local Values

Start treating LocalAsMetadata similarly to function-local members of
the Value hierarchy in MapValue and MapMetadata.

- Don't memoize them.
- Return nullptr if they are missing.

This also cleans up ConstantAsMetadata to stop listening to the
RF_IgnoreMissingLocals flag.

llvm-svn: 265768

show more ...

Revert "ValueMapper: Treat LocalAsMetadata more like function-local Values"

This reverts commit r265759, since even this limited version breaks some
bots:
http://lab.llvm.org:8011/builders/clang-p

Revert "ValueMapper: Treat LocalAsMetadata more like function-local Values"

This reverts commit r265759, since even this limited version breaks some
bots:
http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/3311
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-autoconf/builds/17696

This also reverts r265761 "ValueMapper: Unduplicate
RF_NoModuleLevelChanges check, NFC", since I had trouble separating it
from r265759.

llvm-svn: 265765

show more ...

ValueMapper: Treat LocalAsMetadata more like function-local Values

This is a partial re-commit -- maybe more of a re-implementation -- of
r265631 (reverted in r265637).

This makes RF_IgnoreMissingL

ValueMapper: Treat LocalAsMetadata more like function-local Values

This is a partial re-commit -- maybe more of a re-implementation -- of
r265631 (reverted in r265637).

This makes RF_IgnoreMissingLocals behave (almost) consistently between
the Value and the Metadata hierarchy. In particular:

- MapValue returns nullptr or "metadata !{}" for missing locals in
MetadataAsValue/LocalAsMetadata bridging paris, depending on
the RF_IgnoreMissingLocals flag.

- MapValue doesn't memoize LocalAsMetadata-related results.

- MapMetadata no longer deals with LocalAsMetadata or
RF_IgnoreMissingLocals at all. (This wasn't in r265631 at all, but
I realized during testing it would make the patch simpler with no
loss of generality.)

r265631 went too far, making both functions universally ignore
RF_IgnoreMissingLocals. This broke building (e.g.) compiler-rt.
Reassociate (and possibly other passes) don't currently maintain
dominates-use invariants for metadata operands, resulting in IR like
this:

define void @foo(i32 %arg) {
call void @llvm.some.intrinsic(metadata i32 %x)
%x = add i32 1, i32 %arg
}

If the inliner chooses to inline @foo into another function, then
RemapInstruction will call `MapValue(metadata i32 %x)` and assert that
the return is not nullptr.

I've filed PR27273 to add a Verifier check and fix the underlying
problem in the optimization passes.

As a workaround, return `!{}` instead of nullptr for unmapped
LocalAsMetadata when RF_IgnoreMissingLocals is unset. Otherwise, match
the behaviour of r265631.

Original commit message:

ValueMapper: Make LocalAsMetadata match function-local Values

Start treating LocalAsMetadata similarly to function-local members of
the Value hierarchy in MapValue and MapMetadata.

- Don't memoize them.
- Return nullptr if they are missing.

This also cleans up ConstantAsMetadata to stop listening to the
RF_IgnoreMissingLocals flag.

llvm-svn: 265759

show more ...

Revert "ValueMapper: Make LocalAsMetadata match function-local Values"

This reverts commit r265631, since it caused bot failures:
http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/3256
ht

Revert "ValueMapper: Make LocalAsMetadata match function-local Values"

This reverts commit r265631, since it caused bot failures:
http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/3256
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-42vma/builds/7272

Looks like something is depending on the old behaviour. I'll try to
track it down and recommit.

llvm-svn: 265637

show more ...

ValueMapper: Allow RF_IgnoreMissingLocals and RF_NullMapMissingGlobalValues

Remove the assertion that disallowed the combination, since
RF_IgnoreMissingLocals should have no effect on globals. As i

ValueMapper: Allow RF_IgnoreMissingLocals and RF_NullMapMissingGlobalValues

Remove the assertion that disallowed the combination, since
RF_IgnoreMissingLocals should have no effect on globals. As it happens,
RF_NullMapMissingGlobalValues asserted in MapValue(Constant*,...), so I
also changed a cast to a cast_or_null to get my test passing.

llvm-svn: 265633

show more ...

ValueMapper: Make LocalAsMetadata match function-local Values

Start treating LocalAsMetadata similarly to function-local members of
the Value hierarchy in MapValue and MapMetadata.

- Don't memoiz

ValueMapper: Make LocalAsMetadata match function-local Values

Start treating LocalAsMetadata similarly to function-local members of
the Value hierarchy in MapValue and MapMetadata.

- Don't memoize them.
- Return nullptr if they are missing.

This also cleans up ConstantAsMetadata to stop listening to the
RF_IgnoreMissingLocals flag.

llvm-svn: 265631

show more ...