similar to: [LLVMdev] Problem with callstack/frame-index

It just occured to me that perhaps what happens is that since the cmp-instruction is initially followed by the pseudo-instruction - which doesn't have Uses = [CFR] - that it's marked dead initially, and never changed back when the SKIPCOND is inserted by the custom emitter? But I feel that this would happen in e.g. MSP430 too then... On Wed, Dec 15, 2010 at 10:14 AM, Anton Korobeynikov

On 2011-03-09 02:51, Bill Wendling wrote: > There are LLVM 2.9 RC1 pre-release tarballs source available. You can find them here: > llvm 2.9rc1 test on Dualcore ARM running Ubuntu Natty gunzip llvm-2.9rc1.src.tar.gz tar zxvf llvm-2.9rc1.src.tar cd llvm-2.9-build ../llvm-2.9rc1/configure --enable-shared time make clean ;time make CXXFLAGS=-marm CFLAGS=-marm xranby at

Hi Gents, For those of us with out-of-tree backends which are not 32bit, the msp430 backend is a useful vehicle for examining changes and testing out ideas. So I was wondering about enabling debug output on the MSP430 backend so that I can illustrate a few issues to Adrian and you on the variable pieces side. (there doesn't appear to be any specific person claiming the msp430 code right

Hello, I have a user asking about msp430 support for Zig. When they try to target msp430, this error is triggered: if (target_machine->addPassesToEmitFile(MPM, dest, ft)) { *error_message = strdup("TargetMachine can't emit a file of this type"); return true; } I tried using clang alone: clang -c add.c -target msp430-unknown int add(int

Hi I'm doing a port of Clang/LLVM - purely for the educational value - to the MC6809 (and HD6309 as a dub target) processors. I'll also want to eventually provide direct support for the AM9511 floating-point coprocessor as an option. I'm working with bleeding-edge code from the Git mirror. I've made some pretty decent progress; I copied the llvm/lib/Targets/MSP430 Target to

Hello, While trying to find out why the LDC compiler refuses to generate object code for MSP430 targets (but generates MSP430 assembly or LLVM IR/bitcode), I came across the following apparent inconsistency. This works: $ clang --target=msp430 -c test.c This doesn't work: $ clang --target=msp430 -S -emit-llvm test.c $ llc -filetype=obj test.ll /opt/msp430/bin/llc: target does not support

Hello, Several people have expressed interest in using LLVM to target MSP430 microcontrollers. Anton wrote an MSP430 backend as an exercise, and some of the nastiest parts are done (thanks Anton!), but the consensus seems to be that there's still quite a bit of work left to do before LLVM can replace the commercial and open-source compilers (IAR, CCE, CrossWorks, mspgcc, and so on) that

On Thu, Jul 6, 2017 at 1:35 AM, Nicholas Wilson < iamthewilsonator at hotmail.com> wrote: > Luís, try using the -no-integrated-as flag to execute the assembler for > you. > We should probably make that the default for MSP430. > Cool. When I did that on macOS, LDC generated a lot of complaints, possibly because it is assuming mach-o files. I tried changing from -mtriple=msp430

On Thu, Jul 6, 2017 at 2:19 AM, Tim Northover <t.p.northover at gmail.com> wrote: > On 5 July 2017 at 17:51, Luís Marques via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > Cool. When I did that on macOS, LDC generated a lot of complaints, > possibly > > because it is assuming mach-o files. I tried changing from > -mtriple=msp430 > > to

On Aug 14, 2012, at 2:05 PM, Steve Montgomery <stephen.montgomery3 at btinternet.com> wrote: > Further to my earlier question, I'm perhaps a bit confused about memory serialisation. The following example, compiled using clang for the MSP430: > > target datalayout = "e-p:16:16:16-i8:8:8-i16:16:16-i32:16:32-n8:16" > target triple = "msp430-??-??" >

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

What guarantees, if any, does the scheduler make when two selection nodes are linked by a Flag type? Can I expect the machine instructions that are selected from the two nodes to be scheduled consecutively? I'm trying to implement code generation for SELECT_CC nodes in a back end that I'm working on. The compare operations on the architecture communicate via bits in a global status

In SelectionDAGBuilder::visitRet(), there is this bit of code: // FIXME: C calling convention requires the return type to be promoted // to at least 32-bit. But this is not necessary for non-C calling // conventions. The frontend should mark functions whose return values // require promoting with signext or zeroext attributes. if (ExtendKind !=

The Inst field is used to specify instruction encodings, which are then used to generate assemblers and disassemblers. I'm not sure offhand, but it's possible that the MSP430 backend doesn't make use of an auto-generated assembler. --Owen On Jul 21, 2013, at 4:19 PM, David Wiberg <dwiberg at gmail.com> wrote: > Hello, > > Within the file

When building with Clang for the MSP430 architecture against headers distributed with TI MSP GCC, interrupt service routine interrupt(vector_number) attribute is rejected: __attribute__ ((interrupt(USCI_A0_VECTOR))) void ISR(void) { } error: 'interrupt' attribute parameter 48 is out of bounds This is due to the check in tools/clang/lib/Sema/SemaDeclAttr.cpp:5104 unsigned Num

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> <font size="-1"><font face="Verdana">wow!!! i would be interested in trying

> At -O0, you don't. __mulsi3 is the obvious lowering, and you're doing > something wrong if your tools don't provide it. MSP430 is 16 bit target, so mulsi is a bit expensive there, mulhi / mulqi can be implemented via hardware multiplier. There are several problems wrt 16 bit support inside LLVM in general and msp430 in particular: 1. In some places LLVM expectes 32 bit or 64

Hello > inline asm code is like below: > > void test(unsigned short a) { >    asm("myinstr          my16bitreg, %0"::"r"(a)); > } > I want it generate instruction "myinstr          my16bitreg, r15" > > I execute > llc test.bc -march = msp430 -o test.s > then it reports > "LLVM ERROR: Couldn't allocate input reg for constraint

Hi David, Thank you for your patience but I still don’t get it: I don’t see how that is a “command”, as it’s just a list of strings that state command options. I know how to use the debugger, this is what I attempt to debug: clang --target=msp430 -emit-llvm -c -S -Oz main.c The debugger works fine, but only on the main thread. However breakpoints do not work with the code that was invoked

While migrating my codebase from llvm-2.6 to llvm-2.7, I found a different behaviour in the register allocation. I have been able to reproduce it using the msp430 backend, with the 2.7 release as well as the svn head. For the msp430, the first four parameters of a function are passed thru registers. What I observe is that if those parameters are not used inside the function, those registers can