Move TargetRegistry.(h|cpp) from Support to MC

This moves the registry higher in the LLVM library dependency stack.
Every client of the target registry needs to link against MC anyway to
actually us

Move TargetRegistry.(h|cpp) from Support to MC

This moves the registry higher in the LLVM library dependency stack.
Every client of the target registry needs to link against MC anyway to
actually use the target, so we might as well move this out of Support.

This allows us to ensure that Support doesn't have includes from MC/*.

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

show more ...

[MachineInstr] Move MIParser's DBG_VALUE RegState::Debug invariant into MachineInstr::addOperand

Based on the reasoning of D53903, register operands of DBG_VALUE are
invariably treated as RegState::

[MachineInstr] Move MIParser's DBG_VALUE RegState::Debug invariant into MachineInstr::addOperand

Based on the reasoning of D53903, register operands of DBG_VALUE are
invariably treated as RegState::Debug operands. This change enforces
this invariant as part of MachineInstr::addOperand so that all passes
emit this flag consistently.

RegState::Debug is inconsistently set on DBG_VALUE registers throughout
LLVM. This runs the risk of a filtering iterator like
MachineRegisterInfo::reg_nodbg_iterator to process these operands
erroneously when not parsed from MIR sources.

This issue was observed in the development of the llvm-mos fork which
adds a backend that relies on physical register operands much more than
existing targets. Physical RegUnit 0 has the same numeric encoding as
$noreg (indicating an undef for DBG_VALUE). Allowing debug operands into
the machine scheduler correlates $noreg with RegUnit 0 (i.e. a collision
of register numbers with different zero semantics). Eventually, this
causes an assert where DBG_VALUE instructions are prohibited from
participating in live register ranges.

Reviewed By: MatzeB, StephenTozer

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

show more ...

[MC] Refactor MCObjectFileInfo initialization and allow targets to create MCObjectFileInfo

This makes it possible for targets to define their own MCObjectFileInfo.
This MCObjectFileInfo is then used

[MC] Refactor MCObjectFileInfo initialization and allow targets to create MCObjectFileInfo

This makes it possible for targets to define their own MCObjectFileInfo.
This MCObjectFileInfo is then used to determine things like section alignment.

This is a follow up to D101462 and prepares for the RISCV backend defining the
text section alignment depending on the enabled extensions.

Reviewed By: MaskRay

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

show more ...

[MC] Untangle MCContext and MCObjectFileInfo

This untangles the MCContext and the MCObjectFileInfo. There is a circular
dependency between MCContext and MCObjectFileInfo. Currently this dependency
a

[MC] Untangle MCContext and MCObjectFileInfo

This untangles the MCContext and the MCObjectFileInfo. There is a circular
dependency between MCContext and MCObjectFileInfo. Currently this dependency
also exists during construction: You can't contruct a MOFI without a MCContext
without constructing the MCContext with a dummy version of that MOFI first.
This removes this dependency during construction. In a perfect world,
MCObjectFileInfo wouldn't depend on MCContext at all, but only be stored in the
MCContext, like other MC information. This is future work.

This also shifts/adds more information to the MCContext making it more
available to the different targets. Namely:

- TargetTriple
- ObjectFileType
- SubtargetInfo

Reviewed By: MaskRay

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

show more ...

Switch from llvm::is_trivially_copyable to std::is_trivially_copyable

GCC<5 did not support std::is_trivially_copyable. Now LLVM builds require 5.1
we can migrate to std::is_trivially_copyable.

The

Switch from llvm::is_trivially_copyable to std::is_trivially_copyable

GCC<5 did not support std::is_trivially_copyable. Now LLVM builds require 5.1
we can migrate to std::is_trivially_copyable.

