[MachineOuliner][NFC] Refactoring code to make outline rerunning a cleaner diff.

I want to add the ability to rerun the outliner in certain cases, and I
thought this could be an NFC change that coul

[MachineOuliner][NFC] Refactoring code to make outline rerunning a cleaner diff.

I want to add the ability to rerun the outliner in certain cases, and I
thought this could be an NFC change that could make a subsequent change
that allows for rerunning the outliner a cleaner diff.

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

show more ...

[DebugInfo][If-Converter] Update call site info during the optimization

During the If-Converter optimization pay attention when copying or
deleting call instructions in order to keep call site infor

[DebugInfo][If-Converter] Update call site info during the optimization

During the If-Converter optimization pay attention when copying or
deleting call instructions in order to keep call site information in
valid state.

Reviewers: aprantl, vsk, efriedma

Reviewed By: vsk, efriedma

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

llvm-svn: 374068

show more ...

[MachineOutliner] Disable outlining from noreturn functions

Outlining from noreturn functions doesn't do the correct thing right now. The
outliner should respect that the caller is marked noreturn.

[MachineOutliner] Disable outlining from noreturn functions

Outlining from noreturn functions doesn't do the correct thing right now. The
outliner should respect that the caller is marked noreturn. In the event that
we have a noreturn function, and the outlined code is in tail position, the
outliner will not see that the outlined function should be tail called. As a
result, you end up with a regular call containing a return.

Fixing this requires that we check that all candidates live inside noreturn
functions. So, for the sake of correctness, don't outline from noreturn
functions right now.

Add machine-outliner-noreturn.mir to test this.

llvm-svn: 373791

show more ...

[NewPM] Port MachineModuleInfo to the new pass manager.

Existing clients are converted to use MachineModuleInfoWrapperPass. The
new interface is for defining a new pass manager API in CodeGen.

Revi

[NewPM] Port MachineModuleInfo to the new pass manager.

Existing clients are converted to use MachineModuleInfoWrapperPass. The
new interface is for defining a new pass manager API in CodeGen.

Reviewers: fedor.sergeev, philip.pfaffe, chandlerc, arsenm

Reviewed By: arsenm, fedor.sergeev

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

llvm-svn: 373240

show more ...

[Backend] Keep call site info valid through the backend

Handle call instruction replacements and deletions in order to preserve
valid state of the call site info of the MachineFunction.

NOTE: If th

[Backend] Keep call site info valid through the backend

Handle call instruction replacements and deletions in order to preserve
valid state of the call site info of the MachineFunction.

NOTE: If the call site info is enabled for a new target, the assertion from
the MachineFunction::DeleteMachineInstr() should help to locate places
where the updateCallSiteInfo() should be called in order to preserve valid
state of the call site info.

([10/13] Introduce the debug entry values.)

Co-authored-by: Ananth Sowda <asowda@cisco.com>
Co-authored-by: Nikola Prica <nikola.prica@rt-rk.com>
Co-authored-by: Ivan Baev <ibaev@cisco.com>

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

llvm-svn: 364536

show more ...

Use llvm::stable_sort

While touching the code, simplify if feasible.

llvm-svn: 358996

[MachineOutliner] Replace ostringstream based string concatenation with Twine

This makes my libLLVMCodeGen.so.9svn 4936 bytes smaller.

While here, delete unused #include <map>

llvm-svn: 358089

[opaque pointer types] Add a FunctionCallee wrapper type, and use it.

Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc
doesn't choke on it, hopefully.

Original Message:
The Func

[opaque pointer types] Add a FunctionCallee wrapper type, and use it.

Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc
doesn't choke on it, hopefully.

Original Message:
The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.

Then:
- update the CallInst/InvokeInst instruction creation functions to
take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.

One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.

However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)

Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.

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

llvm-svn: 352827

show more ...

Revert "[opaque pointer types] Add a FunctionCallee wrapper type, and use it."

This reverts commit f47d6b38c7a61d50db4566b02719de05492dcef1 (r352791).

Seems to run into compilation failures with GC

Revert "[opaque pointer types] Add a FunctionCallee wrapper type, and use it."

This reverts commit f47d6b38c7a61d50db4566b02719de05492dcef1 (r352791).

Seems to run into compilation failures with GCC (but not clang, where
I tested it). Reverting while I investigate.

llvm-svn: 352800

show more ...

[opaque pointer types] Add a FunctionCallee wrapper type, and use it.

The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue pas

[opaque pointer types] Add a FunctionCallee wrapper type, and use it.

The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.

Then:
- update the CallInst/InvokeInst instruction creation functions to
take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.

One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.

However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)

Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.

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

llvm-svn: 352791

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

Fix Wdocumentation warning. NFCI.

llvm-svn: 348517

[MachineOutliner][NFC] Move yet another std::vector out of a loop

Once again, following the wisdom of the LLVM Programmer's Manual.

I think that's enough refactoring for today. :)

llvm-svn: 348439

[MachineOutliner][NFC] Move std::vector out of loop

See http://llvm.org/docs/ProgrammersManual.html#vector

llvm-svn: 348433

[MachineOutliner][NFC] Remove IntegerInstructionMap from InstructionMapper

