Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

Solvers for Boolean formulas have proven to be powerful tools for many applications, ranging from CAD, e. g., for formal verification [4] and circuit test [11], to artificial intelligence [33]. They are not only of academic interest, but have also gained acceptance in industry. While solvers for deciding satisfiability of quantifier-free propositional formulas (the famous SAT-problem [5]) have reached a certain level of maturity during the last years, solving quantified and dependency quantified Boolean formulas (QBFs and DQBFs [27], resp.) is still a hot topic in research. In particular, the last two decades have brought enormous progress in solving QBFs [16, 19, 25, 29] and the last five years also in solving DQBFs [12, 13, 15]. With increasing improvements of solver technology also new applications have arisen which could not be handled (or only handled approximately) before, such as verification of partial designs [14, 35], controller synthesis [7], and games with incomplete information [27].

One part of this success is due to improved solution methods not only based on depth-first search (the QDPLL algorithm) as implemented in solvers like DepQBF [25], QuBE [16], and AQuA (see [32]), but also using quantifier elimination as applied by AIGSolve [29] and Quantor [2], counterexample-guided abstraction refinement, which is the principle underlying the solvers GhostQ [22], RAReQS [19], and Qesto [20], and further algorithms. Another protagonist are sophisticated preprocessing techniques. Their goal is to simplify the formula using algorithms of lower complexity (mostly polynomial) than the actual decision problem before the solver is called. This can reduce the overall computation time by orders of magnitude and, most interestingly, it can even make solving instances feasible which cannot be solved without preprocessing.

Many techniques have been proposed for preprocessing and implemented in different tools. One can distinguish between four main types of preprocessor routines: clause elimination, clause strengthening, variable elimination, and other formula modifications. We will discuss these categories and the corresponding techniques in Sect. 2.2. All of them yield an equisatisfiable formula, which is typically easier to solve than the original one.

Contribution. In this paper, we present the new tool HQSpre, which supports most preprocessing techniques for QBFs and extends them to DQBFs. It is the first available tool for preprocessing DQBFs. The available QBF tools like sQueezeBF and Bloqqer only have a subset of these techniques available. HQSpre can be used both as a standalone tool and as a library. It is designed to be easily extensible and adaptable to different solver back-ends. For instance, if the back-end solver is not CNF-based, but rather works on a circuit representation of the formula, the preprocessor takes care not to destroy this structure, e. g., by forbidding the application of clause elimination routines to clauses that encode circuit gates.

We provide an extensive experimental evaluation where we show that HQSpre  is state of the art: (1) it enables state-of-the-art QBF solvers (AIGSolve [29], AQuA [32], Caqe [38], DepQBF [25], Qesto [20], and RAReQS [19]) to solve more instances in less time than using the alternative preprocessors sQueezeBF [17] and Bloqqer [6], and it is robust over different kinds of solvers; (2) HQSpre is very effective on DQBFs as well, as it is able to solve directly or to simplify into QBFs many formulas, and lets DQBF solvers decide several more problems.

HQSpre is available as an open source tool. The most recent version can be downloaded from:

https://projects.informatik.uni-freiburg.de/projects/dqbf/files.

Structure of this Paper. In the following section, we introduce the necessary foundations and describe the different preprocessing techniques and how they are implemented in HQSpre. Section 3 contains the results of our experiments. Finally, in Sect. 4, we conclude this paper with an outlook on future work.

2 Preprocessing Techniques in HQSpre

2.1 Foundations

Let V be a set of Boolean variables. We consider (dependency) quantified Boolean formulas in prenex conjunctive normal form (PCNF): a quantifier-free Boolean formula is in CNF if it is a conjunction of clauses. A clause is a disjunction of literals, and a literal is either a variable \(v\in V\) or its negation \(\lnot v\). We write clauses in the form \(\{v_1, \dots , v_n\}\) with literals \(v_i\). A clause is called unit if it contains only one literal, and called binary if it contains two literals. We denote the size of a formula as the number of all literals in all clauses. A formula is in PCNF if it can be split into a quantifier prefix and a Boolean formula in CNF, the matrix of the formula.

Definition 1

Let \(V=\{v_1,\ldots ,v_n\}\) be a set of Boolean variables and \(\varphi \) a quantifier-free Boolean formula over V. A quantified Boolean formula (QBF) \(\psi \) has the form \(\displaystyle \psi = Q_1 v_1\ldots Q_n v_n:\varphi \) with \(Q_i\in \{\forall ,\exists \}\) and \(v_i\in V\) for \(i=1,\ldots ,n\). \(Q_1 v_1\ldots Q_n v_n\) is called the quantifier prefix and \(\varphi \) the matrix of \(\psi \).

