similar to: [LLVMdev] Patch for PR4776

Hello, Yesterday I noticed that MSP430 argument passing is broken in trunk; see http://llvm.org/PR6573 for details and testcases. The problem is that calls aren't being preceded by instructions that put the arguments into registers. I backtracked my working copy and then stepped forward until it broke between r98937 and r98938. Refining further, I found that rolling back the

On Fri, Jun 11, 2010 at 2:55 PM, Ben Ransford <ransford at cs.umass.edu> wrote: > Yesterday I noticed that MSP430 argument passing is broken in trunk; > see http://llvm.org/PR6573 for details and testcases.  The problem is > that calls aren't being preceded by instructions that put the > arguments into registers.  I backtracked my working copy and then > stepped forward

The current implementation of llvm::Mangler does not check if a symbol name exists before mangling. This can cause problems if the mangled name aliases another symbol in the IR. For example, consider the following: @"a(b" = addrspace(1) global float 1.0 @"a_28_b" = addrspace(1) global float 1.0 If I run this through the x86 backend, I get: llc:

Hello all, Is it well known that building LLVM with --enable-optimized causes RegisterPass calls to be removed from dynamically loadable libraries (i.e., those built with LOADABLE_MODULE=1)? For example, here's what happens to the Hello pass (ToT on Darwin, both with and without --enable-optimized): $ pwd /Users/ransford/llvm/lib/Transforms/Hello $ nm -j Release+Asserts/Hello.o | c++filt -p

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,

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

Hello, I just built a virgin ToT (r98634) for release on vanilla Snow Leopard. It seems that the Hello pass doesn't want to load because of undefined symbols: builddir% ../llvm/configure --prefix=$(PWD)/../installdir --enable-optimized builddir% make builddir% make install && cd ../installdir installdir% bin/opt -load lib/libLLVMHello.dylib Error opening

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:

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

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

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, 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&

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 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 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

Hello, Within the file "MSP430InstrFormats.td" there is a class called "MSP430Inst" which has "Instruction" as superclass. Within this class there is a field called "Inst" (field bits<16> Inst;) which gets assigned in classes which specifies a specific instruction format, e.g. IForm contains: let Inst{12-15} = opcode; let Inst{7} = ad.Value; let

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

On May 5, 2010, at 1:22 PM, Nathan Jeffords wrote: > On Wed, May 5, 2010 at 11:15 AM, Chris Lattner <clattner at apple.com> wrote: > On May 4, 2010, at 11:03 AM, Nathan Jeffords wrote: > ... We basically want one MCStreamer callback to correspond to one statement in the .s file. This makes it easier to handle from the compiler standpoint, but is also very important for the llvm-mc

Hi, I have the solution to my problem :). And the llvm gc infrastructure can work with the current MCJIT without any change (good news). I will explain what I have done to find the garbage collector metadata generated by llvm with MCJIT, I'm pretty sure that it could help someone. And it's very easy. You just have to activate a static gcprinter for the assembly. A very good example is

I have a case where I the expression (MCSymbolRefExpr) is the offset from the beginning of the section. The need is to combine that offset to the virtual address of the section it belongs, in this case .text, but it could be any section. I can get a MCSectionELF class object from MCSymbol that I get from MCSymbolRefExpr: int Kind = Value->getKind(); if (Kind == MCExpr::SymbolRef) {