Refactoring.

This map was only used when we used a string of integers to output the outlined
sequence. Since it's no longe

[MachineOutliner][NFC] Remove IntegerInstructionMap from InstructionMapper

Refactoring.

This map was only used when we used a string of integers to output the outlined
sequence. Since it's no longer used for anything, there's no reason to keep it
around.

llvm-svn: 348432

show more ...

[MachineOutliner][NFC] Remove buildCandidateList and replace with findCandidates

More refactoring.

Since the pruning logic has changed, and the candidate list is gone,
everything can be sunk into f

[MachineOutliner][NFC] Remove buildCandidateList and replace with findCandidates

More refactoring.

Since the pruning logic has changed, and the candidate list is gone,
everything can be sunk into findCandidates.

We no longer need to keep track of the length of the longest substring, so we
can drop all of that logic as well.

After this, we just find all of the candidates and move to outlining.

llvm-svn: 348428

show more ...

[MachineOutliner][NFC] Candidates don't need to be shared_ptrs anymore

More refactoring.

After the changes to the pruning logic, and removing CandidateList, there's
no reason for Candiates to be sh

[MachineOutliner][NFC] Candidates don't need to be shared_ptrs anymore

More refactoring.

After the changes to the pruning logic, and removing CandidateList, there's
no reason for Candiates to be shared_ptrs (or pointers at all).

std::shared_ptr<Candidate> -> Candidate.

llvm-svn: 348427

show more ...

[MachineOutliner][NFC] Remove CandidateList, since it's now unused.

After removing the pruning logic, there's no reason to populate a list of
Candidates. Remove CandidateList and update comments.

l

[MachineOutliner][NFC] Remove CandidateList, since it's now unused.

After removing the pruning logic, there's no reason to populate a list of
Candidates. Remove CandidateList and update comments.

llvm-svn: 348422

show more ...

Fix buildbot capture warning

A bot didn't like my lambda. This ought to fix it.

Example:

http://lab.llvm.org:8011/builders/lld-x86_64-win7/builds/30139/steps/build%20lld/logs/stdio

error C3493: '

Fix buildbot capture warning

A bot didn't like my lambda. This ought to fix it.

Example:

http://lab.llvm.org:8011/builders/lld-x86_64-win7/builds/30139/steps/build%20lld/logs/stdio

error C3493: 'AlreadyRemoved' cannot be implicitly captured because no default
capture mode has been specified

llvm-svn: 348421

show more ...

[MachineOutliner][NFC] Simplify and unify pruning/outlining logic

Since we're now performing outlining per OutlinedFunction rather than per
Candidate, we can simply outline each candidate as it show

[MachineOutliner][NFC] Simplify and unify pruning/outlining logic

Since we're now performing outlining per OutlinedFunction rather than per
Candidate, we can simply outline each candidate as it shows up.

Instead of having a pruning phase, instead, we'll outline entire functions.
Then we'll update the UnsignedVec we mapped to reflect the deletion. If any
candidate is in a space that's marked dirty, then we'll drop it.

This lets us remove the pruning logic entirely, and greatly simplifies the
code.

llvm-svn: 348420

show more ...

[MachineOutliner] Outline functions by order of benefit

Mostly NFC, only change is the order of outlined function names.

Loop over the outlined functions instead of walking the candidate list.

Thi

[MachineOutliner] Outline functions by order of benefit

Mostly NFC, only change is the order of outlined function names.

Loop over the outlined functions instead of walking the candidate list.

This is a bit easier to understand. It's far more natural to create a function,
then replace all of its occurrences with calls than the other way around.

The functions outlined after this do not change, but their names will be
decided by their benefit. E.g, OUTLINED_FUNCTION_0 will now always be the
most beneficial function, rather than the first one seen.

This makes it easier to enforce an ordering on the outlined functions. So,
this also adds a test to make sure that the ordering works as expected.

llvm-svn: 348414

show more ...

[MachineOutliner][NFC] Don't create outlined sequence from integer mapping

Some gardening/refactoring.

It's cleaner to copy the instructions into the MachineFunction using the first
candidate inste

[MachineOutliner][NFC] Don't create outlined sequence from integer mapping

Some gardening/refactoring.

It's cleaner to copy the instructions into the MachineFunction using the first
candidate instead of going to the mapper.

Also, by doing this we can remove the Seq member from OutlinedFunction entirely.

llvm-svn: 348390

show more ...

Fix Wdocumentation warning. NFCI.

llvm-svn: 347253

[DebugInfo] DISubprogram flags get their own flags word. NFC.
This will hold flags specific to subprograms. In the future
we could potentially free up scarce bits in DIFlags by moving
subprogram-spec

[DebugInfo] DISubprogram flags get their own flags word. NFC.
This will hold flags specific to subprograms. In the future
we could potentially free up scarce bits in DIFlags by moving
subprogram-specific flags from there to the new flags word.

This patch does not change IR/bitcode formats, that will be
done in a follow-up.

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

llvm-svn: 347239

show more ...

[MachineOutliner][NFC] Check if CandidatesForRepeatedSeq < 2

There's no reason to call getOutliningCandidateInfo with a single candidate.

llvm-svn: 346913