search for: gekkeko

...ght be handy to put this in the windows docs since it costed me quite some time to discover. This is for reference to other users that are having heap issues: http://stackoverflow.com/questions/25026488/c11-vs2013-class-pod-member-initialization On Thu, Feb 25, 2016 at 4:33 PM, koffie drinker <gekkekoe at gmail.com> wrote: > I found the root cause, but I don't know what's the best approach to fix > it. > > Under windows, 64 bit, when a function is created the void *User::operator > new(size_t Size) operator allocates space + Use*. > In the Use* the HasHungOffUses is...

...amp; N, llvm::Module * M) Line 116 C++ caused it to be set to False. So do I need to trace into all the Function bases classes and find out where it is set to false? or do I need to fix the Storage address computation in the else part? Cheers, On Thu, Feb 25, 2016 at 1:07 PM, koffie drinker <gekkekoe at gmail.com> wrote: > I made the llvm::Function() constructor public (for testing purpose) and > used the non-overloaded new. > > auto func = ::new llvm::Function(...) > if (func) func->eraseFromParent(); > > And the heap corruption is gone! Did something changed in ll...

...purpose) and used the non-overloaded new. auto func = ::new llvm::Function(...) if (func) func->eraseFromParent(); And the heap corruption is gone! Did something changed in llvm::User::new between 3.7.1 and 3.8.0 ? I found a bug in llvm ? On Thu, Feb 25, 2016 at 12:10 PM, koffie drinker <gekkekoe at gmail.com> wrote: > I downloaded 3.8.0rc3 and I also have it in 3.8.0rc3. > I did set a data access breakpoint on the first function ptr that causes > the invalid heap. This would allow me to break whenever someone is touching > that address. It did not show double deletes durin...

Hi, I'm trying to speed up the JIT time with llvm (3.9.1). So far i've implemented the object cache, used FastISel and disabled optimizations. Jit time is still too slow for my purpose (I do have a lot of code to Jit). http://llvm.org/docs/ProgrammersManual.html#threads-and-the-jit states that we can invoke ExecutionEngine::getPointerToFunction() concurrently. This function was replaced

Hi, What other options do I have to reduce JIT time for large amount of code? - setting optimization level to none helps a lot - enabling FastISel doesn't seem to help much Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160812/f05d51fb/attachment.html>

...it? I'm using visual studio 2015 update1, and could not find any known issue regarding heaps. I'm at a point where I'm suspecting my compiler. But its weird that the same compiler works fine with 3.7.1 any ideas would be appreciated On Wed, Feb 24, 2016 at 9:10 AM, koffie drinker <gekkekoe at gmail.com> wrote: > > I recently upgraded from llvm 3.7.1 to a pre release of llvm (3.8.0rc2) in > order to test some issues regarding bug 24233. > After upgrading I starting to see heap corruption messages in vs 2015 sp1 > when my program exits. > "HEAP[ConsoleEngine...

I recently upgraded from llvm 3.7.1 to a pre release of llvm (3.8.0rc2) in order to test some issues regarding bug 24233. After upgrading I starting to see heap corruption messages in vs 2015 sp1 when my program exits. "HEAP[ConsoleEngine.exe]: Invalid address specified to RtlValidateHeap( 0000000000290000, 0000000000318698 )" Initially I only got it in Release build. Debug build seems

I'm on llvm 3.8.1 and was wondering if there's a memory leak in the removeModule impl of mcjit. In the tutorial http://llvm.org/releases/3.8.1/docs/tutorial/LangImpl4.html a module is removed from the Jit by invoking removeModule. According to the tutorial: "Its API is very simple:: addModule adds an LLVM IR module to the JIT, making its functions available for execution;

...have to have a execution engine per module. Is this still the case ? (the posting were quite old). Is there a difference between mcjit and orc in this case? I was hoping that by not modifying IR during getfunctionaddress() would work :( Cheers, On Tue, Dec 20, 2016 at 6:13 PM, koffie drinker <gekkekoe at gmail.com> wrote: > Hi, > > I'm trying to speed up the JIT time with llvm (3.9.1). > So far i've implemented the object cache, used FastISel and disabled > optimizations. > Jit time is still too slow for my purpose (I do have a lot of code to Jit). > > http:/...

Hi, I am wondering what the status of Clang++ and LLVM on the Windows platform ? When I last saw what the state was there was not proper linking and more recently heard that the Structured Exception Handling was not working. The status page seems somewhat out of date ? Many thanks in advance, Aaron

Hi Kevin, Koffie, We will start migrating to ORC for next release, but for now, this release > invoke delete after remove right? MCJIT's removeModule method does not delete the module. You'll need to do that manually. OrcMCJITReplacement is a bug-for-bug compatible implementation of MCJIT using ORC components, so it does not free the memory either. Does this mean MCJIT is

I am trying to improve my application's compile-time performance. On a given workload, I take 68 seconds to compile some code. If I disable the LLVM code generation (i.e. I will generate IR instructions, but skip the LLVM optimization and instruction selection steps) then my compile time drops to 3 seconds. If I write out the LLVM IR (just to prove that I am generating it) then my compile

Hi Koffie, I'd highly recommend switching to ORC from MCJIT. It is much more flexible when it comes to memory-management. 1. I took the approach of 1 execution engine with multiple modules (I'm not > removing modules once they have been added). During profiling, I noticed > that the memory usage is high with a lot of code. How can I reduce the > memory usage? Is one execution