similar to: [LLVMdev] Running CodeGen/Generic tests on different targets

Inspired by the dicussion of removing IA64, I just tried running llc over test/CodeGen/Generic targeting all the legal values of -march and counting the number of crashes and aborts, as an attempt to roughly measure the maturity/bitrottedness of the backends. I went through and fixed some easy legalization issues; the following is the remaining issues: x86-64: 3. I'm not entirely sure

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

Hi all, *TL;DR:* I have a target TMS9900CodeGen but cmake is looking for LLVMTMS9900 or LLVMTMS9900CodeGen which I don't have, and cmake dies. But the MSP430 target doesn't have that either, and cmake is happy with it. What am I missing? *The premise:* I may be making a huge mistake, but I'm trying to develop an LLVM backend. I'm writing up some notes while I do so, and I hope

On Tue, Feb 24, 2009 at 06:24:17PM -0800, Julien Lerouge wrote: > I haven't tested with objdir != srcdir. Ok, that was broken. Attached is a smaller diff that should work in all cases. Julien -- Julien Lerouge PGP Key Id: 0xB1964A62 PGP Fingerprint: 392D 4BAD DB8B CE7F 4E5F FA3C 62DB 4AA7 B196 4A62 PGP Public Key from: keyserver.pgp.com -------------- next part -------------- Index:

Hello, The attached patch adds the jcheck target equivalent to make check, but that can run with a -j flag ($ make jcheck -jX). It does not interfere with the regular check, but rather builds on top of the check-one target: it first generates a list of tests to run using RunLLVMTests, and then run those tests according to the supplied -j flag, invoking the check-one target for each one of them.

As part of trying to fix PR30610 (ThinLTO with module inline asm), I wanted to add an assert that we have a Target and an MCAsmParser when we have non-null module inline asm in IRObjectFile::CollectAsmUndefinedRefs. Otherwise it silently fails to parse the module inline asm, which I initially found when trying to add an 'opt' based test for my fix (because 'opt' wasn't

> 1. TI MSP430. http://en.wikipedia.org/wiki/TI_MSP430 I'm also very interested in an msp430 backend. I had been considering seeing if I could hack out a first draft over winter break. This would be very useful to one of my students who is currently stuck doing things in gcc. The msp430 port of gcc is not closely maintained and seems quite buggy. > 2. ARM Cortex M3. This would

Hey all, Quick query on out of tree target support - at present I can drop a folder Foo into <llvm>/lib/Target/Foo and use the CMake option LLVM_EXPERIMENTAL_TARGETS_TO_BUILD to pick up my target. The issue is that I still need to patch the one LLVMBuild.txt file in <llvm>/lib/Target with; |iff --git a/lib/Target/LLVMBuild.txt b/lib/Target/LLVMBuild.txt index 4112046..6e42cbe

On Wed, Feb 25, 2009 at 12:02:18PM -0800, Julien Lerouge wrote: > For 2), I think the NewNightlyTest.pl script would require some small > changes, to invoke the jcheck target instead of check, pass the desired > -j flag, and also parse the log. I'll take a look. In any case, the > changes would only apply to the DejaGNU tests (llvm-test already works > fine with -jX). Here is

Is anyone working on supporting additional targets used in embedded systems. I am particularly interested in two: 1. TI MSP430. http://en.wikipedia.org/wiki/TI_MSP430 A nice very low power 16-bit machine with a PDP-11-like instruction set. We can assume the PIC16 developers have found and fixed all the 32-bit assumptions in the code base. Newer versions, the MSP430X series, have

Now, I've no spaces in my path: ------------------ $ echo $PATH .:/usr/local/bin:/mingw/bin:/bin:/mingw/bin:/usr/bin:/c/LLVM/tools:/c/perl/5.8.5/bin:/c/perl/5.8.5/bin/MSWin32-x86-multi-thread ------------------ I've found that you safely can delete site.exp. The new values in site.exp are: ------------------ ## these variables are automatically generated by make ## # Do not edit here.

Hello everyone, I'm wrestling with the LLVM unit and regression tests now and would like to discuss some changes to make. I will be preparing patches, but any input/ideas are welcome. I leave "where the tests should run" question out for the scope yet. Let's review what kind of tests we have and how to handle them correctly. We have 3 types of unit and regression tests: 1.)

On Fri, 7 Jan 2005, Henrik Bach wrote: > I'm trying to test the llvm tools as described in > 'http://llvm.cs.uiuc.edu/docs/TestingGuide.html'. The problem here is that your PATH envvar has spaces in it. There are many thing in LLVM that won't work with that, please try pruning your PATH and trying again. Thanks, -Chris > However, when running the command: 'make

I believe we'd need LLVMBuild.txt even in autoconf build - for bunch of autogenerated stuff, e.g. list of all asmprinters / asmparsers / InitializeAllTargetInfos, etc., since targets are not autoregistered anymore. On Mon, Mar 9, 2015 at 7:20 PM, Eric Christopher <echristo at gmail.com> wrote: > Hi Neil, > > Weird, I'd think the cmake build should probably do something

Hi, I'm trying to test the llvm tools as described in 'http://llvm.cs.uiuc.edu/docs/TestingGuide.html'. However, when running the command: 'make check VERBOSE=1 2>&1' I get this error: ------------------- if test -d "/C/projects/build/MinGW/llvm-2-1/test" ; then \ if test -f "/C/projects/build/MinGW/llvm-2-1/test/Makefile" ; then \ echo

Any progress on the TI MSP430 target?

The architecture that I'm targeting with an LLVM back end has SRA instructions for all its data sizes, but is missing SRL instructions for some data sizes. I'm having trouble with the SelectionDAGISel::ShrinkDemandedOps() pass. Although it runs after the DAG has been legalized, it replaces legal SRAs with illegal SRLs, which results in failures in instruction selection. Is there a

From http://www.llvm.org/docs/TestingGuide.html#quickdejagnu : To run only a subdirectory of tests in llvm/test using DejaGNU (ie. Transforms), just set the TESTSUITE variable to the path of the subdirectory (relative to llvm/test): % gmake TESTSUITE=Transforms check On 17-Jun-09, at 1:33 PM, Aaron Gray wrote: > Does 'make check' allow just running on a particualar directory of

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