This is an archive of the discontinued LLVM Phabricator instance.

[Debugify] Port -debugify-each to NewPM
ClosedPublic

Authored by MaskRay on Oct 28 2020, 8:02 PM.

Details

Summary

Preemptively switch 2 tests to the new PM

Diff Detail

Event Timeline

MaskRay created this revision.Oct 28 2020, 8:02 PM
Herald added a project: Restricted Project. · View Herald TranscriptOct 28 2020, 8:02 PM
MaskRay requested review of this revision.Oct 28 2020, 8:02 PM
MaskRay updated this revision to Diff 301509.Oct 28 2020, 8:11 PM
MaskRay edited the summary of this revision. (Show Details)

Delete an unneeded change. Fix tests

Thanks for looking into this!

I was previously worried that modifying the IR in pass instrumentation would be bad, but maybe it's ok? The biggest thing I was worried about was unintentionally invalidating analyses, but it looks like both debugify passes preserve all analyses, so it might be ok.

I'm not so sure of moving the flags into Debugify.cpp since they are debugging tools, but I'm not 100% against it.

DebugifyEachInstrumentation should probably be part of StandardInstrumentations so that all users of StandardInstrumentations will get it for free (tying into moving the flags to not be opt-specific). DebugifyEachInstrumentation::registerCallbacks can check if DebugifyEach is set or not to determine whether or not to actually register callbacks, which is cleaner than checking in NewPMDriver.cpp.

llvm/test/DebugInfo/debugify-export.ll
1–2

We should keep the legacy PM RUN line since its implementation is so different. Then use regex to check that we're running a verifier pass.

Thanks for looking into this!

I was previously worried that modifying the IR in pass instrumentation would be bad, but maybe it's ok? The biggest thing I was worried about was unintentionally invalidating analyses, but it looks like both debugify passes preserve all analyses, so it might be ok.

Yeah I was a bit concerned as well. The code says PreservedAnalyses::all() so may be it is fine? The dirty part is the const_cast.

I'm not so sure of moving the flags into Debugify.cpp since they are debugging tools, but I'm not 100% against it.

DebugifyEachInstrumentation should probably be part of StandardInstrumentations so that all users of StandardInstrumentations will get it for free (tying into moving the flags to not be opt-specific). DebugifyEachInstrumentation::registerCallbacks can check if DebugifyEach is set or not to determine whether or not to actually register callbacks, which is cleaner than checking in NewPMDriver.cpp.

-debugify-export writes a file. So even if it is moved to StandardInstrumentations, all the users (clang/opt newPM/opt legacyPM) will need to do something with the option.

Thanks for looking into this!

I was previously worried that modifying the IR in pass instrumentation would be bad, but maybe it's ok? The biggest thing I was worried about was unintentionally invalidating analyses, but it looks like both debugify passes preserve all analyses, so it might be ok.

Yeah I was a bit concerned as well. The code says PreservedAnalyses::all() so may be it is fine? The dirty part is the const_cast.

I'm not so sure of moving the flags into Debugify.cpp since they are debugging tools, but I'm not 100% against it.

DebugifyEachInstrumentation should probably be part of StandardInstrumentations so that all users of StandardInstrumentations will get it for free (tying into moving the flags to not be opt-specific). DebugifyEachInstrumentation::registerCallbacks can check if DebugifyEach is set or not to determine whether or not to actually register callbacks, which is cleaner than checking in NewPMDriver.cpp.

-debugify-export writes a file. So even if it is moved to StandardInstrumentations, all the users (clang/opt newPM/opt legacyPM) will need to do something with the option.

Ah I see, that makes sense.

I still think DebugifyEachInstrumentation should be treated in StandardInstrumentations like the others, and DebugifyEachInstrumentation::registerCallbacks can check the flags to enable/disable itself.

Thanks for looking into this!

