search for: mcsymbols

...oves 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 MCAssembler into a std::vector (along with some churn to pass around MCSymbols instead of MCSymbolData). As a result, during object emission we save ~6 pointers per MCSymbol, eliminate lookup indirection between MCSymbol and MCSymbolData, and avoid allocation overhead for MCSymbolData. I've measured ~4% memory savings on `llc` with this patch (using the same -flto -g in...

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 all, When emitting GC information, it can be very useful to emit the debug location of a GC point, represented as a MCSymbol. Infortunately I haven't found any API (JIT and codegen) where I can get from a MCSymbol to a DebugLoc. Does that interface exist? If not, I plan on committing a small change in the GC code where the debug location is passed to the constructor of a GC point. Patch

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

Ok, I've isolated the recent additions that cause the issue and supplied a patch which is NOT meant to be applied, but instead solely exists for identification purposes for those who know what they are doing. :-) The patch is offset from HEAD. The patch is a hack which removes use of the MCSymbol::isDefined(...) method, as its use happens to break in the exception JIT context; both in

On Sep 12, 2010, at 9:44 AM, nicolas geoffray wrote: > Hi all, > > When emitting GC information, it can be very useful to emit the debug location of a GC point, represented as a MCSymbol. Infortunately I haven't found any API (JIT and codegen) where I can get from a MCSymbol to a DebugLoc. Does that interface exist? If not, I plan on committing a small change in the GC code where

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

Hi Garrison, Does r101453 fix this? -Chris On Mar 22, 2010, at 12:35 PM, Garrison Venn wrote: > Ok, I've isolated the recent additions that cause the issue and supplied a patch which is NOT meant > to be applied, but instead solely exists for identification purposes for those who know what they are doing. :-) > The patch is offset from HEAD. > > The patch is a hack which

Dear llvm-dev-list, I have created my own custom section to be added at the end into a binary upon compilation which contains address of all basic blocks. As the final address of the basic block is not known until link time, I collect the MCSymbol* Symbol Values per BB in a temp array and at the in the custom section and emit it (emitSymbolValue) into my section within EmitEndOfAsmFile() I have

Hi, I am new to llvm. I create a global variable called "test_llvm_var" in the front end function pass like this: new GlobalVariable(*m, tmp->getType(), true, llvm::GlobalValue::ExternalLinkage, tmp, "test_llvm_var"); where tmp is a function. Then I tried to access this global variable in the back end MachineFunctionPass like this: MCContext&

No, I don't. But I’m sure it is not optimized because I can see this variable in the final binary file emitted. Do you mean if I don’t refer to this variable in the front end, then I can’t see it in the backend? (although it’s in the final binary file) Thank you! 2019年1月19日(土) 2:00 <paul.robinson at sony.com>: > Do you have a use of the new variable as well? If not, it might be

Hi everybody. I found that there are some problems with symbol location in AsmParser. 1. We need to know where symbol was declared. 2. We need to know where symbol was defined first time. There are two ways: 1. Add helper table to the parser with additional symbol info. But it takes additional memory consumption. 2. Add user tag (void*) for MCSymbol object. As I understood MCSymbol can live

Hi! I have now a more precise question, I hope that this time, someone will be able to help me :) I'm now able to find the gc meta data. To find this data, I simply register a GCMetadataPrinter (just like during an AOT compilation). A GCMetadataprinter is called at the end of the compilation of a module after having assigned the slots to the live roots. I have almost everything except that

Hi David, Thanks for your efforts here. I have a few comments on your patch, although I realise it's still a work in progress. +class ConstantPool { + MCSymbol *Label; + typedef std::vector<const MCExpr*> EntryVecTy; Use a SmallVector here? + MCSymbol *getLabel() {return Label;} + size_t getNumEntries() {return Entries.size();} + const MCExpr *getEntry(size_t Num) {return

Hi all, So, MCJIT is working with vmkit, that's great. However, I need to retrieve the GCModuleInfo and the MachineCodeEmitter used during the compilation process. And I don't know how I should proceed? I'm trying to understand how they are preserved with the old jit, but I have to say that I'm a little bit lost because I haven't a global view of the code... So, any help would

Hi Chris, The MCSymbol r98459 patch of llvm seems to have broken the ExceptionDemo example. As the example is dying in the associated personality's first unwind search phase, which happens to have no language specific context, and is returning a _URC_CONTINUE_UNWIND, I believe the issue is generic and not specific to the example. However I'm not sure why then this wasn't seen in one

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 Liad, I'm not an expert in MC, but what you describe doesn't sound any different from how you would handle a branch instruction. Create an MCSymbol that represents the address of the target instruction; use that symbol as an operand in the referencing instruction; emit the symbol as a label just prior to emitting the target instruction. The second and third steps can occur in either

Forgot to add platform with issue: OS X 10.6.2. I have not tested elsewhere. Garrison On Mar 18, 2010, at 14:20, Garrison Venn wrote: > Hi Chris, > > The MCSymbol r98459 patch of llvm seems to have broken the ExceptionDemo example. As the example is dying in the > associated personality's first unwind search phase, which happens to have no language specific context, and is