62 lines
3.1 KiB
C++
62 lines
3.1 KiB
C++
|
/*
|
||
|
|
* This program is free software; you can redistribute it and/or
|
||
|
|
* modify it under the terms of the GNU General Public License
|
||
|
|
* as published by the Free Software Foundation; either version 2
|
||
|
|
* of the License, or (at your option) any later version.
|
||
|
|
*
|
||
|
|
* This program is distributed in the hope that it will be useful,
|
||
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||
|
|
* GNU General Public License for more details.
|
||
|
|
*
|
||
|
|
* You should have received a copy of the GNU General Public License
|
||
|
|
* along with this program; if not, write to the Free Software Foundation,
|
||
|
|
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
|
||
|
|
*/
|
||
|
|
|
||
|
|
#pragma once
|
||
|
|
|
||
|
|
/** \file
|
||
|
|
* \ingroup fn
|
||
|
|
*
|
||
|
|
* A #MFProcedure optimization pass takes an existing procedure and changes it in a way that
|
||
|
|
* improves its performance when executed.
|
||
|
|
*
|
||
|
|
* Oftentimes it would also be possible to implement a specific optimization directly during
|
||
|
|
* construction of the initial #MFProcedure. There is a trade-off between doing that or just
|
||
|
|
* building a "simple" procedure and then optimizing it uses separate optimization passes.
|
||
|
|
* - Doing optimizations directly during construction is typically faster than doing it as a
|
||
|
|
* separate pass. However, it would be much harder to turn the optimization off when it is not
|
||
|
|
* necessary, making the construction potentially slower in those cases.
|
||
|
|
* - Doing optimizations directly would also make code more complex, because it mixes the logic
|
||
|
|
* that generates the procedure from some other data with optimization decisions.
|
||
|
|
* - Having a separate pass allows us to use it in different places when necessary.
|
||
|
|
* - Having a separate pass allows us to enable and disable it easily to better understand its
|
||
|
|
* impact on performance.
|
||
|
|
*/
|
||
|
|
|
||
|
|
#include "FN_multi_function_procedure.hh"
|
||
|
|
|
||
|
|
namespace blender::fn::procedure_optimization {
|
||
|
|
|
||
|
|
/**
|
||
|
|
* When generating a procedure, destruct instructions (#MFDestructInstruction) have to be inserted
|
||
|
|
* for all variables that are not outputs. Often the simplest approach is to add these instructions
|
||
|
|
* at the very end. However, when the procedure is executed this is not optimal, because many more
|
||
|
|
* variables are initialized at the same time than necessary. This inhibits the reuse of memory
|
||
|
|
* buffers which decreases performance and increases memory use.
|
||
|
|
*
|
||
|
|
* This optimization pass moves destruct instructions up in the procedure. The goal is to destruct
|
||
|
|
* each variable right after its last use.
|
||
|
|
*
|
||
|
|
* For simplicity, and because this is the most common use case, this optimization currently only
|
||
|
|
* works on a single chain of instructions. Destruct instructions are not moved across branches.
|
||
|
|
*
|
||
|
|
* \param procedure The procedure that should be optimized.
|
||
|
|
* \param block_end_instr The instruction that points to the last instruction within a linear chain
|
||
|
|
* of instructions. The algorithm moves instructions backward starting at this instruction.
|
||
|
|
*/
|
||
|
|
void move_destructs_up(MFProcedure &procedure, MFInstruction &block_end_instr);
|
||
|
|
|
||
|
|
} // namespace blender::fn::procedure_optimization
|