I was previously worried that modifying the IR in pass instrumentation would be bad, but maybe it's ok? The biggest thing I was worried about was unintentionally invalidating analyses, but it looks like both debugify passes preserve all analyses, so it might be ok.

Yeah I was a bit concerned as well. The code says PreservedAnalyses::all() so may be it is fine? The dirty part is the const_cast.

I'm not so sure of moving the flags into Debugify.cpp since they are debugging tools, but I'm not 100% against it.

DebugifyEachInstrumentation should probably be part of StandardInstrumentations so that all users of StandardInstrumentations will get it for free (tying into moving the flags to not be opt-specific). DebugifyEachInstrumentation::registerCallbacks can check if DebugifyEach is set or not to determine whether or not to actually register callbacks, which is cleaner than checking in NewPMDriver.cpp.

-debugify-export writes a file. So even if it is moved to StandardInstrumentations, all the users (clang/opt newPM/opt legacyPM) will need to do something with the option.

Ah I see, that makes sense.

I still think DebugifyEachInstrumentation should be treated in StandardInstrumentations like the others, and DebugifyEachInstrumentation::registerCallbacks can check the flags to enable/disable itself.

Emmm. Since we don't really benefit from having the code StandardInstrumentations (using -debugify-export requires the knowledge about DebugifyStatsMap), having the code in Debugify.cpp is fine?
The implementation is actually all in Debugify.cpp . Having DebugifyEachInstrumentation can make StandardInstrumentations unaware of DebugInfo, which achieves good isolation.
This allows us to make apply* and check* static after legacy PM debugify code in opt.cpp is removed.

The issue I have is that the flags can be used anywhere, but each user of StandardInstrumentations has to manually register DebugifyEachInstrumentation if they want to use it. I'd prefer either that the flags be opt-specific and opt can register DebugifyEachInstrumentation, or the flags move to Debugify.cpp so any user of PassBuilder can use them and StandardInstrumentations handle DebugifyEachInstrumentation so that not every user of PassBuilder has to remember to use it.

MaskRay updated this revision to Diff 301990.Oct 30 2020, 12:37 PM

Move -debugify-each and -debugify-export from Debugify.cpp to opt

MaskRay added a comment.EditedOct 30 2020, 12:38 PM

The issue I have is that the flags can be used anywhere, but each user of StandardInstrumentations has to manually register DebugifyEachInstrumentation if they want to use it. I'd prefer either that the flags be opt-specific and opt can register DebugifyEachInstrumentation, or the flags move to Debugify.cpp so any user of PassBuilder can use them and StandardInstrumentations handle DebugifyEachInstrumentation so that not every user of PassBuilder has to remember to use it.

Thanks! This argument makes sense. I moved the two cl::opt options from Debugify.cpp to opt since clang cannot really use them (well, probably it could with some efforts, but that shall belong to a separate change).

Since only opt knows about debugify, it makes sense to have a DebugifyEachInstrumentation.

lgtm besides comments about tests

llvm/test/DebugInfo/pr37964.ll
1

-passes=gvn instead of -gvn -enable-newpm=1

MaskRay updated this revision to Diff 302066.Oct 30 2020, 10:45 PM
MaskRay marked an inline comment as done.

-passes=gvn instead of -gvn -enable-newpm=1

MaskRay edited the summary of this revision. (Show Details)Oct 30 2020, 10:45 PM
aeubanks accepted this revision.Oct 30 2020, 10:50 PM

There's one more comment on debugify-export.ll, otherwise lgtm

This revision is now accepted and ready to land.Oct 30 2020, 10:50 PM
MaskRay updated this revision to Diff 302067.Oct 30 2020, 10:58 PM
MaskRay marked an inline comment as done.

debugify-export.ll: test both -enable-new-pm=[01], use -disable-output

aeubanks accepted this revision.Oct 31 2020, 12:13 AM
This revision was landed with ongoing or failed builds.Nov 2 2020, 8:16 AM
This revision was automatically updated to reflect the committed changes.