similar to: [LLVMdev] Debug Info Verifier: should we create a module pass for it?

My off the cuff idea here is to make it a module pass, but we'll split the verification a bit: a) IR verification time - Verify debug metadata attached to instructions (i.e. line information). Only check it for structure (i.e. do the various metadata nodes have the right number and kind of operands). b) Module pass - Walk down from the CUs in the file and verify everything we see. I think

On Mon, Dec 16, 2013 at 4:05 PM, Eric Christopher <echristo at gmail.com>wrote: > My off the cuff idea here is to make it a module pass, but we'll split the > verification a bit: > > a) IR verification time - > > Verify debug metadata attached to instructions (i.e. line information). > Only check it for structure (i.e. do the various metadata nodes have the >

On Mon, Nov 18, 2013 at 11:06 AM, Manman Ren <manman.ren at gmail.com> wrote: > > > > On Mon, Nov 18, 2013 at 10:55 AM, Eric Christopher <echristo at gmail.com> > wrote: >> >> On Sun, Nov 17, 2013 at 6:35 PM, Manman Ren <manman.ren at gmail.com> wrote: >> > Hi Bill, >> > >> > Thanks for the testing case. Most of the time is

On Mon, Nov 18, 2013 at 10:55 AM, Eric Christopher <echristo at gmail.com>wrote: > On Sun, Nov 17, 2013 at 6:35 PM, Manman Ren <manman.ren at gmail.com> wrote: > > Hi Bill, > > > > Thanks for the testing case. Most of the time is spent on debug info > > verifier. > > I fixed a bug in r194974, now it takes too long to run debug info > >

On Sun, Nov 17, 2013 at 6:35 PM, Manman Ren <manman.ren at gmail.com> wrote: > Hi Bill, > > Thanks for the testing case. Most of the time is spent on debug info > verifier. > I fixed a bug in r194974, now it takes too long to run debug info > verification. > > Debug info verifier is part of the verifier which is a Function Pass. Tot > currently tries to pull all

Hi Bill, Thanks for the testing case. Most of the time is spent on debug info verifier. I fixed a bug in r194974, now it takes too long to run debug info verification. Debug info verifier is part of the verifier which is a Function Pass. Tot currently tries to pull all reachable debug info MDNodes in each function, which is too time-consuming. The correct fix seems to be separating debug info

I think it might be. I’m attaching a preprocessed file that can show the problem. Compile it with ToT. $ clang++ -g -fvisibility-inlines-hidden -fno-exceptions -fno-rtti -fno-common -Woverloaded-virtual -Wcast-qual -fno-strict-aliasing -m64 -pedantic -Wno-long-long -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcovered-switch-default -Wno-uninitialized -Wno-missing-field-initializers -c

Hi Bill Is this a recent regression? I recently changed the debug info verifier to fix a bug. Thanks, Manman > On Nov 17, 2013, at 5:52 PM, Bill Wendling <isanbard at gmail.com> wrote: > > I think that debug info is slowing a self-hosting build down. This build has been going for ages now and shows no sign of quitting. To reproduce, build a Release+Asserts build of clang. Then

On Tue, Nov 12, 2013 at 4:38 PM, Chandler Carruth <chandlerc at google.com>wrote: > > On Tue, Nov 12, 2013 at 4:29 PM, Manman Ren <manman.ren at gmail.com> wrote: > >> Hi All, >> >> In LTO, we load in the source modules and link the source modules into a >> destination module. >> Lots of MDNodes are only used by the source modules, for example

On Tue, Nov 12, 2013 at 4:46 PM, Manman Ren <manman.ren at gmail.com> wrote: > > > > On Tue, Nov 12, 2013 at 4:38 PM, Chandler Carruth <chandlerc at google.com>wrote: > >> >> On Tue, Nov 12, 2013 at 4:29 PM, Manman Ren <manman.ren at gmail.com> wrote: >> >>> Hi All, >>> >>> In LTO, we load in the source modules and

