On 7/27/2021 3:58 AM, Aldy Hernandez wrote:
On Mon, Jul 26, 2021 at 9:10 PM Jeff Law <jeffreya...@gmail.com> wrote:
On 7/2/2021 2:13 AM, Aldy Hernandez wrote:
On 7/2/21 12:20 AM, Jeff Law wrote:
On 6/28/2021 10:21 AM, Aldy Hernandez wrote:
+// Internal construct to help facilitate debugging of solver.
+#define DEBUG_SOLVER getenv("DEBUG")
Shouldn't this really be a property of what pass is using the solver
and whether or not the appropriate dump flag is on for that pass?
Whoops. This was a private construct used for debugging the solver.
I've changed it to:
+#define DEBUG_SOLVER (0 && dump_file)
I would probably argue that the #define should disappear and the code
should be checking the current dump state for the current pass. If you
don't want to keep the debugging output, then remove it :-) I think
that can be handled in a follow-up patch.
The debugging output is really verbose, especially because the
threader will try a boatload of different paths all of which get their
propagation dumped. Is there a recommended way of leaving the
debugging in the code, but only enabled sporadically? Perhaps a
--param ??. Or perhaps I could remove it near the end of stage 1?
You could make it conditional on TDF_DETAILS, which is what I think most
passes do when they want the higher levels of verbosity.
ie
if (dump_file && (dump_flags & TDF_DETAILS))
Jeff
