[PATCH 1/2] Implement basic block path solver.

[Jeff Law]

On 7/27/2021 3:58 AM, Aldy Hernandez wrote:
> On Mon, Jul 26, 2021 at 9:10 PM Jeff Law <jeffreyalaw@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