On Fri, Jun 21, 2013 at 12:33 PM, Manman Ren <mren at apple.com> wrote: > > On Jun 21, 2013, at 11:56 AM, Eric Christopher wrote: > >> On Fri, Jun 21, 2013 at 11:50 AM, Manman Ren <mren at apple.com> wrote: >>> >>> On Jun 21, 2013, at 11:35 AM, Eric Christopher wrote: >>> >>>> On Thu, Jun 20, 2013 at 10:52 PM, Manman Ren <mren at

Hi All, In LTO, we load in the source modules and link the source modules into a destination module. Lots of MDNodes are only used by the source modules, for example Xalan used 649MB for MDNodes after loading and linking, but the actual destination module only has 393MB of MDNodes. There are 649-393MB (40% of 649MB) not used. MDNodes belong to the Context, deleting modules will not release the

On Tue, Nov 12, 2013 at 1:01 PM, David Blaikie <dblaikie at gmail.com> wrote: > Hi Manman, > > Thanks for sending this summary and progress plans - it's great to see the > impact your changes have had and ideas for future direction. > > Type uniquing for C++ is in. Some data for Xalan with -flto -g: >> 9.9MB raw dwarf size, peak memory usage at 2.8GB >> The

On Tue, Nov 12, 2013 at 4:29 PM, Manman Ren <manman.ren at gmail.com> wrote: > Hi All, > > In LTO, we load in the source modules and link the source modules into a > destination module. > Lots of MDNodes are only used by the source modules, for example Xalan > used 649MB for MDNodes after loading and linking, but the actual > destination module only has 393MB of

On Tue, Nov 12, 2013 at 4:59 PM, Chandler Carruth <chandlerc at google.com>wrote: > On Tue, Nov 12, 2013 at 4:46 PM, Manman Ren <manman.ren at gmail.com> wrote: > >> >> >> >> On Tue, Nov 12, 2013 at 4:38 PM, Chandler Carruth <chandlerc at google.com>wrote: >> >>> >>> On Tue, Nov 12, 2013 at 4:29 PM, Manman Ren <manman.ren

I think that debug info is slowing a self-hosting build down. This build has been going for ages now and shows no sign of quitting. To reproduce, build a Release+Asserts build of clang. Then use that to build a Debug+Asserts version. Include all of the bells and whistles, like the clang-extras and compiler-rt libraries. The reason I suspect debug info is because of this stack trace: [morbo:llvm]

Hi All, Type uniquing for C++ is in. Some data for Xalan with -flto -g: 9.9MB raw dwarf size, peak memory usage at 2.8GB The raw dwarf size was 58MB, memory usage was 7GB back in May, 2013. Other efforts at size reduction helped, and type uniquing improved on top of those. Data on building clang with "-flto -g" after type uniquing: 3.4GB MDNodes after parsing all bc files, 7GB

On Tue, Nov 12, 2013 at 2:08 PM, Manman Ren <manman.ren at gmail.com> wrote: > > > > On Tue, Nov 12, 2013 at 1:01 PM, David Blaikie <dblaikie at gmail.com> wrote: > >> Hi Manman, >> >> Thanks for sending this summary and progress plans - it's great to see >> the impact your changes have had and ideas for future direction. >> >>

On Fri, Jun 21, 2013 at 12:33 PM, Manman Ren <mren at apple.com> wrote: > > On Jun 21, 2013, at 11:56 AM, Eric Christopher wrote: > >> On Fri, Jun 21, 2013 at 11:50 AM, Manman Ren <mren at apple.com> wrote: >>> >>> On Jun 21, 2013, at 11:35 AM, Eric Christopher wrote: >>> >>>> On Thu, Jun 20, 2013 at 10:52 PM, Manman Ren <mren at

On Jun 21, 2013, at 11:56 AM, Eric Christopher wrote: > On Fri, Jun 21, 2013 at 11:50 AM, Manman Ren <mren at apple.com> wrote: >> >> On Jun 21, 2013, at 11:35 AM, Eric Christopher wrote: >> >>> On Thu, Jun 20, 2013 at 10:52 PM, Manman Ren <mren at apple.com> wrote: >>>> >>>> A summary of options for issue #3: >>>>