similar to: [LLVMdev] Bug in MapVector::erase ?

> On 2014-Jul-15, at 11:07, Reid Kleckner <rnk at google.com> wrote: > > Can we explicitly delete the erase method or do something else to document the fact that it is unsupported? It was added incidentally in r211350, even though it was added and removed by Doug back in r175538 / r175449. > I'm happy with it deleted or fixed (see WIP patch that fixes it w/o tests). For

> On 2014-Jul-15, at 10:05, David Blaikie <dblaikie at gmail.com> wrote: > > On Tue, Jul 15, 2014 at 9:43 AM, Duncan P. N. Exon Smith > <dexonsmith at apple.com> wrote: >> >>> On 2014-Jul-15, at 09:38, David Blaikie <dblaikie at gmail.com> wrote: >>> >>> On Tue, Jul 15, 2014 at 9:31 AM, Duncan P. N. Exon Smith >>>

> On 2014-Jul-15, at 09:38, David Blaikie <dblaikie at gmail.com> wrote: > > On Tue, Jul 15, 2014 at 9:31 AM, Duncan P. N. Exon Smith > <dexonsmith at apple.com> wrote: >> >>> On 2014-Jul-15, at 08:29, David Blaikie <dblaikie at gmail.com> wrote: >>> >>> Sounds pretty clearly buggy, and against the original design of the

The new MCJIT is module-oriented, like a classic compiler+linker (which it is) while the old JIT is function-oriented. If I understand correctly, the main problems with the old JIT were the duplication of the debug information code and EH code (both gone now). Moreover, if we ignore the lazy evaluation mechanism then the current JIT is actually quite simple module. Would it be possible to keep

Sure, that makes a lot of sense. The implementation details may get tricky, of course, but the concept is great. -Jim On Oct 30, 2013, at 12:20 PM, Yaron Keren <yaron.keren at gmail.com> wrote: > Hi, > > I'm trying to transition from the JIT to MCJIT. The requirements are fast response time and dynamic unloading/replacement of modified functions. Lazy evaluation is *not*

Hi, I'm trying to transition from the JIT to MCJIT. The requirements are fast response time and dynamic unloading/replacement of modified functions. Lazy evaluation is *not* required: I expect all functions to be present at runtime or else an error is fine. With the JIT it's quite simple to unload and replace functions due to the stubs (JMP instructions) that redirect the actual function

> On 2014-Jul-15, at 08:29, David Blaikie <dblaikie at gmail.com> wrote: > > Sounds pretty clearly buggy, and against the original design of the > ADT (as pointed out by the documentation quotation). When was erase > functionality added to MapVector? Can/should it be removed (and the > use case changed to use some other container) > > Making erase linear time

+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_svector_ostream (without a buffer) goes though write for every character or block it writes. It can work without virtual write() by overriding the existing virtual write_impl() but this is a slower code path for

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

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()) >

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 this right. I experimented with both changes and practically only the lib/Target/X86/X86ISelLowering.cpp fixes the problem. The other change lib/Target/X86/X86FrameLowering.cpp was not

When LLVM's configure finds a usable <pthread.h>, it prefers to use that rather than the home-grown stuff. However if LLVM is configured with --disable-pthreads, both mingw flavors produce the 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

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

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 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>

Yes, this is correct code address accessing bad data address. However, there is no other relocation before .text or near it. I'll send you the full debug printout, maybe you'll note something. The problem could be result of something else entirely else than the linker such as some library initialization code that by chance worked with smaller code but fails now. I need to debug and see

There are two unexpected failures 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

Yes, that's the idea, when you -DLLVM_OPTIMIZED_TABLEGEN=ON tblgen is built in Release in addition to whatever /property:Configuration= is. 2015-05-29 10:03 GMT+03:00 Mueller-Roemer, Johannes Sebastian < Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de>: > That it’s faster is no surprise. Is the Release tblgen even built when > you build in Debug mode? Otherwise this

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 function initialization. If you take a look for isTargetCOFF() in

Hi, Thanks for your ideas. Memory allocation already exceeds 2x64K in the "working" case so it's not the condition of allocating more than 64K. To be sure I had modified SectionMemoryManager::allocateSection to allocate four time the required memory but it did not trigger more crashes.I debugged through the allocation code including the Win32 code and it seems to work well. I have

I sent out a patch for review. http://reviews.llvm.org/D10102 <http://reviews.llvm.org/D10102> -Chris > On May 28, 2015, at 9:48 AM, Yaron Keren <yaron.keren at gmail.com> wrote: > > Thanks! > > 2015-05-28 18:56 GMT+03:00 Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>>: > >> On May 28, 2015, at 8:37 AM, Yaron Keren