similar to: [LLVMdev] VS2005 fix for MCAssembler.cpp

Right now MC is optimized for emitting assembly, but as Rafael pointed out to me over IRC the optimized path should be emitting object files. This WIP patch moves MCSymbolData into MCSymbol.h and makes it a field inside MCSymbol. This eliminates a pointer from MCSymbolData back to MCSymbol, the DenseMap<const MCSymbol *, MCSymbolData *> in MCAssembler, and converts the iplist in

On Wed, May 5, 2010 at 5:53 PM, Chris Lattner <clattner at apple.com> wrote: > > On May 5, 2010, at 5:22 PM, Nathan Jeffords wrote: >> >> The logic to handle this has to go somewhere, putting it in the MCStreamer >> *implementation* that needs it is the most logical place.  We also aim to >> implement an assembler, it doesn't make sense to duplicate this

On May 5, 2010, at 5:22 PM, Nathan Jeffords wrote: > > The logic to handle this has to go somewhere, putting it in the MCStreamer *implementation* that needs it is the most logical place. We also aim to implement an assembler, it doesn't make sense to duplicate this logic in the compiler and the assembler parser. > > > Assembly language has often been *the* intermediate

Hi Michael, Overall patch looks good. I do have a few comments below. My main comment is please try to make the style match that used in the MCMachOStreamer more closely. I intend to refactor more functionality into the base MCObjectStreamer class, and having them use consistent idioms makes this easier; specific instances are included in the comments: -- > diff --git

On Sun, Jul 11, 2010 at 6:10 PM, Chris Lattner <clattner at apple.com> wrote: > This probably needs to be slightly tweaked to work with mainline.  I don't see anything objectionable, but I think Daniel needs to review this one. Updated patch to work with mainline. http://github.com/Bigcheese/llvm-mirror/commit/d19a4c82c18afc4830c09b70f02d162292231c94 - Michael Spencer

Hi Jim, The diff below is not intended to be a patch, but a starting point. It is the shortest path (I hope) to getting LLVM to emit ARM mapping symbols to the ELF without changing any shared interfaces. Could you have a look at the FIXME comments and offer some pointers on how to get this code out of MCELFStreamer? Thanks, Greg diff --git a/lib/MC/MCELFStreamer.cpp b/lib/MC/MCELFStreamer.cpp

Good catch! I meant "for iterator" of course. Attached is a corrected patch together with an old patch for clang just to keep them together. Could someone commit these, please? Thanks, Victor 2009/11/4 Jeffrey Yasskin <jyasskin at google.com> > + // Otherwise this is a copy constructor for const_iterator. > > Do you mean "for iterator"? > > Otherwise,

Reminding about the patches... Is there a problem with them or simply nobody have looked at them since? Victor 2009/11/4 Victor Zverovich <victor.zverovich at googlemail.com> > Good catch! I meant "for iterator" of course. Attached is a corrected patch > together with an old patch for clang just to keep them together. > Could someone commit these, please? > >

Attached is a working patch set for llvm to be able to emit arm64 (currently as triple aarch64-apple-ios) mach-o object files, in case someone is interested. I'm not sure if the llvm maintainers want the patch given the previous message that there's going to be an official patch set from apple to support this, but here is mine. What works (tested on an iPhone 5S): * objc strings,

Hi Jeffrey, You are right that the generated copy constructor is used for const_iterator. I have added a comment clarifying this. Also I have added the tests you suggested and corrected the comparison operators. Please find attached the updated patches. Best regards, Victor 2009/11/3 Jeffrey Yasskin <jyasskin at google.com> > +template <bool, typename True, typename False> >

Attached is an example of how to reproduce the issue. It uses a C file that happens to has a bunch of switch statements which are encoded as jump tables, giving us data-in-code. Usage: To build object files with clang via the -integrated-as versus via GCC: $ export NDK_DIR=<my_ndk_dir> $ export LLVM_DIR=<my_llvm_bin_dir> $ make To test that the generated objects contain the same

On Jun 11, 2010, at 6:44 PM, Michael Spencer wrote: > Here is a full patch including Nathan's COFF support, tests that pass > on Windows, and some changes to lit. > > Obviously the COFF support and changes to lit should be separate > patches in the end. > > http://codereview.appspot.com/1624043/show Hi Guys, What is the status of this patch? Here are some comments on

Albert Graef <Dr.Graef at t-online.de> writes: > Victor Zverovich wrote: >> I am considering a possibility of using LLVM JIT for an algebraic >> modelling language. I have already done some prototyping following the >> Kaleidoscope tutorial and currently thinking of how to connect the >> jitted code to a runtime library (for this language) which I would like

Dear all I am trying to get the size of an LLVM pointer type. getPrimitiveSizeInBits() returns 0 for it and the documentation for isSized() suggest to use TargetData. I figured out from Kaleidoscope example that one can get a pointer to TagetData object through the execution engine but it seems to be an overkill. What is the right way to do it? Best regards, Victor -------------- next part

+ // Otherwise this is a copy constructor for const_iterator. Do you mean "for iterator"? Otherwise, looks good to me. If you can commit this, please do. Otherwise, someone else should as I'm not going to be around tomorrow. On Wed, Nov 4, 2009 at 12:27 AM, Victor Zverovich <victor.zverovich at googlemail.com> wrote: > Hi Jeffrey, > You are right that the generated

Hi, The question about the name mangling gave me an idea that it can be used to automate registration of DLL functions. Instead of manually creating Function objects specifying a return type and argument types which is error-prone and time-consuming one can get a list of functions exported from a DLL using Windows API, demangle each name and construct a Function object from it. Is there any

Hi all, Following the example from http://llvm.org/docs/GoldPlugin.html#example1 gives the following error on Ubuntu Karmic: /usr/bin/ld: error: a.a: no archive symbol table (run ranlib) /usr/bin/ld: /usr/lib/crt1.o:../sysdeps/i386/elf/start.S:115: error: undefined reference to 'main' /usr/bin/ld: b.o: in function foo1:b.c(.text+0x4): error: undefined reference to 'foo2'

Nathan, do you have any other changes? If not, I can make these changes and have a patch ready this evening. Sent from my iPhone On Jun 14, 2010, at 2:16 PM, Chris Lattner <clattner at apple.com> wrote: > > On Jun 11, 2010, at 6:44 PM, Michael Spencer wrote: > >> Here is a full patch including Nathan's COFF support, tests that pass >> on Windows, and some

Hi Óscar, On 14 March 2010 15:06, Óscar Fuentes <ofv at wanadoo.es> wrote: > Victor Zverovich <victor.zverovich at googlemail.com> writes: > > > Hi llvm-dev, > > > > Attached are two patches for the LLVM cmake build system. > > > > The first one adds static runtimes (MT and MTd) to the list of runtimes > for > > the MSVC build. > >

Dear all, The first of the proposed patches (DenseMapIterator.patch) forbids implicit conversion of DenseMap::const_iterator to DenseMap::iterator which was possible because DenseMapIterator inherited (publicly) from DenseMapConstIterator. Conversion the other way around is now allowed as one may expect. The template DenseMapConstIterator is removed and the template parameter IsConst which