We denote universal variables with x, and existential ones with y. If the quantifier does not matter, we use v. Accordingly, \(\ell \) is an arbitrary literal, \(\ell ^\exists \) a literal with an existential variable, and \(\ell ^\forall \) a universal literal. For a literal \(\ell \), we define \(\mathrm {var}(\ell )\) as the corresponding variable, i. e., \(\mathrm {var}(v) = \mathrm {var}(\lnot v) = v\).

The quantifier prefix imposes a linear order on the variables. One can think of a QBF as a two-player game: one player assigns the existential variables, the other player the universal ones. The game proceeds turn-based according to the prefix from left to right: When it is the existential player’s turn, he assigns the corresponding existential variable, and similarly for the universal player. The goal of the existential player is to satisfy the formula, the universal player wants to falsify it. The formula is satisfiable if the existential player has a winning strategy, i. e., if he can satisfy the formula no matter how the universal player assigns his variables.

Dependency quantified Boolean formulas are a generalization of QBFs. They are obtained syntactically by relaxing the requirement of a linearly ordered prefix and making the dependencies explicit, and semantically by restricting the knowledge of the players.

Definition 2

Let \(V=\{x_1,\ldots ,x_n,y_1,\ldots ,y_m\}\) be a set of Boolean variables and \(\varphi \) a quantifier-free Boolean formula over V in CNF. A dependency quantified Boolean formula (DQBF) \(\varPsi \) has the form \(\displaystyle \forall x_1\ldots \forall x_n\exists y_1(D_{y_1})\ldots \exists y_m(D_{y_m}):\varphi \), where \(D_{y_i}\subseteq \{x_1,\ldots ,x_n\}\) for \(i=1,\ldots ,m\) is the dependency set of \(y_i\).

In contrast to QBF, a DQBF can be considered as a game with partial information: The universal player assigns all universal variables in the beginning. The existential player assigns a value to each existential variable y based only on the assignment of the universal variables in the corresponding dependency set \(D_y\).

