[FuncSpec]Fix assertion failure when value is not added to solver

This patch improves the fix in D110529 to prevent from crashing on value
with byval attribute that is not added in SCCP solver.

Aut

[FuncSpec]Fix assertion failure when value is not added to solver

This patch improves the fix in D110529 to prevent from crashing on value
with byval attribute that is not added in SCCP solver.

Authored-by: [email protected]
Reviewed By: ChuanqiXu

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

show more ...

Pipe potentially invalid InstructionCost through CodeMetrics

Per the documentation in Support/InstructionCost.h, the purpose of an invalid cost is so that clients can change behavior on impossible t

Pipe potentially invalid InstructionCost through CodeMetrics

Per the documentation in Support/InstructionCost.h, the purpose of an invalid cost is so that clients can change behavior on impossible to cost inputs. CodeMetrics was instead asserting that invalid costs never occurred.

On a target with an incomplete cost model - e.g. RISCV - this means that transformations would crash on (falsely) invalid constructs - e.g. scalable vectors. While we certainly should improve the cost model - and I plan to do so in the near future - we also shouldn't be crashing. This violates the explicitly stated purpose of an invalid InstructionCost.

I updated all of the "easy" consumers where bailouts were locally obvious. I plan to follow up with loop unroll in a following change.

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

show more ...

[FuncSpec][NFC] Cache code metrics for analyzed functions.

This isn't expected to reduce compilation times as 'max-iters' is set to
one by default, but it helps with recursive functions that require

[FuncSpec][NFC] Cache code metrics for analyzed functions.

This isn't expected to reduce compilation times as 'max-iters' is set to
one by default, but it helps with recursive functions that require higher
iteration counts.

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

show more ...

[FuncSpec] Constant propagate multiple arguments for recursive functions.

This fixes a TODO in constantArgPropagation() to make it feature complete.
However, I do find myself in agreement with the r

[FuncSpec] Constant propagate multiple arguments for recursive functions.

This fixes a TODO in constantArgPropagation() to make it feature complete.
However, I do find myself in agreement with the review comments in
https://reviews.llvm.org/D106426. I don't think we should pursue
specializing such recursive functions as the code size increase becomes
linear to 'max-iters'. Compiling the modified test just with -O3 (no
function specialization) generates the same code.

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

show more ...

[FuncSpec] Support function specialization across multiple arguments.

The current implementation of Function Specialization does not allow
specializing more than one arguments per function call, whi

[FuncSpec] Support function specialization across multiple arguments.

The current implementation of Function Specialization does not allow
specializing more than one arguments per function call, which is a
limitation I am lifting with this patch.

My main challenge was to choose the most suitable ADT for storing the
specializations. We need an associative container for binding all the
actual arguments of a specialization to the function call. We also
need a consistent iteration order across executions. Lastly we want
to be able to sort the entries by Gain and reject the least profitable
ones.

MapVector fits the bill but not quite; erasing elements is expensive
and using stable_sort messes up the indices to the underlying vector.
I am therefore using the underlying vector directly after calculating
the Gain.

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

show more ...

[FuncSpec][NFC] Clang-format the source code and fix debug typo.

Cleanup includes: Transforms/IPO

Preprocessor output diff: -238205 lines
Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.ll

Cleanup includes: Transforms/IPO

Preprocessor output diff: -238205 lines
Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D122183

show more ...

[FuncSpec] Remove unnecessary function pointer type check

We will check a bit later that the constant is in fact a function,
so the separate check for a function pointer type is largely
redunant. Al

[FuncSpec] Remove unnecessary function pointer type check

We will check a bit later that the constant is in fact a function,
so the separate check for a function pointer type is largely
redunant. Also simplify the cast stripping with
stripPointerCasts().

show more ...

[FuncSpec][NFC] Refactor internal structures.

`ArgInfo` is reduced to only contain a pair of {formal,actual} values.
The specialized function `Fn` and the `Partial` flag are redundant in
this struct

[FuncSpec][NFC] Refactor internal structures.

`ArgInfo` is reduced to only contain a pair of {formal,actual} values.
The specialized function `Fn` and the `Partial` flag are redundant in
this structure. The `Gain` is moved to a new struct `SpecializationInfo`.

The value mappings created by cloneCandidateFunction() are being used
by rewriteCallSites() for matching the formal arguments of recursive
functions.

The list of specializations is passed by reference to calculateGains()
instead of being returned by value.

The `IsPartial` flag is removed from isArgumentInteresting() and
getPossibleConstants() as it's no longer used anywhere in the code.

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

show more ...

Cleanup includes: Transform/Scalar

Estimated impact on preprocessor output line:
before: 1062981579
after: 1062494547

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cl

Cleanup includes: Transform/Scalar

Estimated impact on preprocessor output line:
before: 1062981579
after: 1062494547

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D120817

show more ...

Cleanup includes: TransformsUtils

Estimation on the impact on preprocessor output:
before: 1065307662
after: 1064800684

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-

Cleanup includes: TransformsUtils

Estimation on the impact on preprocessor output:
before: 1065307662
after: 1064800684

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D120741

show more ...

[FuncSpec] Remove definitions of fully specialized functions.

