public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug analyzer/109361] RFE: SARIF output could contain timing/profile information
Date: Mon, 31 Jul 2023 15:28:53 +0000	[thread overview]
Message-ID: <bug-109361-4-QtbZg4DweZ@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-109361-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109361

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by David Malcolm <dmalcolm@gcc.gnu.org>:

https://gcc.gnu.org/g:75d623946d4b6ea80a777b789b116d4b4a2298dc

commit r14-2881-g75d623946d4b6ea80a777b789b116d4b4a2298dc
Author: David Malcolm <dmalcolm@redhat.com>
Date:   Mon Jul 31 11:13:02 2023 -0400

    SARIF and -ftime-report's output [PR109361]

    This patch adds support for embeddding profiling information about the
    compiler itself into the SARIF output.

    Specifically, if SARIF diagnostic output is requested, via
    -fdiagnostics-format=sarif-file or -fdiagnostics-format=sarif-stderr,
    then any -ftime-report output is written in JSON form into the SARIF
    output, rather than to stderr.

    In earlier versions of this patch I extended -ftime-report so that
    *as well* as writing to stderr, it would embed the information in any
    SARIF output.  This turned out to be awkward to use, in that I found
    myself needing to get the data in JSON form without also having it
    emitted on stderr (which was fouling my build scripts).

    The timing information is written to the SARIF as a "gcc/timeReport"
    property within a property bag of the "invocation" object.

    Here's an example of the output:

      "invocations": [
          {
              "executionSuccessful": true,
              "toolExecutionNotifications": [],
              "properties": {
                  "gcc/timeReport": {
                      "timevars": [
                          {
                              "name": "phase setup",
                              "elapsed": {
                                  "user": 0.04,
                                  "sys": 0,
                                  "wall": 0.04,
                                  "ggc_mem": 1863472
                              }
                          },

                          [...snip...]

                          {
                              "name": "analyzer: processing worklist",
                              "elapsed": {
                                  "user": 0.06,
                                  "sys": 0,
                                  "wall": 0.06,
                                  "ggc_mem": 48
                              }
                          },
                          {
                              "name": "analyzer: emitting diagnostics",
                              "elapsed": {
                                  "user": 0.01,
                                  "sys": 0,
                                  "wall": 0.01,
                                  "ggc_mem": 0
                              }
                          },
                          {
                              "name": "TOTAL",
                              "elapsed": {
                                  "user": 0.21,
                                  "sys": 0.03,
                                  "wall": 0.24,
                                  "ggc_mem": 3368736
                              }
                          }
                      ],
                      "CHECKING_P": true,
                      "flag_checking": true
                  }
              }
          }
      ]

    The documentation notes that the precise output format is subject
    to change.

    I have successfully used this in my analyzer integration tests to get
    timing information about which source files get slowed down by the
    analyzer.  I've validated the generated .sarif files against the SARIF
    schema.

    gcc/ChangeLog:
            PR analyzer/109361
            * diagnostic-client-data-hooks.h (class sarif_object): New forward
            decl.
            (diagnostic_client_data_hooks::add_sarif_invocation_properties):
            New vfunc.
            * diagnostic-format-sarif.cc: Include "diagnostic-format-sarif.h".
            (class sarif_invocation): Inherit from sarif_object rather than
            json::object.
            (class sarif_result): Likewise.
            (class sarif_ice_notification): Likewise.
            (sarif_object::get_or_create_properties): New.
            (sarif_invocation::prepare_to_flush): Add "context" param.  Use it
            to call the context's add_sarif_invocation_properties hook.
            (sarif_builder::flush_to_file): Pass m_context to
            sarif_invocation::prepare_to_flush.
            * diagnostic-format-sarif.h: New header.
            * doc/invoke.texi (Developer Options): Clarify that -ftime-report
            writes to stderr.  Document that if SARIF diagnostic output is
            requested then any timing information is written in JSON form as
            part of the SARIF output, rather than to stderr.
            * timevar.cc: Include "json.h".
            (timer::named_items::m_hash_map): Split out type into...
            (timer::named_items::hash_map_t): ...this new typedef.
            (timer::named_items::make_json): New function.
            (timevar_diff): New function.
            (make_json_for_timevar_time_def): New function.
            (timer::timevar_def::make_json): New function.
            (timer::make_json): New function.
            * timevar.h (class json::value): New forward decl.
            (timer::make_json): New decl.
            (timer::timevar_def::make_json): New decl.
            * tree-diagnostic-client-data-hooks.cc: Include
            "diagnostic-format-sarif.h" and "timevar.h".
            (compiler_data_hooks::add_sarif_invocation_properties): New vfunc
            implementation.

    gcc/testsuite/ChangeLog:
            PR analyzer/109361
            * c-c++-common/diagnostic-format-sarif-file-timevars-1.c: New test.
            * c-c++-common/diagnostic-format-sarif-file-timevars-2.c: New test.

    Signed-off-by: David Malcolm <dmalcolm@redhat.com>

  parent reply	other threads:[~2023-07-31 15:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-31 13:09 [Bug analyzer/109361] New: " dmalcolm at gcc dot gnu.org
2023-03-31 13:16 ` [Bug analyzer/109361] " dmalcolm at gcc dot gnu.org
2023-03-31 20:45 ` dmalcolm at gcc dot gnu.org
2023-04-03 15:31 ` dmalcolm at gcc dot gnu.org
2023-07-28 20:37 ` dmalcolm at gcc dot gnu.org
2023-07-31 15:28 ` cvs-commit at gcc dot gnu.org [this message]
2023-07-31 15:30 ` dmalcolm at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-109361-4-QtbZg4DweZ@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).