search for: raw_stream

...stuff (entire module) into a slower destination (file). Even ignoring git execution time it's counter intuitive. The only difference is that while I write more, it overwrite itself continuously, instead of being a long linear steam. I was thinking of mmap the file instead of going through our raw_stream, but maybe that's unnecessary then... > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180315/c303c87c/attachment.html>

...ule) into a slower destination (file). Even ignoring git execution time it's counter intuitive. >> >> The only difference is that while I write more, it overwrite itself continuously, instead of being a long linear steam. I was thinking of mmap the file instead of going through our raw_stream, but maybe that's unnecessary then... >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev...

...wer > destination (file). Even ignoring git execution time it's counter > intuitive. > > The only difference is that while I write more, it overwrite itself > continuously, instead of being a long linear steam. I was thinking of > mmap the file instead of going through our raw_stream, but maybe > that's unnecessary then... > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -------------- next part -------------- An HTML attachm...

...nto a slower > destination (file). Even ignoring git execution time it's counter intuitive. > > The only difference is that while I write more, it overwrite itself > continuously, instead of being a long linear steam. I was thinking of mmap > the file instead of going through our raw_stream, but maybe that's > unnecessary then... > >> > > _______________________________________________ > LLVM Developers mailing listllvm-dev at lists.llvm.orghttp://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > _______________________________________________ &g...

...s >>> counter intuitive. >>> >>> The only difference is that while I write more, it overwrite >>> itself continuously, instead of being a long linear steam. I was >>> thinking of mmap the file instead of going through our >>> raw_stream, but maybe that's unnecessary then... >>> >>> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >>> http...

...nation (file). Even ignoring git execution time it's counter intuitive. >>>> >>>>     The only difference is that while I write more, it overwrite itself continuously, instead of being a long linear steam. I was thinking of mmap the file instead of going through our raw_stream, but maybe that's unnecessary then... >>>> >>>> >>>> >>>>     _______________________________________________ >>>>     LLVM Developers mailing list >>>>     llvm-dev at lists.llvm.org >>>> http://lists.l...

Hi llvmdev, I am still using llvm 2.9. The function addPassesToEmitMC in 3.0 takes a extra parameter to specify the raw stream for the emitter to emit code. However in 2.9, there is no such a parameter. How shall I do if want to pass a raw_stream object? llvm 2.9 // addPassesToEmitMC - Add passes to the specified pass manager to get /// machine code emitted with the MCJIT. This method returns true if machine /// code is not supported. It fills the MCContext Ctx pointer which can be /// used to build custom MCStreamer. /// bool LLVMTargetMa...

...oring git execution time it's > counter intuitive. > >>>> > >>>>     The only difference is that while I write more, it overwrite > itself continuously, instead of being a long linear steam. I was > thinking of mmap the file instead of going through our raw_stream, but > maybe that's unnecessary then... > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>>     LLVM Developers mailing list > >>>>     llvm-dev at lists.llvm.org > &g...

...Even ignoring git execution time it's counter intuitive. > >>>> > >>>> The only difference is that while I write more, it overwrite > itself continuously, instead of being a long linear steam. I was thinking > of mmap the file instead of going through our raw_stream, but maybe that's > unnecessary then... > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> LLVM Developers mailing list > >>>> llvm-dev at lists.llvm.org >...

...> counter intuitive. >> > >>>> >> > >>>> The only difference is that while I write more, it overwrite >> > itself continuously, instead of being a long linear steam. I was >> > thinking of mmap the file instead of going through our raw_stream, but >> > maybe that's unnecessary then... >> > >>>> >> > >>>> >> > >>>> >> > >>>> _______________________________________________ >> > >>>> LLVM Developers mailing list >&gt...

On 03/15/2018 06:09 PM, Alexandre Isoard wrote: > Does git-commit-after-all print correctly after all the passes? Maybe > I messed it up and it skip some passes, therefore having less to do? I did verify that total amount of lines committed to git is reasonably high: ] git rev-list master | while read cmt; do git show $cmt:some-ir.ll; done | wc -l 1587532 corresponding number for

...13 index_mail_get_flags, > > 214 index_mail_get_keywords, > > 215 index_mail_get_parts, > > (dbx) dump > > mbox_mail_get_stream(_mail = 0x200281a8, hdr_size = 0x2ff227a8, body_size = 0x2ff227b8), line 206 in "mbox-mail.c" > > raw_stream = 0x2ff22780 > > mbox = 0x20024a98 > > data = 0x2002820c > > mail = 0x200281a8 > > offset = 804398928 > > (dbx) up > > mail_get_stream(mail = 0x200281a8, hdr_size = 0x2ff227a8, body_size = 0x2ff227b8), line 107 in "mail.c" > > (dbx) list > >...

Does git-commit-after-all print correctly after all the passes? Maybe I messed it up and it skip some passes, therefore having less to do? Either that, or piping has a higher cost than writing to file. Looks like it surprisingly spends much less time in system more when going through file. Maybe that's because the file is consistently around the same size and is mmapped into memory

...ignoring git execution time it's > counter intuitive. > >>>> > >>>> The only difference is that while I write more, it overwrite > itself continuously, instead of being a long linear steam. I was > thinking of mmap the file instead of going through our raw_stream, but > maybe that's unnecessary then... > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> LLVM Developers mailing list > >>>> llvm-dev at lists.llvm.org<mailt...