[PATCH] -fsave-optimization-record: add contrib/optrecord.py

[Jeff Law]

On 07/25/2018 08:59 AM, David Malcolm wrote:
> On Tue, 2018-07-24 at 16:11 +0200, Richard Biener wrote:
>> On Mon, Jul 23, 2018 at 9:20 PM David Malcolm <dmalcolm@redhat.com>
>> wrote:
>>>
>>> On Mon, 2018-07-23 at 11:46 +0200, Richard Biener wrote:
>>>> On Fri, Jul 20, 2018 at 6:27 PM David Malcolm <dmalcolm@redhat.co
>>>> m>
>>>> wrote:
>>>>>
>>>>> This patch adds a Python 3 module to "contrib" for reading the
>>>>> output of
>>>>> -fsave-optimization-record.
>>>>>
>>>>> It can be imported from other Python code, or run standalone as
>>>>> a
>>>>> script,
>>>>> in which case it prints the saved messages in a form resembling
>>>>> GCC
>>>>> diagnostics.
>>>>>
>>>>> OK for trunk?
>>>>
>>>> OK, but shouldn't there maybe a user-visible (and thus installed)
>>>> tool for
>>>> this kind of stuff?  Which would mean to place it somewhere else.
>>>
>>> As well as this support code, I've got code that uses it to
>>> generate
>>> HTML reports.  I'm thinking that all this Python code might be
>>> better
>>> to maintain in an entirely separate repository, as a third-party
>>> project (maintained by me, under some suitable Free Software
>>> license,
>>> accessible via PyPI), since I suspect that the release cycle ought
>>> to
>>> be different from that of gcc itself.
>>>
>>> Would that be a better approach?
>>
>> Possibly.
>>
>> Richard.
> 
> [CCing Rainer and Mike]
> 
> A related matter that may affect this: currently there's not much test
> coverage for -fsave-optimization-record in trunk (sorry).
> 
> "trunk" currently has:
> 
> (a) selftest::test_building_json_from_dump_calls, which captures the
> results of some dump calls, and does very minimal textual verification
> of the JSON that would be emitted by -fsave-optimization-record.
> 
> (b) gcc.c-torture/compile/pr86636.c, which merely verifies that we
> don't ICE with a particular usage of -fsave-optimization-record.
> 
> Ideally we'd have some test coverage of the file written out by -fsave-
> optimization-record: that it's valid JSON, that it conforms to the
> expected internal structure, and that the expected data is correct and
> complete (relative to some known dump calls; I have a plugin for
> testing this if need be, in gcc.dg/plugins).
> 
> I don't know if Tcl has any JSON support, but in Python, JSON support
> is built-in to the standard library, so I wonder if there's a case for
> having a DejaGnu directive to (optionally) call out to a Python script
> to check the JSON file that's been written, using this optrecord.py
> module to handle loading the JSON.  Doing so would implicitly check
> that that the emitted adheres to the expected internal structure, and
> the script could add additional testcase-specific verifications.
> 
> The directive would have to check for the presence of Python, and emit
> an UNSUPPORTED if unavailable.
I'd support this.  When a suitable python isn't available it fails
gracefully and gives us independent testing that the resulting bits are
proper JSON.

jeff