search for: yaron

If it's a Windows-only thing the correct tests would be: if (NumBytes >= 4096 && STI.isOSWindows()) { and if (Subtarget->isTargetWindows()) where bool isOSWindows() const { return TargetTriple.isOSWindows(); } Yaron 2013/10/23 Andrew MacPherson <andrew.macp at gmail.com> > Glad that helped! As I understand it __chkstk is always required on > Windows regardless of output type, I had meant to file a bug about this but > had apparently forgotten to do so. I think the check needs to be that the...

This is the right fix if Cygwin wants calls to __chkstk. Otherwise you'll want TargetTriple.isOSMSVCRT(). On Wed, Oct 23, 2013 at 2:50 AM, Yaron Keren <yaron.keren at gmail.com> wrote: > If it's a Windows-only thing the correct tests would be: > > if (NumBytes >= 4096 && STI.isOSWindows()) { > > and > > if (Subtarget->isTargetWindows()) > > where > > bool isOSWindows() const {...

...ot required to fix the problem thus it is probably required for other reasons. So, should I patch both tests? Is the correct patch removing the test isTargetCOFF() completely? Or enabling it for both COFF or ELF tarrgets? I mean - is there any X86 target that does NOT require this stack checking? Yaron 2013/10/23 Andrew MacPherson <andrew.macp at gmail.com> > Hi Yaron, > > If you're outputting ELF on Windows this sounds like an issue we ran into > where __chkstk calls weren't being output in the assembly due to an > explicit check for COFF output. Once stack alloc...

...same results. BTW, I've tried to quantify the slowdown: a quick test indicates that LLVM build that uses pthreads is about 10% slower than the one which doesn't. This is less that I remember seeing last year (something got optimized?), but still... Vadim On Fri, Sep 26, 2014 at 3:29 AM, Yaron Keren <yaron.keren at gmail.com> wrote: > Yes, of course. > > I refer to the significant slowdown of Rust compiler when compiled with > -pthreads vs -win32threads flavor. > If Rust can be compiled without <mutex> and <thread> on win32threads, why > should it sl...

...current raw_svector_ostream. Would you prefer to continue review on Phabricator? 2015-07-11 20:48 GMT+03:00 Rafael Espíndola <rafael.espindola at gmail.com>: > This makes write virtual. What is the impact of that on the other > streamers? > > > > On 22 May 2015 at 10:17, Yaron Keren <yaron.keren at gmail.com> wrote: > > Here's a performance testcase for the raw_svector_ostream patch. On my > > WIndows x64 machine it runs in 1010ms with the current code and in 440ms > > with the patch applies. Is this OK to commit? > > > > > >...

...lways required on Windows regardless of output type, I had meant to file a bug about this but had apparently forgotten to do so. I think the check needs to be that the target is Windows and ignore the output type, Linux and OSX don't use this. Cheers, Andrew On Wed, Oct 23, 2013 at 11:32 AM, Yaron Keren <yaron.keren at gmail.com> wrote: > YES, this is the problem! > > The program work ok, even a 5x larger version works well. > > Clearly the _chkstk calls must be emitted with ELF target on Windows as > well - why not? > > I'd like to make a patch and fix thi...

...ake MCJIT emit debug info but for some reason attached gdb did not understand it. Maybe this could be solved. I assumed there may be some limitations around 31-32 bits as there are various int32 members in the ELF structure, but that's far far away. Problems start at .text size of about 150K. Yaron 2013/10/22 Kaylor, Andrew <andrew.kaylor at intel.com> > So it looks like 0x0A3600D1 is a good code address and there’s no > problem executing the code there, but 0x00BC7680 is a bad data address. Is > that correct?**** > > ** ** > > If so, this is almost certainly...

Hi Yaron, If you're outputting ELF on Windows this sounds like an issue we ran into where __chkstk calls weren't being output in the assembly due to an explicit check for COFF output. Once stack allocations in a given function exceeded some amount we'd get exactly this kind of crash in the func...

...<rafael.espindola at gmail.com>: > Given that it is faster, I am OK with it. > > I get 0.774371631s with master and 0.649787169s with your patch. > > Why move all virtual functions to the header? LGTM with them still in > the .cpp file. > > On 12 August 2015 at 01:53, Yaron Keren <yaron.keren at gmail.com> wrote: > > +llvm-dev at lists.llvm.org > > > > The impact should be small as all the other streamers usually write > directly > > to the memory buffer and only when out of buffer they call write(). > > > > OTOH, raw_svect...

Here's a performance testcase for the raw_svector_ostream patch. On my WIndows x64 machine it runs in 1010ms with the current code and in 440ms with the patch applies. Is this OK to commit? 2015-05-02 21:31 GMT+03:00 Yaron Keren <yaron.keren at gmail.com>: > Following a hint from Duncan in http://llvm.org/pr23395, here is a > revised patch. Rather then introduce the raw_char_ostream adapter, this > version improves raw_svector_ostream. > > raw_svector_ostream is now a very lightweight adapter, r...

...d | cat_metric | var_metric | commented | filename | category | var_name | var_val | +----+------------+-------------+----------------+-----------------------+-----------+---------------+----------+ | 2 | 0 | 0 | 0 | musiconhold.conf | yaron | directory | moh | | 3 | 0 | 0 | 0 | musiconhold.conf | yaron | mode | files | | 10 | 0 | 0 | 0 | musiconhold.conf | yaron1 | directory | moh | | 11 | 0...

...s the last function added to the Module. Also I speculated that if it crashes when .text crosses 128K but no, it happens when it's larger. I had attached gdb to the process hoping it will show more information but it showed even less information than the Visual C++ debugger. Out of ideas... Yaron 2013/10/22 Kaylor, Andrew <andrew.kaylor at intel.com> > I would guess that it’s crashing somewhere in the generated code. On > Windows we don’t have a way to get call stacks to the generated code > (though if you want to try it on Linux, that should work). You can > probab...

...ED: UBSan-Standalone-x86_64::log-path_test.cc <http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/4522/steps/ninja%20check%201/logs/UNRESOLVED%3A%20UBSan-Standalone-x86_64%3A%3Alog-path_test.cc> this masks other new test failuers (clang modules related). Could you have a look? Yaron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150901/60d0cbb6/attachment.html>

...ctions at addresses that are more than 2GB apart we'll have problems, but you should see an assertion in that case. That can happen if we weren't able to get the address we requested from allocateMappedMemory, but it doesn't look like that's what's happening here. -Andy From: Yaron Keren [mailto:yaron.keren at gmail.com] Sent: Tuesday, October 22, 2013 1:41 PM To: Kaylor, Andrew Cc: <llvmdev at cs.uiuc.edu> Subject: Re: Size limitations in MCJIT / ELF Dynamic Linker/ ELF codegen? Hi, Thanks for your ideas. Memory allocation already exceeds 2x64K in the "working&...

...s in the check-all (this check-all runs with self-build-clang): Failing Tests (2): Clang Tools :: clang-tidy/clang-tidy-diff.cpp Clang Tools :: clang-tidy/file-filter.cpp Last log: http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/340/steps/ninja%20check%202/logs/stdio From: Yaron Keren [mailto:yaron.keren at gmail.com] Sent: Thursday, April 23, 2015 12:27 To: Paweł Bylica Cc: Fedorova, Vera; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Buildbot for Windows native LLVM/Clang testing r235576 Window7 Visual C++ 2013 x64 just passed regression OK on my system. 2015-04-23 12...

Hi Yaron, Not sure I understand your question. Wasn't <mutex> one of the more important C++11 features that LLVM would like to use? On Thu, Sep 25, 2014 at 1:24 AM, Yaron Keren <yaron.keren at gmail.com> wrote: > Vadim, > > Thanks for the feedback on the -win32. A dependency on a...

...lines of the above code module and crash the same with more code. The call stack is unhelpful Visual C++ says: Frames below may be incorrect and/or missing which indicates a real problem with it. I have tried to provide less stack space (default is 10M) for the compiled program without any change. Yaron 2013/10/22 Kaylor, Andrew <andrew.kaylor at intel.com> > I’m not aware of such a limitation.**** > > ** ** > > What architecture, code model and relocation model are you using? Are you > using the SectionMemoryManager?**** > > ** ** > > -Andy**** > >...

...gt; > > > Fraunhofer-Institut für Graphische Datenverarbeitung IGD > > Fraunhoferstr. 5 | 64283 Darmstadt | Germany > > Tel +49 6151 155-606 | Fax +49 6151 155-139 > > johannes.mueller-roemer at igd.fraunhofer.de | www.igd.fraunhofer.de > > > > *From:* Yaron Keren [mailto:yaron.keren at gmail.com] > *Sent:* Friday, May 29, 2015 08:59 > *To:* Mueller-Roemer, Johannes Sebastian > *Cc:* Chris Bieneman; LLVM Developers Mailing List > > *Subject:* Re: [LLVMdev] [RFC] Late May Update: Progress report on CMake > build system's ability to...

...from the module and did the search ourselves so that we could keep some information about the things that didn’t match and optimize the next search. > > -Andy > > From: Jim Grosbach [mailto:grosbach at apple.com] > Sent: Monday, October 21, 2013 4:39 PM > To: Kaylor, Andrew; Yaron Keren > Cc: <llvmdev at cs.uiuc.edu> > Subject: Re: [LLVMdev] An enhancement for MCJIT::getFunctionAddress > > The search is linear? If that’s really true, we should fix that. > > On Oct 21, 2013, at 10:14 AM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: >...

...Second, I'd look at the relocation processing. If it is generating any stubs, that would be a potential problem spot, but it shouldn't be generating any stubs. So the obvious thing to look at is whether any of the relocations are writing to the spot where the crash occurs. -Andy From: Yaron Keren [mailto:yaron.keren at gmail.com] Sent: Tuesday, October 22, 2013 10:17 AM To: Kaylor, Andrew Cc: <llvmdev at cs.uiuc.edu> Subject: Re: Size limitations in MCJIT / ELF Dynamic Linker/ ELF codegen? OS is Windows 7 64 bit OS, compiler is 32 bit Visual C++ 2012 with 32 bit. The target whi...