similar to: [LLVMdev] DISerializer question

Thanks cedric, I will look into the ways the debug information could be used. However, it seems like i would have to write a piece of code that would successively reduce the conditional predicate in terms of the local and global variables (of the code). I plan to do it like this. Since i am using a runonBasicblock pass, the context information between two basic blocks cannot be shared, since

Hi Evan, >>Is it possible to implement it without using MachineModuleInfo? but llvm-2.5 didn't , if implement it without using MachineModuleInfo, so I should create another ADT, but that is mostly same to MachineModuleInfo, that's repeat work! or less cost for me ! >> It's being removed. if so, what's the replacement of the MachineModuleInfo ? zhangzw

Hi Evan, My apologies: I've been so excited on sharing the functionality that I forgot to review my patch! Evan Cheng wrote: > On Dec 10, 2007, at 9:52 AM, Nicolas Geoffray wrote: > > >> Hi everyone, >> >> Here's a patch that enables exception handling when jitting. I've >> copy/pasted _many_code from lib/Codegen/DwarfWriter.cpp, so we may

On Dec 10, 2007, at 9:52 AM, Nicolas Geoffray wrote: > Hi everyone, > > Here's a patch that enables exception handling when jitting. I've > copy/pasted _many_code from lib/Codegen/DwarfWriter.cpp, so we may > need > to factorize it, but the functionality is there and I'm very happy > with > it :) Very nice! I don't know enough about EH, someone else

Looks sane. Thanks. Evan On Feb 1, 2008, at 1:24 AM, Nicolas Geoffray wrote: > Dear all, > > Here's a new patch with Evan's comments (thx Evan!) and some cleanups. > Now the (duplicated) exception handling code is in a new file: > lib/ExecutionEngine/JIT/JITDwarfEmitter. > > This patch should work on linux/x86 and linux/ppc (tested). > > Nicolas > Index:

On Oct 14, 2008, at 11:21 PM, Kenneth Boyd wrote: > Mark Kromis wrote: >> Resend >> >> >> On Oct 14, 2008, at 5:40 AM, Mark Kromis wrote: >> >> >>> Greetings, >>> >>> I have a compiler error that I have not been able to get through. I >>> usually depend upon pre-built binaries but there was none available >>> for

Hi Stefan, This looks like a bug. Thanks for catching this and writing the mailing list. Do you think you could submit a patch to fix the problem ? I understand that you can’t release your source code, but there is an easy way to generate test-cases from confidential code. If you can write a “verifier" that makes the compiler crash on an assertion then you can use bug point to reduce

Hi, I run into a a strange error when compiling with debug infos, where LLC tries to generate a variable DIE using a completely wrong frame-index (DebugDwarf tries to resolve frame index 27 in a simple function which only has a single frame object .. ). After digging around, I found that MachineModuleInfo has a VariableDbgInfo map, that is filled by SelectionDAGBuilder.

On Dec 5, 2013, at 4:47 PM, Chandler Carruth <chandlerc at google.com> wrote: > > On Thu, Dec 5, 2013 at 4:16 PM, Andrew Trick <atrick at apple.com> wrote: > We currently have something that looks like: > > IR Transform > (links with) -> TargetTransformInfo > (dynamic call) -> X86TTI > (links with) -> X86Subtarget > > I was thinking of

CodeGen, since it depends on MachineModuleInfo. On 2008-06-05, at 04:06, Talin wrote: > HyperQuantum wrote: >> I'm not a LLVM developer, but I'll give it a try... >> >> On Wed, Jun 4, 2008 at 9:12 AM, Talin <viridia at gmail.com> wrote: >> >> >>> I went and added a new file to the "Support" >>> directory (in include and

Hi we have something like an external driver that likes to own MCInst data externally, i.e. outside from LLVM. By default, the MachineModuleInfo/WrapperPass creates its own context in the constructor of MachineModuleInfo. MMI's context is used throughout codegen. When using a MCStreamer with an external context one can achieve almost what we want, because the streamer's context is used to

As the LLVM build does not create dll's on Windows, two problems arises: 1. Static linking creates big executables. 2. Link time is long. We can create dll's on MinGW using a feature of binutils that mimics .so files on GNU/Linux. The process is very simple. On a MSYS or Cygwin shell (make sure MinGW binaries are on the path before Cygwin's). Read all message before rolling up

On Sep 5, 2013, at 5:15 PM, Ken Dyck <kd at kendyck.com> wrote: > Hi, > > One of the long-standing code clean-up bugs in Bugzilla is to extract > the Machine* code from the CodeGen library into a separate one, on > which CodeGen depends ( > http://llvm.org/bugs/show_bug.cgi?id=1121). > > I'd like to start working on this. The general approach I'm planning

Hi, Some random sample of VS warning: Lot of 64 bits conversions: AsmPrinter.cpp ..\..\lib\CodeGen\AsmPrinter.cpp(277) : warning C4244: 'initializing' : conversion from 'uint64_t' to 'unsigned int', possible loss of data ..\..\lib\CodeGen\AsmPrinter.cpp(614) : warning C4244: 'argument' : conversion from 'uint64_t' to 'int', possible loss of data

Hi Abhishek, On Sunday, July 29, 2012 18:32:11 AbhishekR wrote: > It seems like I may have to modify the way MachineFunction is instantiated in MachineFunctionAnalysis. Instead of doing it per Function, it may have to be done for the entire Module by instantiating MachineFunction objects for every Function inside the Module. This might require major changes to the PassManager framework as well.

Hello all, I am a LLVM newer who want to add a new backend(EBC) into LLVM. After coping the related files from another target and modifying it, I meet a problem when I build the project. The error message is as follows: ================================================================ [ 94%] Built target llvm-dis Linking CXX executable ../../bin/llvm-mc Undefined symbols:

On Thu, Dec 5, 2013 at 4:16 PM, Andrew Trick <atrick at apple.com> wrote: > We currently have something that looks like: > > IR Transform > (links with) -> TargetTransformInfo > (dynamic call) -> X86TTI > (links with) -> X86Subtarget > > I was thinking of directly replacing X86Subtarget as such: > > IR Transform > (links with) ->

Dear LLVM, I'm trying to understand why opt tool does not know some of the registered passes, for example, -targetpassconfig, -gc-lowering, -unreachableblockelim, -unreachableblockelim, -stack-protector, -machinemoduleinfo. This prevents me from using bugpoint to reduce the crash in backend. As I understand, they should be registered and available through the command line in the same way as

On Apr 7, 2008, at 3:02 AM, Nicolas Geoffray wrote: > Hi Evan, > > Evan Cheng wrote: >> >> I don't think the duplication is going to be top much of a problem. >> If >> it is, I'll bug you about refactoring. :) >> >> > > I don't mean to show how lazy I can be, but I also need to know the > size > of the exception table

Hi Duncan, Is it correct that opt does not understand codegen passes, but llc understands both analysis/transformation and codegen passes? I would like to modify bugpoint to work on this end. Thanks, - D. 2012/6/29 Duncan Sands <baldrick at free.fr>: > Hi Dima, > >> I'm trying to understand why opt tool does not know some of the >> registered passes, for example,