similar to: [LLVMdev] -debug in make check

Hi Reed, > I'd like to have some .ll tests in make check where I verify that > certain DAG nodes are being processed. Normally I would compile with > -debug and look for them. > > Is it possible to scan the stdout instead of the .s file from a .ll in > make check? while it is possible, my understanding is that the output of -debug is not supposed to be stable, may change at

> > And in the test file there is a line: > > XFAIL: powerpc64, s390x, mips, sparc > > This is a crude attempt at "XFAIL: big-endian". The mips entry here is just > wrong if the system is little-endian - the test passes on little-endian machines > and fails on big-endian. This is obviously a problem. 'XFAIL: mips' counts as an XFAIL for all mips targets

If you can help get it working on big-endian systems, we should be able to remove the XFAIL. That seems like the cleanest way out of this. Yuchen sent a patch to llvm-commits on 12/19/13. (I can resend it to you if you don’t have that.) Can you try that out on a BE mips system? On Feb 21, 2014, at 7:11 AM, Reed Kotler <Reed.Kotler at imgtec.com> wrote: > On 02/21/2014 02:58 AM, Daniel

On 02/25/2014 02:38 PM, Eric Christopher wrote: > On Tue, Feb 25, 2014 at 2:32 PM, reed kotler <rkotler at mips.com> wrote: >> On 02/25/2014 09:30 AM, Richard Sandiford wrote: >>> reed kotler <rkotler at mips.com> writes: >>>> On 02/24/2014 04:42 PM, Eric Christopher wrote: >>>>> On Mon, Feb 24, 2014 at 4:40 PM, reed kotler <rkotler at

We are starting to move to using llvm/clang x86 as the starting point for mips native compilers. It's important to make sure that gcc cross compilers can do this too but sometimes there are issues there; especially now as c++11 is moving into the foreground. We are working to also make sure this works. As 3.5 llvm is probably around the corner; our use of clang/llvm for this starting

rkotler at mipsswbrd006-le:~/caviumllvm/build/test$ make Making LLVM 'lit.site.cfg' file... Making LLVM unittest 'lit.site.cfg' file... ( ulimit -t 600 ; ulimit -d 512000 ; ulimit -m 512000 ; ulimit -s 8192 ; \ /usr/bin/python /home/rkotler/workspace/llvm/utils/lit/lit.py -s -v . ) XPASS: LLVM :: tools/llvm-cov/llvm-cov.test (8916 of 9784) ******************** TEST

On 02/13/2014 11:35 AM, Tim Northover wrote: > Hi Reed, > >> but then many tests fail when i do a "make check" > > That's not normal (all tests pass for me on Linux and OS X). Is this > on your build machine, or a MIPS board with some odd > cross-compilation? The latter is more likely to have weird CMake > issues (I know AArch64 does if you're not

Is there a way to just run one test with "make check" for either the llvm or clang test suites? Tia. Reed

Not sure what you mean. I.OutOperandList == (outs CPU16Regs:$rx) I.InOperandList == (ins CPU16Regs:$ry, CPU16Regs:$rz) On 07/02/2012 09:26 PM, Sean Silva wrote: > I think you're missing the template args for `FRRR16_ins` in the first > argument. The switch in TGParser::ParseType() doesn't cover the case > of types with template args though... which makes me wonder what is

On 01/04/2013 06:08 PM, Eli Friedman wrote: > On Fri, Jan 4, 2013 at 4:08 PM, reed kotler <rkotler at mips.com> wrote: >> I'm working on mips16 hard float which at a first approximation is just soft >> float but calls different library routines. Those different library routines >> are just an implementation (in mips32 mode) of soft float using mips32 >>

On 01/08/2013 01:48 PM, Eli Friedman wrote: > On Mon, Jan 7, 2013 at 6:07 PM, reed kotler <rkotler at mips.com> wrote: >> For example: >> >> /home/rkotler/llvm/install/bin/llc -mcpu=mips16 hf16_2.ll -march=mipsel >> -relocation-model=pic -o hf16_2.s -O3 -mips16-hard-float -soft-float > Try something like the following: > > float f; > double test(void*

On 05/06/2013 04:23 PM, Eric Christopher wrote: > On Mon, May 6, 2013 at 3:08 PM, reed kotler <rkotler at mips.com> wrote: >> Hi Hal, >> >> >> I think that it's perfectly valid to generate inline assembler and it >> looks 1000 times cleaner than if I tried to do this same work with >> selection DAG. >> > I'm pretty sure you're the

On Fri, Jan 4, 2013 at 6:28 PM, reed kotler <rkotler at mips.com> wrote: > On 01/04/2013 06:08 PM, Eli Friedman wrote: >> >> On Fri, Jan 4, 2013 at 4:08 PM, reed kotler <rkotler at mips.com> wrote: >>> >>> I'm working on mips16 hard float which at a first approximation is just >>> soft >>> float but calls different library

I have a test that will only fail if I run clang and not if I run llc by itself but it's an llc issue. Where would I put such a test? Are there similar tests in the "make check" or "make check-all" suite? Tia. Reed

class FRRR16_ins<bits<2> _f, string asmstr, list<dag> pattern, InstrItinClass itin> : // ... This class has template args. You don't specify them in the first template arg of class ArithLogicR16<FRRR16_ins I, SDNode OpNode, bit isComm = 0>: // ... --Sean Silva On Tue, Jul 3, 2012 at 2:29 PM, reed kotler <rkotler at mips.com> wrote: > Not sure what you mean.

I think that what I did originally should have worked and the bug was correct as I reported it. Here is an alternate implementation which has the same problem. class ArithLogicRTest16<string I, SDNode OpNode, bit isComm = 0>: FRRR16<!cast<FRRR16_ins>(I).f, !cast<FRRR16_ins>(I).OutOperandList, !cast<FRRR16_ins>(I).InOperandList,

On 01/04/2013 07:45 PM, Eli Friedman wrote: > On Fri, Jan 4, 2013 at 6:28 PM, reed kotler <rkotler at mips.com> wrote: >> On 01/04/2013 06:08 PM, Eli Friedman wrote: >>> On Fri, Jan 4, 2013 at 4:08 PM, reed kotler <rkotler at mips.com> wrote: >>>> I'm working on mips16 hard float which at a first approximation is just >>>> soft

Hi Hal, I think that it's perfectly valid to generate inline assembler and it looks 1000 times cleaner than if I tried to do this same work with selection DAG. > I hope you don't mind if I play devil's advocate here... > > Why is this so complicated that it would be messy to do, at least in part, at a lower level? I can understand needing IR-level analysis for some kinds of

Geting a seg fault. Have not investigted the cause. rkotler at mipsswbrd002:~/richard$ tar vfxz ~/Downloads/ellcc-mips-linux-2014-Mar-24-07-32-26.tgz rkotler at mipsswbrd002:~/richard/ellcc/bin$ gdb ./ecc GNU gdb (GDB) 7.4.1-debian Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are

On 04/24/2013 07:39 PM, Chris Lattner wrote: > On Apr 24, 2013, at 6:27 PM, Reed Kotler <rkotler at mips.com> wrote: >> I would really push towards doing this in LLVM IR as the next step. > > What makes you say that? > >> It's possible that what you are proposing is the right "long term" solution but I think it's not a good evolutionary approach;