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, 2 deletions

diff --git a/comphelper/source/misc/backupfilehelper.cxx b/comphelper/source/misc/backupfilehelper.cxx
index 8bb0804739d5..d47c9904c696 100644
--- a/comphelper/source/misc/backupfilehelper.cxx
+++ b/comphelper/source/misc/backupfilehelper.cxx
@@ -2112,8 +2112,6 @@ namespace comphelper
                                                        "ForceOpenGL", "false"));
         xRootElement->appendChild(lcl_getConfigElement(xDocument, "/org.openoffice.Office.Common/Misc",
                                                        "UseOpenCL", "false"));
-        xRootElement->appendChild(lcl_getConfigElement(xDocument, "/org.openoffice.Office.Common/Misc",
-                                                       "UseSwInterpreter", "false"));
 
         // write back
         uno::Reference< xml::sax::XSAXSerializable > xSerializer(xDocument, uno::UNO_QUERY);