search for: hamed

When we were using MCJIT, I could do this: // Attach the event listener Context.EE->RegisterJITEventListener( LLILCJitEventListener::createLLILCJitEventListener( new LLILCJitEventWrapper(&Context))); The event listeners listened for when an object is emitted (NotifyObjectEmitted), and that’s when we’d go through and extract debug info from the ObjectFile. Now, I imagine

Hi Geoff, We use LLJIT. Do addObjectFile() and StaticLibraryDefinitionGenerator work > for ELF objects? They do. :) I've not tested StaticLibraryDefinitionGenerator extensively on Linux. but we have a regression test checking basic usage. If you run into any trouble at all please file a bug and assign it to me. -- Lang. On Mon, Sep 28, 2020 at 2:05 PM Geoff Levner <glevner at

Hi all, I have 2 CentOS 3.5 boxes & i do backups on the LAN Recently, I always get FTP timout error with large files "700 MB and more" . i tried to log and do manual backup with FTP command and i also got the same result "FTP timeout" i tried to google and i did # modprobe ip_conntrack_ftp but still get the same timeout message Any one can help??? Hameed

Hi Sachin, llvm-dev, I've just committed a new PBQP solver which, among other things, should take care of this bug. Please let me know how it works out for you. Cheers, Lang. On Tue, Dec 15, 2009 at 5:54 PM, Lang Hames <lhames at gmail.com> wrote: > Hi Sachin, > > Yes. Bernhard Scholz and I have just discussed a fix for this. I hope to > commit it in the next few days. I

Oooh. Neat. Thanks Dave. Please go ahead and commit that. Arnaud - I have no idea whether Dave's patch will help with this bug, but it's certainly worth testing. - Lang. On Wed, Sep 10, 2014 at 4:10 PM, David Blaikie <dblaikie at gmail.com> wrote: > While I'm not sure where the leak is, using some pre-canned memory > management might help... > > Attached is a

Peace, I have messages like (on a centos 3.8 box) NET: 21 messages suppressed. martian source 10.255.255.255 from 10.0.0.138, on dev eth0 on my screen. In the same time it is being logged to a file. Are there any way to stop the logging of these messages on the console and still logged to a file (/var/log/messages) Thank you. Hameed

Hi all, So I’m also working on LLILC. Specifically, I have been working on a JITEventListener to pass debug line info to the CoreCLR EE. With Joe’s change, I’ve lost the ability (or as far as I can tell) to attach an event listener. Is there a way within Orc to do the sorts of things that the JITEventListeners do in MCJIT? How would I go about adding a layer to add debugging support? Thanks,

Hi Geoff, Importing symbols into the JIT from an object file or static library...? Sure! Are you interested in doing this with the C API, LLJIT, or raw OrcV2 components? The high-level answer here (which we can dig into further in the BoF) is: For object files: - For raw OrcV2 components you'll want to create an RTDyldObjectLinkingLayer or ObjectLinkingLayer and use the 'add'

Both approaches are not exclusive. I would even think it makes sense to have a pre-split pass to prepare the graph, with a global view, and later on use use trySplit (or an equivalent) to handle the local coloring issues. From: Quentin Colombet [mailto:qcolombet at apple.com] Sent: 09 March 2015 23:08 To: Lang Hames Cc: Jonas Paulsson; llvmdev at cs.uiuc.edu; Arnaud De Grandmaison Subject:

Lang, I added the add/get global mapping to my kaleidoscope JIT, but I think perhaps these would make more sense if they were added to the object linking layer as they would be generally usable there. On Aug 19, 2015, at 11:19 PM, Andy Somogyi wrote: > Hey Lang, > > I've added this to my Kaleidoscope JIT, and it seems to work just fine, basically I copied the global mapping

...t to implement multithreaded code generator in LLVM. tnx --- On Tue, 10/5/10, Duncan Sands <baldrick at free.fr> wrote: From: Duncan Sands <baldrick at free.fr> Subject: Re: [LLVMdev] Multithreaded code generation To: llvmdev at cs.uiuc.edu Date: Tuesday, October 5, 2010, 10:50 AM Hi Hamed, > I want to use LLVM to automatically translate sequential codes to multithreaded > codes for execution on multicore processors. > How should I start? currently LLVM does not have support for anything like this as far as I know. But perhaps you meant that you want to implement it, and a...

Hi all, I'd like to propose that Lang Hames be made code owner of the MCJIT, RuntimeDyld and JIT event listener components. For those who don't know, I am the current code owner, but I have not had the time recently to make the level of contributions I had in the past while Lang has been doing outstanding work in this area and has taken on a de facto leadership role in guiding MCJIT

Hi All, The Kaleidoscope tutorials have now been updated on the orcv1-removal branch. I will try to summarise the state of the work and provide some examples in the ORC JIT Weekly mailout tomorrow. The short version is that I think this is ready to land on the mainline. If anyone wants to check out the OrcV1 removal branch and provide feedback now is the time. Otherwise I will aim to land the

Hi Geoff, I have only encountered one problem. If a static library has not been > compiled with -fPIC and uses symbols from a shared library, LLJIT does not > complain, but the code may crash without warning when it is executed. Was the static library compiled with large code model too? I think this is probably a RuntimeDyld bug: It's not great at error reporting. A few people in the

Not yet unfortunately. I've had my head down working on a jut-linker replacement. Let me take a look right now... On Mon, Feb 18, 2019 at 10:40 AM David Blaikie <dblaikie at gmail.com> wrote: > Ping - did this end up getting addressed? > > On Mon, Jan 21, 2019, 6:15 PM Lang Hames <lhames at gmail.com wrote: > >> Hi Nick, >> >> I was not aware of it,

Hi Susan, It looks like the bitcode you have attached is corrupted. You should make sure to attach it as a binary file. Alternatively you can attach the LLVM assembly as text. You can generate an assembly file from bitcode with: llvm-dis -o <asm file> <bitcode> Regards, Lang. On Fri, Nov 9, 2012 at 11:15 AM, Susan Horwitz <horwitz at cs.wisc.edu> wrote: > Thanks Lang,

Hi Lang, Thanks for your inputs on the problem. I was just curious to know if you got any opportunity to work on the solution for this. Regards Sachin > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On > Behalf Of Sachin.Punyani at microchip.com > Sent: Tuesday, November 17, 2009 12:00 PM > Subject: Re: [LLVMdev] Crash

Sorry about that. I created the assembly file and attached it (as math.txt). Susan On 11/11/2012 12:41 AM, Lang Hames wrote: > Hi Susan, > > It looks like the bitcode you have attached is corrupted. You should > make sure to attach it as a binary file. Alternatively you can attach > the LLVM assembly as text. You can generate an assembly file from > bitcode with: > >

Hi Susan, The problem is that the allocator is re-using the 'preg', which is calculated for an operand that may have a subreg index, for loads and stores to a stack-slot. The stack slot always has the same width as vreg (which is the right behavior), but for operands with subreg indexes, 'preg''s class will be different from 'vreg', in which case you get the mismatched

Hi David, I don't have access to a gcc 6.1.0 / aarch64 setup, but I've tried the tests locally and they're passing asan/ubsan/tsan clean, and there is no obvious uninitialized memory use in the test case (though who knows where it might be inlined from in a release build). When you say other tests broke with 8.2.0, do you mean other ORC tests specifically, or just other LLVM tests?