The Optional.h change made MSVC choke
(https://buildkite.com/llvm-project/premerge-checks/builds/18587#cd1bb616-ffdc-4581-9795-b42c284196de)
so I leave it out for now.

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

show more ...

Revert "Use std::is_trivially_copyable", breaks MSVC build

Revert "Delete llvm::is_trivially_copyable and CMake variable HAVE_STD_IS_TRIVIALLY_COPYABLE"

This reverts commit 4d4bd40b578d77b8c5bc349d

Revert "Use std::is_trivially_copyable", breaks MSVC build

Revert "Delete llvm::is_trivially_copyable and CMake variable HAVE_STD_IS_TRIVIALLY_COPYABLE"

This reverts commit 4d4bd40b578d77b8c5bc349ded405fb58c333c78.

This reverts commit 557b00e0afb2dc1776f50948094ca8cc62d97be4.

show more ...

Use std::is_trivially_copyable

GCC<5 did not support std::is_trivially_copyable. Now LLVM builds require 5.1
we can migrate to std::is_trivially_copyable.

unittest: Disable MachineInstrClone.CopyCallSiteInfo entirely

Somehow, details about the host architecture are creeping into the bogus
target set up in MFCommon.inc, causing call site info to be dis

unittest: Disable MachineInstrClone.CopyCallSiteInfo entirely

Somehow, details about the host architecture are creeping into the bogus
target set up in MFCommon.inc, causing call site info to be disabled:

http://lab.llvm.org:8011/builders/lld-x86_64-win7/builds/41476
http://lab.llvm.org:8011/builders/clang-s390x-linux-lnt/builds/17987

Disable the test to unblock the bots until I can figure this out.

show more ...

unittest: Disable MachineInstrClone.CopyCallSiteInfo on Windows

A bot error (http://45.33.8.238/win/12463/step_11.txt) reports 'unknown
file: error: SEH exception with code 0x3221225477 thrown in th

unittest: Disable MachineInstrClone.CopyCallSiteInfo on Windows

A bot error (http://45.33.8.238/win/12463/step_11.txt) reports 'unknown
file: error: SEH exception with code 0x3221225477 thrown in the test
body', but I don't know what causes this.

It looks like this has come up before, but afaict the root causes could
be different:

https://reviews.llvm.org/rL329195, and in
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20180910/587425.html

I tried testing locally with UBSan, but that didn't uncover anything.

show more ...

MachineFunction: Copy call site info when duplicating insts

Summary:
Preserve call site info for duplicated instructions. We copy over the
call site info in CloneMachineInstrBundle to avoid repeated

MachineFunction: Copy call site info when duplicating insts

Summary:
Preserve call site info for duplicated instructions. We copy over the
call site info in CloneMachineInstrBundle to avoid repeated calls to
copyCallSiteInfo in CloneMachineInstr.

(Alternatively, we could copy call site info higher up the stack, e.g.
into TargetInstrInfo::duplicate, or even into individual backend passes.
However, I don't see how that would be safer or more general than the
current approach.)

Reviewers: aprantl, djtodoro, dstenb

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

show more ...

[Alignment][NFC] Use Align version of getMachineMemOperand

Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llv

[Alignment][NFC] Use Align version of getMachineMemOperand

Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790

Reviewers: courbet

Subscribers: jyknight, sdardis, nemanjai, hiraditya, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, jfb, PkmX, jocewei, Jim, lenary, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, llvm-commits

Tags: #llvm

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

show more ...

[MC] Move deprecation infos from MCTargetDesc to MCInstrInfo

This allows emitting it only when the feature is used by a target.
Shrinks Release+Asserts clang by 900k.

[DebugInfo] Re-implement LexicalScopes dominance method, add unit tests

Way back in D24994, the combination of LexicalScopes::dominates and
LiveDebugValues was identified as having worst-case quadra

[DebugInfo] Re-implement LexicalScopes dominance method, add unit tests

Way back in D24994, the combination of LexicalScopes::dominates and
LiveDebugValues was identified as having worst-case quadratic complexity,
but it wasn't triggered by any code path at the time. I've since run into a
scenario where this occurs, in a very large basic block where large numbers
of inlined DBG_VALUEs are present.

The quadratic-ness comes from LiveDebugValues::join calling "dominates" on
every variable location, and LexicalScopes::dominates potentially touching
every instruction in a block to test for the presence of a scope. We have,
however, already computed the presence of scopes in blocks, in the
"InstrRanges" of each scope. This patch switches the dominates method to
examine whether a block is present in a scope's InsnRanges, avoiding
walking through the whole block.

At the same time, fix getMachineBasicBlocks to account for the fact that
InsnRanges can cover multiple blocks, and add some unit tests, as Lexical
Scopes didn't have any.

Differential revision: https://reviews.llvm.org/D73725

show more ...

Fix initialization-order-fiasco error in "Add a heap alloc site marker field to the ExtraInfo in MachineInstrs"

Recommit "Add a heap alloc site marker field to the ExtraInfo in MachineInstrs"

Summary:
Fixes some things from original commit at https://reviews.llvm.org/D69136. The main
change is that the heap a

Recommit "Add a heap alloc site marker field to the ExtraInfo in MachineInstrs"

Summary:
Fixes some things from original commit at https://reviews.llvm.org/D69136. The main
change is that the heap alloc marker is always stored as ExtraInfo in the machine
instruction instead of in the PointerSumType because it cannot hold more than
4 pointer types.

Add instruction marker to MachineInstr ExtraInfo. This does almost the
same thing as Pre/PostInstrSymbols, except that it doesn't create a label until
printing instructions. This allows for labels to be put around instructions that
are deleted/duplicated somewhere.
Use this marker to track heap alloc site call instructions.

Reviewers: rnk

Subscribers: MatzeB, hiraditya, llvm-commits

Tags: #llvm

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

show more ...

Revert "Add an instruction marker field to the ExtraInfo in MachineInstrs."

Reverting commit b85b4e5a6f8579c137fecb59a4d75d7bfb111f79 due to some
buildbot failures/ out of memory errors.

Add an instruction marker field to the ExtraInfo in MachineInstrs.

Summary:
Add instruction marker to MachineInstr ExtraInfo. This does almost the
same thing as Pre/PostInstrSymbols, except that it

Add an instruction marker field to the ExtraInfo in MachineInstrs.

Summary:
Add instruction marker to MachineInstr ExtraInfo. This does almost the
same thing as Pre/PostInstrSymbols, except that it doesn't create a label until
printing instructions. This allows for labels to be put around instructions that
are deleted/duplicated somewhere.

Also undo the workaround in r375137.

Reviewers: rnk

Subscribers: MatzeB, hiraditya, llvm-commits

Tags: #llvm

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

show more ...

[Alignment][NFC] Use Align for TargetFrameLowering/Subtarget

Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/l

[Alignment][NFC] Use Align for TargetFrameLowering/Subtarget

Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790

Reviewers: courbet

Subscribers: jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, hiraditya, aheejin, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, jsji, Jim, lenary, s.egerton, pzheng, llvm-commits

Tags: #llvm

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

llvm-svn: 375084

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

[unittest] Add the missing bogus machine register info initialization.

llvm-svn: 365529

[unittest] Add bogus register info.

Reviewers: dstenb

Subscribers: llvm-commits

Tags: #llvm

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

llvm-svn: 365516

[CodeGen] Enhance `MachineInstrSpan` to allow the end of MBB to be used.

Summary:
- Explicitly specify the parent MBB to allow the end iterator to be
used.

Reviewers: aprantl, MatzeB, craig.toppe

[CodeGen] Enhance `MachineInstrSpan` to allow the end of MBB to be used.

Summary:
- Explicitly specify the parent MBB to allow the end iterator to be
used.

Reviewers: aprantl, MatzeB, craig.topper, qcolombet

Subscribers: arsenm, jvesely, nhaehnle, hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 365240

show more ...

[X86] Fix several places that weren't passing what they though they were to MachineInstr::print

Over a year ago, MachineInstr gained a fourth boolean parameter that occurs
before the TII pointer. Wh

[X86] Fix several places that weren't passing what they though they were to MachineInstr::print

Over a year ago, MachineInstr gained a fourth boolean parameter that occurs
before the TII pointer. When this happened, several places started accidentally
passing TII into this boolean parameter instead of the TII parameter.

llvm-svn: 362312

show more ...

[Subtarget] Merge ProcSched and ProcDesc arrays in MCSubtargetInfo into a single array.

These arrays are both keyed by CPU name and go into the same tablegenerated file. Merge them so we only need t

[Subtarget] Merge ProcSched and ProcDesc arrays in MCSubtargetInfo into a single array.

These arrays are both keyed by CPU name and go into the same tablegenerated file. Merge them so we only need to store keys once.

This also removes a weird space saving quirk where we used the ProcDesc.size() to create to build an ArrayRef for ProcSched.

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

llvm-svn: 355431

show more ...

Replace llvm::isPodLike<...> by llvm::is_trivially_copyable<...>

As noted in https://bugs.llvm.org/show_bug.cgi?id=36651, the specialization for
isPodLike<std::pair<...>> did not match the expectat

Replace llvm::isPodLike<...> by llvm::is_trivially_copyable<...>

As noted in https://bugs.llvm.org/show_bug.cgi?id=36651, the specialization for
isPodLike<std::pair<...>> did not match the expectation of
std::is_trivially_copyable which makes the memcpy optimization invalid.

This patch renames the llvm::isPodLike trait into llvm::is_trivially_copyable.
Unfortunately std::is_trivially_copyable is not portable across compiler / STL
versions. So a portable version is provided too.

Note that the following specialization were invalid:

std::pair<T0, T1>
llvm::Optional<T>

Tests have been added to assert that former specialization are respected by the
standard usage of llvm::is_trivially_copyable, and that when a decent version
of std::is_trivially_copyable is available, llvm::is_trivially_copyable is
compared to std::is_trivially_copyable.

As of this patch, llvm::Optional is no longer considered trivially copyable,
even if T is. This is to be fixed in a later patch, as it has impact on a
long-running bug (see r347004)

Note that GCC warns about this UB, but this got silented by https://reviews.llvm.org/D50296.

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

llvm-svn: 351701

show more ...