remove Calc's software interpreter

- it's in practice never used nowadays, group threading has higher
priority in the code and since SwInterpreter's allowed opcodes are
a subset of group threading's, there should be no formula where
control flow gets as far as using SwInterpreter
- the only opcodes SwInterpreter allows are ocAdd, ocSub, ocMul,
ocDiv, ocSum and ocProduct, which is a rather limited set and group
threading should handle all that as well
- if SwInterpreter performs anything better than group threading,
there shouldn't be a problem doing the same for group threading
- it's yet another code path that should be handled, tested, etc.
and the added complexity is not worth it
- it shares some code with OpenCL handling, which is both added
hassle in case OpenCL code needs changes, and it also causes confusion
such as people thinking SwInterpreter has something to do with OpenCL

Change-Id: I99052862b60b6266c70dd436d1d7938177dc6bd9
Reviewed-on: https://gerrit.libreoffice.org/58643
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>

1 files changed, 0 insertions, 3 deletions

diff --git a/cui/source/dialogs/about.cxx b/cui/source/dialogs/about.cxx
index 152b49ec9d1f..76ad0ef1fdbe 100644
--- a/cui/source/dialogs/about.cxx
+++ b/cui/source/dialogs/about.cxx
@@ -341,12 +341,9 @@ OUString AboutDialog::GetVersionString()
     OUString aCalcMode = "Calc: "; // Calc calculation mode
 
 #if HAVE_FEATURE_OPENCL
-    bool bSWInterp = officecfg::Office::Common::Misc::UseSwInterpreter::get();
     bool bOpenCL = openclwrapper::GPUEnv::isOpenCLEnabled();
     if (bOpenCL)
         aCalcMode += "CL";
-    else if (bSWInterp)
-        aCalcMode += "group";
 #else
     const bool bOpenCL = false;
 #endif