CodeGen: Refactor MIR parsing

When parsing .mir files immediately construct the MachineFunctions and
put them into MachineModuleInfo.

This allows us to get rid of the delayed construction (and dela

CodeGen: Refactor MIR parsing

When parsing .mir files immediately construct the MachineFunctions and
put them into MachineModuleInfo.

This allows us to get rid of the delayed construction (and delayed error
reporting) through the MachineFunctionInitialzier interface.

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

llvm-svn: 304758

show more ...

[CodeGen] Fix some Clang-tidy modernize-use-using and Include What You Use warnings; other minor fixes (NFC).

llvm-svn: 304265

[LegacyPassManager] Remove TargetMachine constructors

This provides a new way to access the TargetMachine through
TargetPassConfig, as a dependency.

The patterns replaced here are:

* Passes handli

[LegacyPassManager] Remove TargetMachine constructors

This provides a new way to access the TargetMachine through
TargetPassConfig, as a dependency.

The patterns replaced here are:

* Passes handling a null TargetMachine call
`getAnalysisIfAvailable<TargetPassConfig>`.

* Passes not handling a null TargetMachine
`addRequired<TargetPassConfig>` and call
`getAnalysis<TargetPassConfig>`.

* MachineFunctionPasses now use MF.getTarget().

* Remove all the TargetMachine constructors.
* Remove INITIALIZE_TM_PASS.

This fixes a crash when running `llc -start-before prologepilog`.

PEI needs StackProtector, which gets constructed without a TargetMachine
by the pass manager. The StackProtector pass doesn't handle the case
where there is no TargetMachine, so it segfaults.

Related to PR30324.

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

llvm-svn: 303360

show more ...

Implement FreeMachineFunction::getPassName().

llvm-svn: 297222

Move most EH from MachineModuleInfo to MachineFunction

Recommitting r288293 with some extra fixes for GlobalISel code.

Most of the exception handling members in MachineModuleInfo is actually
per fu

Move most EH from MachineModuleInfo to MachineFunction

Recommitting r288293 with some extra fixes for GlobalISel code.

Most of the exception handling members in MachineModuleInfo is actually
per function data (talks about the "current function") so it is better
to keep it at the function instead of the module.

This is a necessary step to have machine module passes work properly.

Also:
- Rename TidyLandingPads() to tidyLandingPads()
- Use doxygen member groups instead of "//===- EH ---"... so it is clear
where a group ends.
- I had to add an ugly const_cast at two places in the AsmPrinter
because the available MachineFunction pointers are const, but the code
wants to call tidyLandingPads() in between
(markFunctionEnd()/endFunction()).

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

llvm-svn: 288405

show more ...

Temporarily Revert "Move most EH from MachineModuleInfo to MachineFunction"

This apprears to have broken the global isel bot:
http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-globalisel_buil

Temporarily Revert "Move most EH from MachineModuleInfo to MachineFunction"

This apprears to have broken the global isel bot:
http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-globalisel_build/5174/console

This reverts commit r288293.

llvm-svn: 288322

show more ...

Move most EH from MachineModuleInfo to MachineFunction

Most of the exception handling members in MachineModuleInfo is actually
per function data (talks about the "current function") so it is better

Move most EH from MachineModuleInfo to MachineFunction

Most of the exception handling members in MachineModuleInfo is actually
per function data (talks about the "current function") so it is better
to keep it at the function instead of the module.

This is a necessary step to have machine module passes work properly.

Also:
- Rename TidyLandingPads() to tidyLandingPads()
- Use doxygen member groups instead of "//===- EH ---"... so it is clear
where a group ends.
- I had to add an ugly const_cast at two places in the AsmPrinter
because the available MachineFunction pointers are const, but the code
wants to call tidyLandingPads() in between
(markFunctionEnd()/endFunction()).

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

llvm-svn: 288293

show more ...

Move VariableDbgInfo from MachineModuleInfo to MachineFunction

VariableDbgInfo is per function data, so it makes sense to have it with
the function instead of the module.

This is a necessary step t

Move VariableDbgInfo from MachineModuleInfo to MachineFunction

VariableDbgInfo is per function data, so it makes sense to have it with
the function instead of the module.

This is a necessary step to have machine module passes work properly.

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

llvm-svn: 288292

show more ...

Move FrameInstructions from MachineModuleInfo to MachineFunction

This is per function data so it is better kept at the function instead
of the module.

This is a necessary step to have machine modul

Move FrameInstructions from MachineModuleInfo to MachineFunction

This is per function data so it is better kept at the function instead
of the module.

This is a necessary step to have machine module passes work properly.

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

llvm-svn: 288291

show more ...

[CodeGen] Pass references, not pointers, to MMI helpers. NFC.

While there, rename them to follow the coding style.

llvm-svn: 287169

[CodeGen] Pull MMI helpers from FunctionLoweringInfo to MMI. NFC.

They're not SelectionDAG- or FunctionLoweringInfo-specific. They
are, however, specific to building MMI from IR.
We could make them

[CodeGen] Pull MMI helpers from FunctionLoweringInfo to MMI. NFC.

They're not SelectionDAG- or FunctionLoweringInfo-specific. They
are, however, specific to building MMI from IR.
We could make them members, but it's nice having MMI be a "simple" data
structure and this logic kept separate.

This also lets us reuse them from GlobalISel.

llvm-svn: 287167

show more ...

[CodeGen] Cleanup MachineModuleInfo doxygen comments. NFC.

Remove redundant names and only keep header comments.

llvm-svn: 287166

CodeGen: Remove MachineFunctionAnalysis => Enable (Machine)ModulePasses

Re-apply this patch, hopefully I will get away without any warnings
in the constructor now.

This patch removes the MachineFun

CodeGen: Remove MachineFunctionAnalysis => Enable (Machine)ModulePasses

Re-apply this patch, hopefully I will get away without any warnings
in the constructor now.

This patch removes the MachineFunctionAnalysis. Instead we keep a
map from IR Function to MachineFunction in the MachineModuleInfo.

This allows the insertion of ModulePasses into the codegen pipeline
without breaking it because the MachineFunctionAnalysis gets dropped
before a module pass.

Peak memory should stay unchanged without a ModulePass in the codegen
pipeline: Previously the MachineFunction was freed at the end of a codegen
function pipeline because the MachineFunctionAnalysis was dropped; With
this patch the MachineFunction is freed after the AsmPrinter has
finished.

Differential Revision: http://reviews.llvm.org/D23736

llvm-svn: 279602

show more ...

MachineModuleInfo: Avoid dummy constructor, use INITIALIZE_TM_PASS

Change this pass constructor to just accept a const TargetMachine * and
use INITIALIZE_TM_PASS, that way we can get rid of the dumm

MachineModuleInfo: Avoid dummy constructor, use INITIALIZE_TM_PASS

Change this pass constructor to just accept a const TargetMachine * and
use INITIALIZE_TM_PASS, that way we can get rid of the dummy
constructor. The pass will still fail when calling the default
constructor leading to TM == nullptr, this is no different than before
but is more in line what other codegen passes are doing and avoids the
dummy constructor.

llvm-svn: 279598

show more ...

Revert r279564. It introduces undefined behavior (binding a reference to a
dereferenced null pointer) in MachineModuleInfo::MachineModuleInfo that causes
-Werror builds (including several buildbots)

Revert r279564. It introduces undefined behavior (binding a reference to a
dereferenced null pointer) in MachineModuleInfo::MachineModuleInfo that causes
-Werror builds (including several buildbots) to fail.

llvm-svn: 279580

show more ...

CodeGen: Remove MachineFunctionAnalysis => Enable (Machine)ModulePasses

Re-apply this commit with the deletion of a MachineFunction delegated to
a separate pass to avoid use after free when doing th

CodeGen: Remove MachineFunctionAnalysis => Enable (Machine)ModulePasses

Re-apply this commit with the deletion of a MachineFunction delegated to
a separate pass to avoid use after free when doing this directly in
AsmPrinter.

This patch removes the MachineFunctionAnalysis. Instead we keep a
map from IR Function to MachineFunction in the MachineModuleInfo.

This allows the insertion of ModulePasses into the codegen pipeline
without breaking it because the MachineFunctionAnalysis gets dropped
before a module pass.

Peak memory should stay unchanged without a ModulePass in the codegen
pipeline: Previously the MachineFunction was freed at the end of a codegen
function pipeline because the MachineFunctionAnalysis was dropped; With
this patch the MachineFunction is freed after the AsmPrinter has
finished.

Differential Revision: http://reviews.llvm.org/D23736

llvm-svn: 279564

show more ...

Revert "(HEAD -> master, origin/master, origin/HEAD) CodeGen: Remove MachineFunctionAnalysis => Enable (Machine)ModulePasses"

Reverting while tracking down a use after free.

This reverts commit r27

Revert "(HEAD -> master, origin/master, origin/HEAD) CodeGen: Remove MachineFunctionAnalysis => Enable (Machine)ModulePasses"

Reverting while tracking down a use after free.

This reverts commit r279502.

llvm-svn: 279503

show more ...

CodeGen: Remove MachineFunctionAnalysis => Enable (Machine)ModulePasses

This patch removes the MachineFunctionAnalysis. Instead we keep a
map from IR Function to MachineFunction in the MachineModule

CodeGen: Remove MachineFunctionAnalysis => Enable (Machine)ModulePasses

This patch removes the MachineFunctionAnalysis. Instead we keep a
map from IR Function to MachineFunction in the MachineModuleInfo.

This allows the insertion of ModulePasses into the codegen pipeline
without breaking it because the MachineFunctionAnalysis gets dropped
before a module pass.

Peak memory should stay unchanged without a ModulePass in the codegen
pipeline: Previously the MachineFunction was freed at the end of a codegen
function pipeline because the MachineFunctionAnalysis was dropped; With
this patch the MachineFunction is freed after the AsmPrinter has
finished.

Differential Revision: http://reviews.llvm.org/D23736

llvm-svn: 279502

show more ...

Remove uses of builtin comma operator.

Cleanup for upcoming Clang warning -Wcomma. No functionality change intended.

llvm-svn: 261270

Move EH-specific helper functions to a more appropriate place

No functionality change is intended.

llvm-svn: 254562

[WinEH] Move WinEHFuncInfo from MachineModuleInfo to MachineFunction

Summary:
Now that there is a one-to-one mapping from MachineFunction to
WinEHFuncInfo, we don't need to use a DenseMap to select

[WinEH] Move WinEHFuncInfo from MachineModuleInfo to MachineFunction

Summary:
Now that there is a one-to-one mapping from MachineFunction to
WinEHFuncInfo, we don't need to use a DenseMap to select the right
WinEHFuncInfo for the current funclet.

The main challenge here is that X86WinEHStatePass is an IR pass that
doesn't have access to the MachineFunction. I gave it its own
WinEHFuncInfo object that it uses to calculate state numbers, which it
then throws away. As long as nobody creates or removes EH pads between
this pass and SDAG construction, we will get the same state numbers.

The other thing X86WinEHStatePass does is to mark the EH registration
node. Instead of communicating which alloca was the registration through
WinEHFuncInfo, I added the llvm.x86.seh.ehregnode intrinsic. This
intrinsic generates no code and simply marks the alloca in use.

Reviewers: JCTremoulet

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D14668

llvm-svn: 253378

show more ...

[WinEH] Remove more dead code

wineh-parent is dead, so is ValueOrMBB.

llvm-svn: 249920

[EH] Handle non-Function personalities like unknown personalities

Also delete and simplify a lot of MachineModuleInfo code that used to be
needed to handle personalities on landingpads. Now that th

[EH] Handle non-Function personalities like unknown personalities

Also delete and simplify a lot of MachineModuleInfo code that used to be
needed to handle personalities on landingpads. Now that the personality
is on the LLVM Function, we no longer need to track it this way on MMI.
Certainly it should not live on LandingPadInfo.

llvm-svn: 246478

show more ...

[WinEH] Add some support for code generating catchpad

We can now run 32-bit programs with empty catch bodies. The next step
is to change PEI so that we get funclet prologues and epilogues.

llvm-sv

[WinEH] Add some support for code generating catchpad

We can now run 32-bit programs with empty catch bodies. The next step
is to change PEI so that we get funclet prologues and epilogues.

llvm-svn: 246235

show more ...

-Wdeprecated-clean: Fix cases of violating the rule of 5 in ways that are deprecated in C++11

Various value handles needed to be copy constructible and copy
assignable (mostly for their use in Dense

-Wdeprecated-clean: Fix cases of violating the rule of 5 in ways that are deprecated in C++11

Various value handles needed to be copy constructible and copy
assignable (mostly for their use in DenseMap). But to avoid an API that
might allow accidental slicing, make these members protected in the base
class and make derived classes final (the special members become
implicitly public there - but disallowing further derived classes that
might be sliced to the intermediate type).

Might be worth having a warning a bit like -Wnon-virtual-dtor that
catches public move/copy assign/ctors in classes with virtual functions.
(suppressable in the same way - by making them protected in the base,
and making the derived classes final) Could be fancier and only diagnose
them when they're actually called, potentially.

Also allow a few default implementations where custom implementations
(especially with non-standard return types) were implemented.

llvm-svn: 243909

show more ...