This is an archive of the discontinued LLVM Phabricator instance.

Add an option to save the backend-produced YAML optimization record to a file
ClosedPublic

Authored by hfinkel on Oct 3 2016, 11:52 PM.

Details

Summary

The backend now has the capability to save information from optimizations, the same information that can be used to generate optimization diagnostics but in machine-consumable form, into an output file. This can be enabled when using opt (see r282539), and this patch will enable it when using clang. The idea is that other tools will be able to consume these files, and perhaps in combination with the original source code, produce various kinds of optimization reports for users (and for compiler developers).

This patch proposes the name -fsave-optimization-record (and -fsave-optimization-record=filename). Bikeshedding welcome.

Diff Detail

Repository
rL LLVM

Event Timeline

hfinkel updated this revision to Diff 73400.Oct 3 2016, 11:52 PM
hfinkel retitled this revision from to Add an option to save the backend-produced YAML optimization record to a file.
hfinkel updated this object.
hfinkel added reviewers: anemet, rsmith, rjmccall.
hfinkel added a subscriber: cfe-commits.

@rsmith @rjmccall - I chatted with @anemet about this on IRC, and he's happy with it. Please look this over, in part to make sure you're happy with the option name.

On the name, two of my thoughts behind using -fsave-optimization-record were: 1) I did not want to call it a "report", because it is YAML output and not something for a human to use directly and 2) I thought that record, the noun, fit well, but not necessarily the verb, and by putting 'save' in the name it seems clear (at least to me) that record is the noun.

hfinkel updated this revision to Diff 73874.Oct 6 2016, 6:29 PM

I reworked the way that the automatic file-name selection works so that it will work with offloading (e.g. CUDA), and added more tests for the automatic file-name selection. It now also bases the file name on the output file name if you use -S (not just -c). When using an offload device, it makes the output file name for the device different from the host in a way that mirrors other parts of the driver.

I also changed the default extension from .yaml to .opt.yaml to make it a little more descriptive (there are obviously lots of different kinds of yaml files).

anemet added inline comments.Oct 7 2016, 3:32 PM
test/CodeGen/opt-record.c
17–25 ↗(On Diff #73874)

Wouldn't this be a good place to also check that we have -gline-tables-only properly hooked up, i.e. CHECK for DebugLoc: as well?

anemet added inline comments.Oct 7 2016, 3:40 PM
lib/CodeGen/CodeGenAction.cpp
198 ↗(On Diff #73874)

Sorry, one more thing: if PGO is available, I think we want to set Ctx.setDiagnosticHotnessRequested as well. Without that, you'd have to pass -fsave-optimization-record and -fdiagnostics-show-hotness to get hotness info into the YAML file which feels strange. I am certainly fine if we do this later but I wanted to bring it up since it's seems related.

hfinkel added inline comments.Oct 7 2016, 3:45 PM
lib/CodeGen/CodeGenAction.cpp
198 ↗(On Diff #73874)

I agree. We shouldn't require -fdiagnostics-show-hotness for that to work.

test/CodeGen/opt-record.c
17–25 ↗(On Diff #73874)

Yes; will do.

hfinkel updated this revision to Diff 74001.Oct 7 2016, 4:30 PM

Addressed review comments (DebugLoc is tested, and we enable hotness computation when saving the optimization record and also using PGO).

anemet edited edge metadata.Oct 7 2016, 4:34 PM

LGTM, thanks. I also like the option name but will let the the other reviewers official approve that part.

rsmith edited edge metadata.Oct 10 2016, 5:12 PM

As discussed on IRC, I have a mild concern about using -fsave-optimization-record (with no argument) to enable the feature, and -fsave-optimization-record=X to enable the feature and specify a filename; in most (but not all) cases, -option arg and -option=arg mean the same thing. Other than that, this looks good to me.

As discussed on IRC, I have a mild concern about using -fsave-optimization-record (with no argument) to enable the feature, and -fsave-optimization-record=X to enable the feature and specify a filename; in most (but not all) cases, -option arg and -option=arg mean the same thing. Other than that, this looks good to me.

For the record (pun intended, I suppose), we discussed on IRC adding a separate -foptimization-record-file=filename to set the file name.

This revision was automatically updated to reflect the committed changes.
twoh added a subscriber: twoh.Oct 31 2016, 2:30 PM

Is there a particular reason why "opt_record_file" is defined in CC1Options.td, not Options.td? If -opt-record-file=<filename> is provided by the command line, line 829-831 in CompilerInvocation.cpp won't handle it because opt_record_file is not a CodeGenArg.

In D25225#584010, @twoh wrote:

Is there a particular reason why "opt_record_file" is defined in CC1Options.td, not Options.td? If -opt-record-file=<filename> is provided by the command line, line 829-831 in CompilerInvocation.cpp won't handle it because opt_record_file is not a CodeGenArg.

It is not intended to be used directly. The user should use -fsave-optimization-record (along with -foptimization-record-file= if they don't like the default name selected). We definitely need to write end-user docs for this; it is on my TODO list.

twoh added a comment.Oct 31 2016, 2:35 PM
In D25225#584010, @twoh wrote:

Is there a particular reason why "opt_record_file" is defined in CC1Options.td, not Options.td? If -opt-record-file=<filename> is provided by the command line, line 829-831 in CompilerInvocation.cpp won't handle it because opt_record_file is not a CodeGenArg.

It is not intended to be used directly. The user should use -fsave-optimization-record (along with -foptimization-record-file= if they don't like the default name selected). We definitely need to write end-user docs for this; it is on my TODO list.

Got it. Thanks!