A DQBF is equivalent to a QBF iff for all existential variables \(y, y'\) the condition \(D_y\subseteq D_{y'}\) or \(D_{y'}\subseteq D_y\) holds.

DQBFs are strictly more expressive than QBFs. While deciding satisfiability of QBFs is PSPACE complete [26], deciding DQBFs is NEXPTIME complete [27].

2.2 Preprocessing Techniques

The goal of preprocessing the formula before the actual solution process is to simplify the formula. Experience suggests that benefits of preprocessing increase with the difficulty of the decision problem. As mentioned already in the introduction, the techniques that we apply in our preprocessor HQSpre can be grouped into four different classes: (1) variable elimination, (2) clause elimination, (3) clause strengthening, and (4) other formula modification routines. Due to space restrictions, we cannot provide all details of the techniques. For more information we refer the reader to the cited literature. We present more details for routines which (a) are not described or applied in the literature so far or (b) have interesting implementation details.

Algorithm 1 gives an overview of the main preprocessing routine which calls the different techniques in a loop until the formula does not change anymore.

figure a

Variable Elimination Routines. We define variable elimination routines as methods which are able to remove a variable v from the formula \(\varphi \). The first kind of such techniques can eliminate v whenever we can fix the truth value of v and propagate it through \(\varphi \) using Boolean constraint propagation (BCP) [5]. Common techniques are the detection of constant and pure literals [5]. For efficiency reasons both kinds are usually only checked syntactically: a literal \(\ell \) is constant if there exists a unit clause \(\{\ell \}\) in \(\varphi \), and a literal \(\ell \) is pure if \(\varphi \) does not contain \(\lnot \ell \) in any clause. Both conditions can be easily generalized to (D)QBF [40].

We also apply a check for constants using another syntactic criterion over binary clauses. For this, we first determine the transitive implication closure, i. e., binary clauses of the form: \(\{\lnot \ell _1,\ell _2\}\), \(\{\lnot \ell _2, \ell _3\}\), \(\{\lnot \ell _3, \ell _4\}\), \(\dots \), \(\{\lnot \ell _{n-1}, \ell _n\}\), and \(\{\lnot \ell _n,\lnot \ell _1\}\). These clauses represent a chain of implications: if \(\ell _1\) is assigned the truth value \(\top \), we can deduce that also \(\ell _2, \ell _3, \ell _4, \ldots , \ell _n\) get the truth value \(\top \) in the example above, and this in turn implies that \(\ell _1\) has to get the truth value \(\bot \), i. e., \(\ell _1\) implies \(\lnot \ell _1\), which is a contradiction. So the matrix will be unsatisfied, if we set \(\ell _1\) to \(\top \). Hence, we can deduce \(\lnot \ell _1\) to be a constant literal.

Additionally, we use a SAT-based constant check as described in [30], which is able to detect constants semantically. For this the matrix \(\varphi \) is passed to an incremental SAT solver and it is determined whether \(\varphi \wedge \ell \) is unsatisfiable. In this case, \(\lnot \ell \) is constant. This method reasons only over the matrix without consideration of the dependencies and can therefore be applied without any restrictions for (D)QBF. However, ignoring the quantifiers makes this method incomplete for (D)QBF.

Another well known variable elimination technique is the detection of equivalences, i. e., determining whether a literal \(\ell _1\) is logically equivalent to another literal \(\ell _2\). In this case, one of the variables can be eliminated by replacing all occurrences with the other one. In the (D)QBF case one has to take into account the quantifiers and the dependencies of the affected variables. A very efficient syntactic check to detect equivalent literals is to represent all binary clauses as a directed graph and to determine the strongly connected components (SCCs) within this graph. Every literal which is contained in such an SCC is equivalent to all other literals in the same component [9]. We refer to [40] for details.

The basic (syntactic) detection and propagation of constant and pure literals as well as equivalent literals can be (and were) implemented very efficiently and turned out to be a necessary feature to let preprocessing scale. Hence, in our implementation we apply these three methodsFootnote 1 after each and every more complex technique until a fixed-point is reached. This is referred to as the simplify() method in Algorithm 1.

After eliminating unit, pure, and equivalent literals, we start the main preprocessing loop by applying gate substitution [10]. To do so, we first identify definitions of logical gates within the formula, which can, e. g., result from applying Tseitin transformation [39] to a circuit (see Algorithm 1, line 4). In particular, we seek for AND gates with an arbitrary number of inputs and 2-input XOR gates [29]. For both we allow arbitrary negations on both inputs and output.Footnote 2 As many (D)QBF instances result from applications with circuits, the number of detectable gates can be very large. Once a gate definition is found, the variable \(y_{\mathrm {out}}\), defining the gate output, is no longer needed. Instead \(y_{\mathrm {out}}\) is replaced in each and every clause by its definition. The defining clauses can be deleted afterwards. This direct substitution often produces smaller formulas than eliminating \(y_{\mathrm {out}}\) by resolution (see next paragraphs), but can nevertheless produce very large formulas in some cases. Hence, it is only performed if the formula does not grow above a user-given bound. It is important that this technique is applied early, since many other methods, in particular the clause elimination methods (see next section), might eliminate gate defining clauses. To overcome this issue we optionally apply the concept of frozen variables and clauses [23] for gate definitions, i. e., these variables and clauses are excluded from elimination methods (with the exception of unit, pure, and equivalent literal detection).

Lastly, there are techniques for the elimination of existential and universal variables applying resolution and universal expansion, respectively. For both, the QBF generalization can be found in [5], and the DQBF version in [40]. Generally speaking, both methods eliminate a variable at the cost of expanding the formula.

Variable elimination by resolution can be applied for any existential variable y depending on all universal variables. In this case, we obtain an equisatisfiable formula by adding all possible resolvents with the pivot y and removing all clauses containing y or \(\lnot y\). The resolution of a variable is performed if the estimated size of the formula does not grow beyond a threshold (which is usually set to zero, i. e., resolution is only performed if the formula does not grow).

We observed a special case of resolution which is efficiently identified and always leads to a smaller formula. Therefore, we perform these resolutions more frequently – namely during BCP and blocked clause elimination (see clause elimination routines). If an existential literal \(\ell ^\exists \) only occurs in exactly one binary clause \(\{\ell ^\exists , \ell \}\) (\(\lnot \ell ^\exists \) can occur arbitrarily often), then resolution of the pivot literal \(\ell ^\exists \) yields resolvents in which \(\lnot \ell ^\exists \) is replaced by \(\ell \) w. r. t. the original clauses. In our implementation we simply remove the clause \(\{\ell ^\exists , \ell \}\) and replace \(\lnot \ell ^\exists \) with \(\ell \) in every clause. This procedure is sound as long as \(\mathrm {var}(\ell )\) is also existential and \(D_{\mathrm {var}(\ell )}\subseteq D_{\mathrm {var}(\ell ^\exists )}\) or \(\mathrm {var}(\ell )\) is universal and \(\mathrm {var}(\ell ^\exists )\) depends on it.

Universal expansion [8, 40] of a universal variable x allows to remove x by introducing a copy \(y'\) for every existential variable y depending on x, which has to depend on the same variables as y. Therefore every clause in which y occurs has to be copied, too, such that y is replaced by \(y'\) in the copy. Every occurrence of x in the original part of the formula is now replaced by \(\top \), and every occurrence in the copied part is replaced by \(\bot \) (or vice versa) resulting in an equisatisfiable formula. In our DQBF benchmark set, the number of depending existential variables is often very large and therefore we obtain a huge blow-up of the formula. Hence, in our implementation we do not apply universal expansion for DQBF. In contrast, in QBF many benchmark classes have quite small universal quantifier blocks. In this case, it turns out that the elimination of a complete universal block is often very beneficial, whereas expansion of single variables in large blocks does have a rather small impact. Therefore, we try to expand blocks with small sizes (< 20). We always try to expand the whole block as long as the blow-up of the formula is at most 50% per variable. After each expansion step we also apply variable elimination by resolution in order to reduce the potential number of copied existential variables in the next steps as suggested in [8].

Clause Elimination Routines. As clause elimination routines [18] we understand techniques which eliminate a clause c such that deleting c yields an equisatisfiable formula.

The simplest form of clause elimination is tautology elimination (TE): A clause \(c \in \varphi \) is a tautology iff c contains both the literals \(\ell \) and \(\lnot \ell \). Tautological clauses can be eliminated from \(\varphi \). This condition is independent from the quantifier and hence can be applied for QBF and DQBF without any restrictions.

Another well-known technique is subsumption elimination (SE) [5]. A clause \(c \in \varphi \) is subsumed if there exists another clause \(c' \in \varphi \) such that the set of occurring literals in \(c'\) are a subset of those in c, i. e., if \(\exists c'\in \varphi : c'\subseteq c\). In this case, c can be removed from \(\varphi \). This technique is applied whenever new clauses are added to the formula and for each clause which was strengthened (see next section). Subsumption can be applied without any restrictions in the same manner for QBF as for DQBF as it yields a logically equivalent matrix.

Recently, blocked clause elimination (BCE) [21] has been intensively investigated. It was generalized to QBF in [6] and to DQBF in [40]. A clause \(c \in \varphi \) is blocked if there is an existential literal \(\ell ^\exists \in c\) such that every resolvent with the pivot literal \(\ell ^\exists \) and the clause c is a tautology and the variable v which is responsible for the resolvent being a tautology is either universal and \(\mathrm {var}(\ell ^\exists )\) depends on v or v is existential and v’s dependencies are a subset of \(\mathrm {var}(\ell ^\exists )\)’s dependencies (in the QBF context this means that v is left of \(\mathrm {var}(\ell ^\exists )\) in the quantifier prefix). Such a blocked clause can be removed from \(\varphi \) without changing satisfiability. See the given literature for further details.

Furthermore, all clause elimination routines can be extended by adding so-called hidden and covered literals [18]. Simply speaking, these methods identify literals which can be added to c without changing satisfiability. These literals are added temporarily to c, obtaining a clause \(c'\). TE, SE and BCE can be applied to \(c'\), resulting in hidden/covered tautology/subsumption/blocked clause elimination [18]. In case the checks were unsuccessful, the additional literals are removed. The intuition behind this literal addition is the following: The more literals a clause c contains, the more likely c is either a tautology, subsumed, or blocked. These methods are generalized to (D)QBF in [6, 40], except for TE and SE with hidden/covered literals to DQBF. It is rather easy to see that these methods are sound, too; therefore we do not state an explicit proof here.

In our implementation we perform all clause elimination routines in a loop until a fixed-point is reached, i. e., until no further changes to the formula can be made (see Algorithm 1, line 7). To do so, we keep a queue of clause candidates, which are updated after removing a clause from the formula. Whenever a clause \(c = \{\ell _1,\dots ,\ell _n\}\) has been removed, every clause in which at least one of the literals \(\ell _1, \lnot \ell _1, \dots , \ell _n, \lnot \ell _n\) occurs becomes a new candidate to be removed by one of the above methods.

Clause Strengthening Routines. Clause strengthening routines try to eliminate literals from a clause while preserving the truth value of the formula. We identify two main ways to do so.

Universal reduction (QBF [5], DQBF [1]) removes a universal literal \(\ell ^\forall \) from a clause \(c\in \varphi \) if there are no existential literals \(\ell ^\exists \) in c that depend on \(\ell ^\forall \). In our implementation universal reduction is applied for every added clause as well as for every clause that was strengthened by self-subsuming resolution.

Self-subsuming resolution [10] identifies two clauses \(c_1\) and \(c_2\) with \(\ell \in c_1\), \(\lnot \ell \in c_2\) and \(c_2\setminus \{\lnot \ell \}\subseteq c_1\setminus \{\ell \}\), i. e., \(c_2\) “almost subsumes” \(c_1\) with the exception of exactly one literal \(\ell \), which is contained in the opposite polarity. Resolution of \(c_1\) and \(c_2\) with the pivot literal \(\ell \) leads to \(c_\mathrm {r} = c_1\setminus \{\ell \}\). By adding \(c_\mathrm {r}\) to the formula, \(c_1\) is “self-subsumed” by \(c_\mathrm {r}\); therefore \(c_1\) can be removed after this addition. Our implementation simply removes \(\ell \) from \(c_1\), which has the same effect. This technique leads to a logically equivalent matrix and is therefore independent of the quantification type and the dependencies of the variables; hence it can be applied to QBF and DQBF without any restrictions.

In our implementation, we iterate over all clauses in order to identify such self-subsumptions until a fixed-point is reached. To do so efficiently, we keep a queue of candidates that is updated after deleting a literal. Whenever a literal \(\ell _i\) is removed from a clause \(c = \{\ell _1, \dots , \ell _n\}\), each clause containing at least one of \(\lnot \ell _1, \dots ,\lnot \ell _{i-1}, \lnot \ell _{i+1}, \dots , \lnot \ell _n\) is potentially self-subsuming with c.

Other Formula Modifications. As formula modifications we consider techniques which do not eliminate variables, literals or clauses, but which are able to identify properties that are helpful to decide the formula.

Whenever substituting a gate’s output variable \(y_{\mathrm {out}}\) with its definition is too costly, we apply gate rewriting [17] instead. It adds a new existential variable \(y_{\mathrm {out}}'\) to the same quantifier block as \(y_{\mathrm {out}}\). For one implication direction of the Tseitin encoding of the gate, \(y_{\mathrm {out}}\) is replaced by \(y_{\mathrm {out}}'\), thus delivering a double Plaisted encoding [31], and the occurrences of \(\lnot y_{\mathrm {out}}\) in the (D)QBF are replaced by \(\lnot y_{\mathrm {out}}'\). The purpose of this transformation is to favor detection of pure literals when the clauses including \(y_{\mathrm {out}}\) evaluate to true and to increase the chance that clauses are blocked [6].

Dependency schemes [34] allow to identify dependencies of existential variables y on universal ones x as pseudo-dependencies. The dependencies are syntactically given by the order of the variables in prefix for QBFs and by the dependency sets for DQBFs. A dependency (xy) is a pseudo-dependency, if it can be added or removed without altering the truth value of the formula. Since deciding whether a dependency is a pseudo-dependency is as hard as solving the formula itself [34, 41], different sufficient criteria have been proposed, which are called dependency schemes.

During universal expansion (see variable elimination routines), we utilize the reflexive quadrangle resolution path dependency scheme [37, 41], which is currently the most effective dependency scheme that is sound for both QBF and DQBF. Before expanding a universal variable x, we identify its pseudo-dependencies. All pseudo-dependencies of x do not have to be copied and neither have the clauses to be doubled in which only pseudo-dependencies and variables independent of x occur. This often leads to significantly smaller formulas after the expansion.

Lastly, we also apply SAT checks over the matrix in order to find trivially (un)satisfied formulas. A (D)QBF is trivially unsatisfied if the matrix \(\varphi \) is already unsatisfied for an arbitrary assignment of the universal variables. For this check, we use an assignment of the universal variables which satisfies the fewest clauses, i. e., we assign x to \(\top \) if x occurs in fewer clauses than \(\lnot x\). A (D)QBF is trivially satisfied if, after removing each occurrence of a universal literal within the matrix \(\varphi \), the resulting matrix \(\varphi '\) is satisfiable. Finally, if a formula does not contain any universal variables after universal expansion, we immediately employ a SAT solver for deciding the resulting formula.

2.3 Implementation Details

Our tool was implemented in C++ on a 64 bits Linux machine. We can handle the standard qdimacs and dqdimacs file formats and also provide a clause interface. We are able to convert each QBF into a DQBF and vice-versa in case the dependencies of the DQBF can be linearized into a QBF prefix.

We apply all described techniques in our preprocessor within a main loop until a fixed-point is reached, i. e., no further changes in the formula arise during the latest iteration. Some (costly) techniques, like trivialMatrixChecks(), which use a SAT solver, are applied only once. For all SAT-based techniques we use the SAT solver Antom [36]. Whenever a routine was able to decide the (D)QBF, we immediately exit the loop and return the result.

For an efficient access to all clauses in which a literal \(\ell \) occurs, we keep complete occurrence lists for each literal. Furthermore, we redundantly hold for each literal \(\ell \) a list of all binary clauses in which \(\ell \) occurs, since many of our syntactic methods, such as gate and equivalence detection, employ binary clauses.

We re-use unused variable IDs, i. e., whenever a variable was removed, we mark the index as “open” and such that it can be re-used. This avoids very large variable IDs and gaps in the data structure, which is crucial during universal expansion where many existential variables are newly introduced as a copy.

We tested different data structures for clauses. Structures based on std::set have the advantage of sorted ranges, which is beneficial for, e. g., subsumption and hidden/covered literal addition, but comes with the downside of more expensive access and insertion costs. On the other hand, a std::vector has constant access time, but checking the occurence of a literal in a clause gets more expensive. To overcome this issue we implemented a data structure which marks already occuring literals in the current clause. This “seen” data structure is also implemented as a std::vector with the length of the maximal literal ID. By doing so, we have efficient access on clause data, and checking whether a literal occurs in the clause becomes very cheap. By using this structure, we have measured a speed-up compared to std::set-based clauses of up to a factor of 4.

3 Experimental Evaluation

3.1 QBF Instances

Setting. We evaluated the effectiveness of HQSpre by comparing it against Bloqqer (Version 037) [6] and sQueezeBF [17] (we used QuBE 7.2, which includes sQueezeBF) regarding both the reduction of the input formula and the impact on several back-end solvers. Our new tool was run in two settings, its default one (HQSpre) and \({\textsc {HQSpre}_g}\), which preserves gate information. In Bloqqer and sQueezeBF two subsets of the techniques available in HQSpre are implemented, for more details the interested reader is referred to [6] and [17], respectively.

We used the testset selected for the latest QBF Evaluation (QBFEval 2016 [32]), consisting of 825 formulas. We selected several state-of-the-art QBF solvers (AIGSolve [29], AQuA-F2V [32] Caqe v2 [38], DepQBF v5.01 [25], GhostQ [19], Qesto v1.0 [20], and RAReQS v1.1 [19]) and observed the effects of HQSpre and the other preprocessors on the solvers, which are based on different solving techniques. AIGSolve was also run in a modified version named AIG-HQS, where the built-in preprocessor was replaced with HQSpre. This way, we can better evaluate how the preprocessors affect circuit-based solvers. The experiments were run on DALCO computing nodes, each having \(2\times 8\) Intel E5-2650v2 cores running at 2.6 GHz and providing 64 GB RAM. Each jobFootnote 3 was run on a single core and limited to 600 s CPU time and 4 GB RAM. An overall consistency check reported no deviation in the results of different tools.

Comparing Pure Preprocessors. In Table 1 we evaluate the ability of the preprocessors to act as incomplete solvers and their efficiency. For each preprocessor under analysis, the number of formulas evaluated to true, to false, and of those on which the preprocessor fails are given; additionally, we specify the accumulated computation time needed to handle the testset. Whenever HQSpre failed, the reason was the time limit; memory consumption was not an issue for our preprocessor. HQSpre is the tool that solves the largest number of formulas and takes the least time on average to perform its transformations. \({\textsc {HQSpre}_g}\) is the fastest tool as it applies clause elimination techniques only to those clauses that do not encode gate information. Additionally, it restricts variable elimination by resolution to variables that are not gate outputs.

Table 1. Number of QBF instances decided by different preprocessors.
Table 2. Formula changes by preprocessing QBF: For each preprocessor, data is shown as “before \(\rightarrow \) after” for just reduced formulas (“r”); for solved (“s”) and failed (“f”) instances we show their original size. At the bottom, the averages concern the subset made of the 233 instances all the preprocessors strictly reduced.

Formula Reduction. In Table 2, we show the main features of the formulas in the testset we used, and their counterparts after the transformation with the preprocessors under analysis. The average number of existential variables, universal variables, overall variables, clauses, and quantifier alternations are given in columns 2 to 6. The testsets obtained by using the tools under analysis are split into three sub-rows (“r”, “s”, and “f”, resp.) to distinguish between reduced, solved, and failed instances, respectively. For the reduced instances we report the averages of the quantity shown in the header before and after preprocessing, whereas for the others we report the averages of the original formulas.

The number of remaining clauses and variables for HQSpre are larger on average than for the competing preprocessors. This is mainly due to more aggressive universal expansion in HQSpre leading to many copied existential variables and clauses. On the other hand, many instances can be decided only due to this aggressive expansion. This can also be seen from the average number of universal variables: for the solved formulas, the number of universal variables is significantly smaller for HQSpre than for the other preprocessors.

At the bottom of Table 2, we also compare the numbers for all 233 instances which are neither solved nor failed for all applied preprocessors. Since the set of instances which are neither solved nor failed is different for each solver, this allows a better comparison of the size of the remaining formula. Also from this point of view, Bloqqer leads on average to the smallest formulas, but the difference to our preprocessor is not as large since many huge formulas for which Bloqqer fails but HQSpre does not are excluded from this presentation. As our next experiments show, the remaining larger average size does not worsen the results when applying a QBF solver to the preprocessed formula.

Table 3. Overall results using the original QBF instances, preprocessed by Bloqqer, sQueezeBF, and HQSpre. We give the number of solved instances together with the accumulated computation times in seconds. Best results for each tool are highlighted.

Combination with QBF Solvers. In Table 3, we show the overall performance of the solvers when considering our testset in its original form and when transformed by the preprocessors under analysis. For each testset, we list the number of formulas to be solved, which excludes those already solved by the preprocessor and those where the preprocessor failed. For each solver and testset, the number of solved instances includes those already solved by the preprocessor.

At first glance, we notice that HQSpre improves the state-of-the-art: for each solver, the number of solved instances is strictly higher compared to sQueezeBF and Bloqqer. CEGAR-based solvers (Caqe, RAReQS, and Qesto) take the greatest advantage from using HQSpre compared to Bloqqer, whereas search-based ones (AQuA and DepQBF) improve by a rather small number of solved instances. AIGSolve is the only solver which does not always take advantage from preprocessing: in most cases, its performance gets even degraded. This is mainly due to the underlying data structure of AIGSolve: it uses AND-Inverter graphs (AIGs), which are basically a circuit representation. Since AIGSolve applies syntactic gate detection on the clauses, any preprocessing step destroying this structure is harmful to the solver. AIG-HQSbenefits most from our \({\textsc {HQSpre}_g}\) variant, where gate defining clauses and variables are untouched, and both variants of AIGSolve simply work worse if coupled with general purpose CNF preprocessors. AIGSolve contains an integrated preprocessor, which is well optimized to the AIG-based back-end solver. Still, by using HQSpre as additional front-end preprocessor, the number of solved instances increases. For the other preprocessors, results get worse because they destroy the gate information that AIGSolve can exploit. Note, that even though our preprocessor runs until a fixed-point is reached, a second independent run can change the results, since some methods are only applied at the very beginning and not in every pass through the main preprocessing loop.

Impact on QBF Solvers. In Table 4, we show the impact of the preprocessors on the solvers regarding their robustness. For each pair, we report as a negative number (left) the amount of formulas a solver is able to solve only without preprocessing, and as a positive number (right) the amount of those instances where the preprocessor is necessary for the solver to solve them. Large positive numbers show complementarity, negative numbers close to zero demonstrate good robustness. As a solver based on a circuit representation of the formula, AIGSolve shows the highest complementarity, whereas our gate-preserving preprocessor version \({\textsc {HQSpre}_g}\) is the most robust one for this solver. For most solvers, HQSpre is the most robust preprocessor; exceptions are DepQBF, Caqe, and RAReQS whose techniques are less impaired by sQueezeBF.

Table 4. Positive and negative effect of preprocessing on QBF solvers. Best results for each QBF solver are highlighted.

3.2 DQBF Instances

Setting. We apply our preprocessor to DQBF benchmarks and use it as a front-end for the only two currently available solvers: HQS [15] and iDQ [13]. HQS is – like AIGSolve – an elimination-based solver using AIGs; iDQ is an instantiation-based approach using a SAT solver as back-end. Since HQSpre is the first available preprocessor for DQBF, there are no competitors to compare with. We also apply the gate preserving version \({\textsc {HQSpre}_g}\) for this test set. Since there is no standard benchmark set for DQBF we randomly selected 499 benchmarks of different size and difficulty from currently available benchmark sets: They encompass equivalence checking problems for incomplete circuits [12, 13, 15], and formulas resulting from the synthesis of safe controllers [7]. We used the DALCO computing nodes with the same limitations as in our QBF experiments.

Comparing Pure Preprocessors. Table 5 shows the ability of HQSpre to act as an incomplete solver. Since no universal expansion is applied, on the one hand HQSpre solved fewer instances compared to the QBF benchmarks set. On the other hand, HQSpre could preprocess all instances within the given limits.

Table 5. Decided instances of different preprocessors for DQBF.

Formula Reduction. Table 6 shows the effect on the formula size for the DQBF instances in the same manner as in Table 2. Note, there are no quantifier blocks for DQBF, hence we cannot give the number of quantifier alternations. Instead, we state the number of dependencies (“deps”), which is the sum of the cardinalities of the dependency sets of the existential variables. The given number is the average over all concerned benchmarks. In the last rows, we state the numbers for the 407 commonly reduced, but not solved benchmarks.

Especially, the number of dependencies is significantly reduced for both variations. Since we do not apply any universal expansion the number of universal variables is almost unchanged – the small decrease is mainly caused by pure literal detection of universal variables. On the other hand, this strictly leads to smaller formulas in terms of variables, clauses, and dependencies. Notably, there are 18 instances with \({\textsc {HQSpre}_g}\) and 20 instances with HQSpre, respectively, for which the DQBF dependencies were linearized, i. e., the tools were able to convert the formula into an easier to solve QBF problem.

Table 6. Formula shrinking after preprocessing DQBF: For each preprocessing setting, data is shown as “before \(\rightarrow \) after” for just reduced (“r”) formulas, and for solved (“s”) formulas we show their original size. At the bottom, the averages concern the subset made of the 407 instances all the preprocessors successfully reduce but not solve.
Table 7. Overall results using the original DQBF instances and preprocessed by HQSpre and \({\textsc {HQSpre}_g}\). The accumulated computation times are given in seconds. Best results for each DQBF solver are highlighted.

Impact on DQBF Solvers. Finally, we passed the preprocessed formulas to the two DQBF solvers and compare them with the results for the original formula. For HQS we use two versions: the usual one (HQS) and a version where we have integrated \({\textsc {HQSpre}_g}\) into the solver (\({\textsc {HQS}^{I}}\)). This means that in the combination of HQSpre and \({\textsc {HQSpre}_g}\) with \({\textsc {HQS}^{I}}\) the formula is actually preprocessed twice. The results are given in Table 7. As it can be seen, iDQ and HQS both significantly benefit from preprocessing. However, preprocessing the formula and feeding it into HQS in CNF form does not yield an optimal behavior of the solver compared to a tight integration as in \({\textsc {HQS}^{I}}\). The reason for this is that HQS does not apply gate detection on its own, which leads to much larger AIGs with more variables. Still, we can see that HQSpre is effective: without preprocessing, only 223 instances are solved, with gate-preserving preprocessing, but without exploiting the gate information 326 instances, and with full preprocessing 351 instances are solved. However, the best results are obtained if we integrate the preprocessor into the solver such that the gate information extracted from the CNF is exploited when creating the AIG data structures of the solver. In this case, 456 instances get solved. Preprocessing the formula twice as in HQSpre + \({\textsc {HQS}^{I}}\) or \({\textsc {HQSpre}_g}\) + \({\textsc {HQS}^{I}}\), causes an additional overhead and modifies the formula: Since some of the more expensive techniques like SAT-based constant detection are applied only once, preprocessing the formula twice leads not only to additional overhead, but also to a different formula.

We can conclude that HQSpre is effective also for preprocessing DQBFs. For HQS as the back-end solver, it is of highest importance not only to preserve gate information, but also to integrate the preprocessor into the solver such that this information is exploited optimally.

4 Conclusion

We presented a new state-of-the-art tool HQSpre for preprocessing QBF outperforming every tested competing tool by the number of solved instances as well as increasing the number of solved instances for each state-of-the-art QBF-solver using HQSpre as front-end. Moreover our tool is able to preprocess DQBF formulas effectively and efficiently, being the first available DQBF preprocessor. An integrated version of the DQBF preprocessor clearly outperforms every other competing solver and preprocessor combination.

As future work we want to improve and enhance our gate detection methods. Namely, we want to support the Plaisted-Greenbaum encoding [31] and semantic gate detection. We like to develop an explicit gate and/or AIGER [3] interface, which also closes the gap between solver and applications in general. We also plan to expand our methodology portfolio by other well-known techniques like unit propagation look-ahead [24] (also sometimes referred to as failed literal detection) and vivification [28]. Moreover, we would like to extend our tool with Skolem and Herbrand functions in order to provide and preserve certificates. Lastly, our experimental results indicate that deciding DQBF is very efficient if we are able to transform the formula into a QBF. In order to decide whether a DQBF can be transformed into an equivalent QBF and which operations are needed to do so, a more intense utilization of dependency schemes is needed.