A function is basically dead when:
* it has no uses
* it has only self-referencing uses (it's recursive)

Differential Revision: https

[FuncSpec] Remove definitions of fully specialized functions.

A function is basically dead when:
* it has no uses
* it has only self-referencing uses (it's recursive)

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

show more ...

[FuncSpec][NFC] Improve debug messages.

Adds diagnostic messages when debugging the pass.

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

[FuncSpec][NFC] Variable renaming.

Just preparing the ground for follow up patches to make the reviews easier.

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

[FuncSpec] Save compilation time by caching uses for propagation

We only need to do propagation on use instructions of the original
value, rather than the replacing const value which might have lots

[FuncSpec] Save compilation time by caching uses for propagation

We only need to do propagation on use instructions of the original
value, rather than the replacing const value which might have lots
of irrelavant uses. This is done by caching uses before replacing.

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

show more ...

[Function Specialisation] Fix use after free

This is a fix for a use-after-free found by the address sanitizer when
compiling GCC: https://github.com/llvm/llvm-project/issues/52821

The Function Spe

[Function Specialisation] Fix use after free

This is a fix for a use-after-free found by the address sanitizer when
compiling GCC: https://github.com/llvm/llvm-project/issues/52821

The Function Specialization pass may remove instructions, cached
inside the PredicateBase class, which are later being dereferenced
from the SCCPInstVisitor class. To prevent the dangling references
I am lazily deleting the dead instructions after the Solver has run.

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

show more ...

[FuncSpec] Add a reference, and some other clarifying comments. NFC.

[FuncSpec] Rename internal option. NFC.

Rename option MaxConstantsThreshold to MaxClonesThreshold. Not only is this
more descriptive, this is also in preparation of introducing another threshold
to

[FuncSpec] Rename internal option. NFC.

Rename option MaxConstantsThreshold to MaxClonesThreshold. Not only is this
more descriptive, this is also in preparation of introducing another threshold
to analyse more than just 1 constant argument as we currently do, and to better
distinguish these options/thresholds.

show more ...

[FuncSpec] Create helper to update state. NFC.

This creates a helper function updateSpecializedFuncs and is a NFC just to make
the function that drives the transformation easier to read.

[FuncSpec] Respect MaxConstantsThreshold

This is a follow up of D115458 and truncates the worklist of actual arguments
that can be specialised to 'MaxConstantsThreshold' candidates if
MaxConstantsTh

[FuncSpec] Respect MaxConstantsThreshold

This is a follow up of D115458 and truncates the worklist of actual arguments
that can be specialised to 'MaxConstantsThreshold' candidates if
MaxConstantsThreshold was exceeded. Thus, this changes the behaviour of option
-func-specialization-max-constants. Before it didn't specialise at all when
this threshold was exceeded, but now it specialises up to MaxConstantsThreshold
candidates from the sorted worklist.

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

show more ...

Recommit "[FuncSpec] Decouple cost/benefit analysis, allowing sorting of candidates."

Replaced llvm:sort with llvm::stable_sort, this was failing on the bot with
expensive checks enabled.

Revert "[FuncSpec] Decouple cost/benefit analysis, allowing sorting of candidates."

This reverts commit 20b03d65364d963585bf16f175b367f3842f223a.

This shows some failed tests on a bot with expensiv

Revert "[FuncSpec] Decouple cost/benefit analysis, allowing sorting of candidates."

This reverts commit 20b03d65364d963585bf16f175b367f3842f223a.

This shows some failed tests on a bot with expensive checks enabled that I need
to look at.

show more ...

[FuncSpec] Decouple cost/benefit analysis, allowing sorting of candidates.

This mostly is the same code that is refactored to decouple the cost and
benefit analysis. The biggest change is top-level

[FuncSpec] Decouple cost/benefit analysis, allowing sorting of candidates.

This mostly is the same code that is refactored to decouple the cost and
benefit analysis. The biggest change is top-level function specializeFunctions
that now drives the transformation more like this:

specializeFunctions() {
Cost = getSpecializationCost(F);
calculateGains(F, Cost);
specializeFunction(F);
}

while this is just a restructuring, it helps the functional change in
calculateGains. I.e., we now sort the candidates based on the expected
specialisation gain, which we didn't do before. For this, a book keeping struct
ArgInfo was introduced. If we have a list of N candidates, but we only want
specialise less than N as set by option -func-specialization-max-constants, we
sort the list and discard the candidates that give the least benefit.

Given a formal argument, this change results in selecting the best actual
argument(s). This is NFC'ish in that this shouldn't change the current output
(hence no test change here), but in follow ups starting with D115509, it
should and I want to go one step further and compare all functions and all
arguments, which will mostly build on top of this refactoring and change.

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

show more ...

Put implementation details into anonymous namespaces. NFCI.

[FuncSpec] Don't run the solver if there's nothing to do

Even if there are no interesting functions, the SCCP solver would still run
before bailing. Now bail earlier, avoid running the solver for no

[FuncSpec] Don't run the solver if there's nothing to do

Even if there are no interesting functions, the SCCP solver would still run
before bailing. Now bail earlier, avoid running the solver for nothing.

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

show more ...