Hello,
@Anastasis: what do you think about this? Do you mind if I implement the
debugify-each mode and refactor the code to have DebugifyFunctionPass and
DebugifyLoopPass? I am sorry if it bothers you, I should have done this
earlier, so you could focus on fixing the optimization passes. FYI, my
debugify-each
is quite ready, I am having Debugify and CheckDebugify before and after
each ModulePass, then I just need to implement the FunctionPass and
LoopPass.
On Thu, Apr 26, 2018 at 8:53 PM, Vedant Kumar <vsk at apple.com> wrote:
> Hello,
>
> On Apr 26, 2018, at 6:44 AM, Son Tuan VU <sontuan.vu119 at gmail.com>
wrote:
>
> Hi Vedant,
>
> I have tried to implement the fix you proposed, but it didn't work as
> expected. I created a new *Module* Pass Manager (not Function Pass
> Manager) and override the *add()* method like this:
>
> class DebugifyEachPassManager : public legacy::PassManager {
> public:
> void add(Pass *P) override {
> PassManager::add(createDebugifyPass());
> PassManager::add(P);
> PassManager::add(createCheckDebugifyPass());
> }
>
> bool run(Module &M) {
> return PassManager::run(M);
> }
> };
>
> However, we can't apply and check debugify of *FunctionPass*es since
> these passes are managed by Function Pass Managers created on the fly
> during *schedulePass()*. I guess we'd have to implement the
FunctionPass
> version of Debugify and CheckDebugify.
>
>
> Yes, Anastasis (CC'd) has started exploring this idea:
> https://gramanas.github.io/posts/community-bonding/. Please sync up with
> him before you start hacking, so you can collaborate on the design and
> split up work :). Now that GSoC has officially started, Anastasis needs to
> plan work ahead of time, so we need to find a way to avoid duplicating
work.
>
> If you find that it's difficult to split up work on this, consider
working
> on enhancing opt's -verify-each mode so that it runs after each pass in
> -O1/-O2/etc. This would help address use-before-def scenarios with debug
> info intrinsics. There's an ongoing discussion about this here:
> https://reviews.llvm.org/D46100.
>
>
Yes I am still waiting for Chandler's thoughts on verify-each mode of
LegacyPassManager (because it works if we use the new PassManager) and on
what would be the best way to tackle it.
> But what about *Call Graph SCC Pass* and *Loop Pass*?
>
>
> Great question! It might not be worthwhile to shoehorn what debugify does
> onto cgscc passes. The major cgscc pass I know of is the inliner, and its
> handling of debug info can be tested in a more targeted way. I think it
> would be worth adding a debugify wrapper for loop passes, however.
>
>
> Do we have a way to know whether a pass is an analysis or a transformation
> at the moment of adding the pass to the manager? I want to try to debugify
> only transformation passes because analysis passes do not modify the IR,
> hence do not modify the DI. But I'm not sure if there's a way to
achieve
> this.
>
>
> I'm not sure if there's a way to do this, but I see it as an
optimization
> that can be deferred for now.
>
>
> I'm currently trying to strip debug info after each CheckDebugify.
>
>
> There's a function called StripDebugInfo which does this.
>
Wow thanks, I was reimplementing that function....
>
> vedant
>
>
> I have been searching everywhere but can't seem to find an API to
remove
> MDNodes. I have seen a *MDNode::deleteAsSubclass() *method, unfortunately
> it is private.I guess nobody has ever needed to remove MDNodes/Metadata
> before. Can you give me some advice on how to do this please?
>
>
> Thank you for your help
>
>
> Son Tuan Vu
>
> On Fri, Mar 16, 2018 at 11:54 PM, Son Tuan VU <sontuan.vu119 at
gmail.com>
> wrote:
>
>> Mhm I see now, thanks for your explanation!
>>
>> Son Tuan Vu
>>
>> On Fri, Mar 16, 2018 at 10:58 PM, Vedant Kumar <vsk at apple.com>
wrote:
>>
>>>
>>> On Mar 16, 2018, at 2:30 PM, Son Tuan VU <sontuan.vu119 at
gmail.com>
>>> wrote:
>>>
>>> Hi Vedant,
>>>
>>> Thank you for your reply. I think I can make this debugify-each
mode,
>>> but I guess this is reserved for your GSoC project ?
>>>
>>>
>>> No, there's no reserved work. If you'd like to work on this
I encourage
>>> you to do so. There's plenty of other work slated for the GSoC
project.
>>> That said, let's make sure to sync up on the mailing lists to
make sure
>>> work isn't being duplicated.
>>>
>>>
>>> However, if I understand correctly, we do not want to take the
output of
>>> the first check-debugify (I mean the .ll file with potentially all
the
>>> WARNINGs and ERRORs after the first pass) as input for the second
debugify.
>>> What we need is to take the fresh output of *clang -Xclang
-emit-llvm
>>> -disable-O0-optnone -S *and iteratively test each optimization. Am
I
>>> right?
>>>
>>>
>>> The intermediate textual output is all irrelevant. And clang
isn't in
>>> the picture here. Opt's regular mode of operation is to run
pass1, then run
>>> pass2, etc. In the debugify-each mode, this instead looks like:
debugify,
>>> pass1, check-debugify, strip debug info, debugify, pass2, etc. etc.
>>>
>>> vedant
>>>
>>>
>>>
>>> Cheers,
>>>
>>>
>>> Son Tuan Vu
>>>
>>> On Thu, Mar 15, 2018 at 4:05 AM, Vedant Kumar <vsk at
apple.com> wrote:
>>>
>>>> Hi Son Tuan,
>>>>
>>>> Thanks for taking a look at this :). Responses inline --
>>>>
>>>> On Mar 14, 2018, at 8:11 AM, Son Tuan VU <sontuan.vu119 at
gmail.com>
>>>> wrote:
>>>>
>>>> Hi Vedant, hi all,
>>>>
>>>> My goal is to measure debug info loss of *each* optimization
pass in
>>>> LLVM. I am trying to create a debugify-each mode in opt,
inspired by
>>>> verify-each mode which is supposed to already work.
>>>>
>>>>
>>>> + Anastasis, who's interested in working on this as well.
There's
>>>> definitely enough work to go around: once we can measure debug
info loss
>>>> after each pass, we'll need a testing harness.
>>>>
>>>>
>>>> However, if I understand correctly, the verify-each mode
(triggered by
>>>> -verify-each option in opt) only works when we provide a pass
list or a
>>>> pass pipeline.
>>>>
>>>>
>>>> Yes, you're correct.
>>>>
>>>>
>>>> Is this intended? I mean, why do not let people verify each
pass in
>>>> -O{1,2,3} pipeline?
>>>>
>>>>
>>>> That's a good question! Like you, I assumed -verify-each
"does the
>>>> right thing" when you pass -O1/-O2/etc. to opt.
>>>>
>>>> I'm not sure if the current behavior is intended (hopefully
others will
>>>> chime in about this :). If no one does, please file a bug.
>>>>
>>>> I imagine this is pretty simple to fix. You can just define and
use
>>>> custom pass managers within opt which inject debugify passes as
needed:
>>>>
>>>> // In opt.cpp:
>>>>
>>>>
>>>> class DebugifyEachFunctionPassManager : public
>>>> legacy::FunctionPassManager {
>>>> public:
>>>> explicit DebugifyEachFunctionPassManager(Module *M)
>>>> : FunctionPassManager(M) {}
>>>>
>>>> void add(Pass *P) override {
>>>> // FunctionPassManager::add(<debugify>)
>>>> FunctionPassManager::add(P);
>>>> }
>>>> };
>>>>
>>>>
>>>>
>>>> My second question is more about debugify: what should be the
best way
>>>> to debugify each pass? Adding a debugify-each mode would make
the output
>>>> unreadable!
>>>>
>>>>
>>>> The intermediate output is all irrelevant. I think it'd be
best to
>>>> simply throw it away. What really matters are the debug info
loss
>>>> statistics: we should capture these stats after each pass and
dump them as
>>>> JSON, at the end of the pipeline.
>>>>
>>>> vedant
>>>>
>>>>
>>>> Maybe writing a script that collects all optimization options
(like
>>>> -mem2reg or -constmerge), then pass each one of them to opt
with
>>>> -enable-debugify so that we have 1 output file for each
debugified pass?
>>>>
>>>> Thank you for your help,
>>>>
>>>> Son Tuan Vu
>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180427/a4b38c4e/attachment.html>