search for: ransford

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

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

...l 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 | grep llvm::RegisterPass $ nm -j Debug+Asserts/Hello.o | c++filt -p | grep llvm::RegisterPass llvm::RegisterPass<(anonymous namespace)::Hello>::RegisterPass llvm::RegisterPass<(anonymous namespace)::Hello>::Register...

...TableGen. I have tried removing the field and it is at least still possible to run llc on a simple input file. This leads to a couple of questions: 1. Is this field redundant or does it have some use which I have missed? 2. What is the status of the MSP430 backend? In a mail from 2012 (http://lists.ransford.org/pipermail/llvm-msp430/2012-February/000194.html) Anton indicates that it is usable but is it a good basis for backend studies? My goal is to implement support for a new target and one step on the way is to fully understand how one of the existing backends work. Thanks David

...for debugging this? My install went fine except for some failures during make check (Unexpected Failures: 92). All failures were in one of the following: LLVM::FrontendC++ LLVM::FrontendC LLVM::FrontendObjC++ LLVM::FrontendObjC LLVM::Transforms Thanks, Scott On Tue, Mar 16, 2010 at 9:24 AM, Ben Ransford <ransford at cs.umass.edu> wrote: > 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 --...

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

...can replace the commercial and open-source compilers (IAR, CCE, CrossWorks, mspgcc, and so on) that people use. I've created a mailing list where we can have graphic, detailed discussions of the MSP430 and its LLVM backend. Feel free to subscribe for discussion and/or lurking. http://lists.ransford.org/mailman/listinfo/llvm-msp430 We'll try to redirect questions to llvmdev if they aren't MSP430 specific. -ben

...moving the field and it is at > least still possible to run llc on a simple input file. This leads to > a couple of questions: > 1. Is this field redundant or does it have some use which I have missed? > 2. What is the status of the MSP430 backend? In a mail from 2012 > (http://lists.ransford.org/pipermail/llvm-msp430/2012-February/000194.html) > Anton indicates that it is usable but is it a good basis for backend > studies? > > My goal is to implement support for a new target and one step on the > way is to fully understand how one of the existing backends work. > &...

Hello, This patch against svn r82147 "fixes" PR4776. Certain targets (e.g., MSP430) allow a symbol to start with a number, e.g. "0x0021"; you can say stuff like "mov.b &0x0021, r15" to copy a byte from memory address 0x0021 to register r15. LLVM had been generating this ill-formed code instead: mov.b &_30_x0021, r15 # note ASCII '0' has