llvm dev - Feb 2013 - [LLVMdev] GCMetadataPrinter::finishAssembly not executed?

Sorry for the triple-posting! :-$

On 02/14/2013 04:30 PM, Yiannis Tsiouris wrote:
> On 02/10/2013 08:47 PM, Yiannis Tsiouris wrote:
>> After rebasing my local LLVM repo to ToT, I noticed that the
>> finishAssembly function is not executed and, thus, the stack map is not
>> printed at all.
>>
>> Is this a known issue or I 'm doing something wrong?
>>
>> I used a custom GCMetadataPrinter plugin but I reproduced this using
the
>> builtin "ocaml" GC plugin and the attached file (actually,
any simple ll
>> file that uses "ocaml" gc is fine).
>>
>> Note: The beginAssembly function works great.
> I've tried adding two debug prints in 
> lib/CodeGen/AsmPrinter/OcamlGCPrinter.cpp: one in beginAssembly and 
> one in finishAssembly. It seems to me that finishAssembly is never 
> called.
I used git bisect and I think the commit that is responsible for this is:

 > d1abec365aa89a8497d9b615ccb4b21c72da9447 is the first bad commit
 > commit d1abec365aa89a8497d9b615ccb4b21c72da9447
 > Author: Pedro Artigas <partigas at apple.com>
 > Date:   Wed Dec 5 17:12:22 2012 +0000
 >
 >    - Added calls to doInitialization/doFinalization to immutable passes
 >    - fixed ordering of calls to doFinalization to be the reverse of 
the pass run order due to potential dependencies
 >    - fixed machine module info to operate in the 
doInitialization/doFinalization model, also fixes some FIXMEs
 >
 >    reviewed by Evan Cheng <evan.cheng at apple.com>
 >
 >
 >
 >    git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk at 169391 
91177308-0d34-0410-b5e6-96231b3b80d8

Evan or Pedro, can you please take a look at this? :-)

Thanks!
yiannis

-- 
Yiannis Tsiouris
Ph.D. student,
Software Engineering Laboratory,
National Technical University of Athens
WWW: http://www.softlab.ntua.gr/~gtsiour

Hello Yiannis,

I believe what is going on is that there is an issue with the way that
information is deleted (the CG information). Right now there is a pass whose
only job is to delete that information (CGInfoDeleter) and that pass deletes the
info before the AsmPrinter has a chance to call the finishAssembly function.
Right now the order that the doFinalization is called on passes is the reverse
order of doInitialization (and that makes sense as if a pass depends on some
other pass it has to initialize after that pass and clean up before it) so the
deleter pass would have to be added in the pass order after the AsmPrinter pass
as that pass clearly depends on the Deleter pass (passes that have dependencies
on other passes should finalize before the pass it depends on does).

I have a hunch that the very need for the Deleter pass is that the order of
deletion was somewhat undefined before and by having an specific pass one could
place the deletion wherever she/he sees fit. Now that the doFinalization order
is the reverse of the doInitialization one can probably just not have a deleter
and free the info inside the printer pass. The AsmPrinter depends on the Printer
pass so the new order should take care of initialization and finalization at the
right time.

Does this make sense?

Pedro

On Feb 14, 2013, at 12:04 PM, Yiannis Tsiouris <gtsiour at
softlab.ntua.gr> wrote:
> Sorry for the triple-posting! :-$
> 
> On 02/14/2013 04:30 PM, Yiannis Tsiouris wrote:
>> On 02/10/2013 08:47 PM, Yiannis Tsiouris wrote:
>>> After rebasing my local LLVM repo to ToT, I noticed that the
>>> finishAssembly function is not executed and, thus, the stack map is
not
>>> printed at all.
>>> 
>>> Is this a known issue or I 'm doing something wrong?
>>> 
>>> I used a custom GCMetadataPrinter plugin but I reproduced this
using the
>>> builtin "ocaml" GC plugin and the attached file
(actually, any simple ll
>>> file that uses "ocaml" gc is fine).
>>> 
>>> Note: The beginAssembly function works great.
>> I've tried adding two debug prints in
lib/CodeGen/AsmPrinter/OcamlGCPrinter.cpp: one in beginAssembly and one in
finishAssembly. It seems to me that finishAssembly is never called.
> 
> I used git bisect and I think the commit that is responsible for this is:
> 
> > d1abec365aa89a8497d9b615ccb4b21c72da9447 is the first bad commit
> > commit d1abec365aa89a8497d9b615ccb4b21c72da9447
> > Author: Pedro Artigas <partigas at apple.com>
> > Date:   Wed Dec 5 17:12:22 2012 +0000
> >
> >    - Added calls to doInitialization/doFinalization to immutable
passes
> >    - fixed ordering of calls to doFinalization to be the reverse of
the pass run order due to potential dependencies
> >    - fixed machine module info to operate in the
doInitialization/doFinalization model, also fixes some FIXMEs
> >
> >    reviewed by Evan Cheng <evan.cheng at apple.com>
> >
> >
> >
> >    git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk at 169391
91177308-0d34-0410-b5e6-96231b3b80d8
> 
> Evan or Pedro, can you please take a look at this? :-)
> 
> Thanks!
> yiannis
> 
> -- 
> Yiannis Tsiouris
> Ph.D. student,
> Software Engineering Laboratory,
> National Technical University of Athens
> WWW: http://www.softlab.ntua.gr/~gtsiour
>

Hi Pedro (et al.),

On 02/14/2013 11:43 PM, Pedro Artigas wrote:
> I believe what is going on is that there is an issue with the way that
information is deleted (the CG information).
Yeap, that's exactly the problem! :-) I noticed that the 
GCModuleInfo::iterator (line 931 in 
lib/CodeGen/AsmPrinter/AsmPrinter.cpp) is empty and, thus, 
GCMetadataPrinter::finishAssembly is never called.
> Right now there is a pass whose only job is to delete that information
(CGInfoDeleter) and that pass deletes the info before the AsmPrinter has a
chance to call the finishAssembly function. Right now the order that the
doFinalization is called on passes is the reverse order of doInitialization (and
that makes sense as if a pass depends on some other pass it has to initialize
after that pass and clean up before it) so the deleter pass would have to be
added in the pass order after the AsmPrinter pass as that pass clearly depends
on the Deleter pass (passes that have dependencies on other passes should
finalize before the pass it depends on does).
>
> I have a hunch that the very need for the Deleter pass is that the order of
deletion was somewhat undefined before and by having an specific pass one could
place the deletion wherever she/he sees fit. Now that the doFinalization order
is the reverse of the doInitialization one can probably just not have a deleter
and free the info inside the printer pass. The AsmPrinter depends on the Printer
pass so the new order should take care of initialization and finalization at the
right time.
>
> Does this make sense?
Hmm, I see what happens with the doInitialization/doFinalization and the 
pass dependencies. This makes sense to me.

One question though: does this mean that someone has to modify the 
GCMetadataPrinter instance to explicitly take care of the deletion of 
the metadata or changing the order of the Deleter/Printer passes should 
do the trick? If I got it right, this should happen automatically.

yiannis

-- 
Yiannis Tsiouris
Ph.D. student,
Software Engineering Laboratory,
National Technical University of Athens
WWW: http://www.softlab.ntua.gr/~gtsiour