similar to: [LLVMdev] inline asm constraints examples/tests

Hi John, Have you looked at the GCC test suite? It certainly has some examples -- I know for sure because one of them is now failing with Clang after your recent patch. :) I have a hacked up version in the 'clang-tests' module in SVN which has been made a bit easier to run with clang. - Daniel On Mon, Sep 20, 2010 at 12:07 PM, John Thompson <john.thompson.jtsoftware at

Daniel, Sorry, I'm implementing the back-end support for multiple-alternative constraints in stages. I wouldn't expect any serious inline asm multiple alternative constraints tests to work yet, as a number of the constraint characters aren't implemented yet. I'll try to fix it so that it doesn't assert when unsupported constraints are used. Clang may have passed parsing

Thanks, Stuart. Sorry, I had some left-over editing cruft in my email. >From Googling runtest, I had found dejagnu, which I'd heard some folks were using over there, so I used the local package manager to install it. But from what you said I went ahead and got the dejagnu sources and built it, but had problems in running make install, which is trying to put it /usr/local/bin rather than

On Sep 20, 2010, at 9:40 PMPDT, John Thompson wrote: > Thanks, Stuart. Sorry, I had some left-over editing cruft in my email. From Googling runtest, I had found dejagnu, which I'd heard some folks were using over there, so I used the local package manager to install it. But from what you said I went ahead and got the dejagnu sources and built it, but had problems in running make

I'm trying to fix the handling of multiple alternate constraints in Clang (see http://gcc.gnu.org/onlinedocs/gcc/Multi_002dAlternative.html#Multi_002dAlternative ). How should the constraints be represented in the .ll file? Clang currently will assert because the code generator sees a constraints string with the wrong number of comma-separated items. Basically, after some editing, it just

The LLVM asm parser doesn't support multiple alternative constraints; you need to have Clang pick one tuple in the front end. See ChooseConstraintTuple in llvm-gcc for prior art. On Jul 29, 2010, at 11:36 AMPDT, John Thompson wrote: > I'm trying to fix the handling of multiple alternate constraints in > Clang (see

Dale, Sorry, I see you did say I should run the gcc tests. I apologize for forgetting this. I'll work on getting them to run here. Chris et. all, I have a fix for the assertion failure in the enclosed llvmmultalt8.patch file. I didn't realize the input constraints could have different numbers of alternatives from the outputs, which now makes sense. The pr20314-2.c file now compiles

On Sep 20, 2010, at 4:38 PM, John Thompson wrote: [snip] > I just tried running the gcc tests, but am missing "runtest". http://www.gnu.org/software/dejagnu/ Follow the directions there. I think the GCC test suite wants DejaGNU to be installed in a sibling directory, adjacent to the llvm-gcc or clang toplevel. HTH, stuart

Actually the 2.8 fork is coming up tomorrow and I'm thinking maybe we should wait until after that. Is this something you really want to get in 2.8? On Sep 1, 2010, at 6:29 PMPDT, John Thompson wrote: > Dale, > > Thanks. It's not changed, but I've enclosed a fresh patch against > today's trunk. > However, I'm seeing 28 unexpected failing tests in

Dale, Thanks. It's not changed, but I've enclosed a fresh patch against today's trunk. However, I'm seeing 28 unexpected failing tests in llvm/test on x86 Linux 64 today. But it's the same on an unmodified tree, so I guess I'm still okay. It passed at one point for me with these changes. -John On Wed, Sep 1, 2010 at 5:04 PM, Dale Johannesen <dalej at apple.com>

On Sep 1, 2010, at 11:03 AMPDT, John Thompson wrote: > I'm close to confirming that I get the equivalent results from the > test-suite with my changes, compared to a fresh tree, on a Linux x86 > 64 bit box. > > When that is the case, may I check in my current changes for the > LLVM side? In principle, yes, I'd like to rereview if it's changed. > My

I'm close to confirming that I get the equivalent results from the test-suite with my changes, compared to a fresh tree, on a Linux x86 64 bit box. When that is the case, may I check in my current changes for the LLVM side? My preference is to develop the mult-alt support incrementally, rather than one big check-in, as I get nervous sitting on a lot of changes for a long time. I feel this

On Aug 30, 2010, at 3:11 PMPDT, John Thompson wrote: > Dale, > > I took a closer look at the first llc failure, initp1. Looking at > the initp1.llc file in gdb, it appears that the statically > constructed objects without the init_priority attribute are being > constructed before those with it, though the test seems to expect > the opposite. > > The

Dale, I took a closer look at the first llc failure, initp1. Looking at the initp1.llc file in gdb, it appears that the statically constructed objects without the init_priority attribute are being constructed before those with it, though the test seems to expect the opposite. The initp1.llc.s file seems to have the .ctors table in the right order, but the _init code is reading the table in

On Sep 21, 2010, at 2:45 PMPDT, John Thompson wrote: > fatal error: error in backend: Ran out of registers during register allocation! > Please check your inline asm statement for invalid constraints: > INLINEASM <es:>, 0, 10, %reg16396<def>, 10, %reg16397<def>, 10, %reg16398<def>, 10, %reg16399<def>, 10, %reg16400<def>, 10, %reg16401<def>,10,

CBE is fairly broken everywhere AFAIK, don't worry about it. Most of the JIT failures are in tests that exercise exception handling. Not sure if that is supposed to work in your environment, it works in some JITs and not others. The LLC failures are cause for concern. On Aug 30, 2010, at 10:59 AMPDT, John Thompson wrote: > Dale, > > Thanks for reviewing this. > > I have

Dale, Thanks for reviewing this. I have some newbie questions regarding the test-suite for you or anyone: I'm trying to run the test-suite as described in the "LLVM Testing Infrastructure Guide" on a Ubuntu x86 64 bit system. Initially I ran into problems with missing tools like yacc, which I fixed as I went along until the make at the test-suite level completed. However, I get

Dale, I've looked a bit at ChooseConstraintTuple in llvm-gcc, as well as the code generator in Clang and the inline asm handling in LLVM (ala visitInlineAsm). While I see how Clang could do it to some extent by looking at the expression types of the operands, it seems that LLVM would be in a better position for choosing multiple alternative constraints as it would know what all the operands

Hi, I'm looking for some feedback on the changes represented in the attached patches, which I'll describe below. I'm sending this to both the LLVM and Clang list because it affects both, though the main focus here is LLVM. Basically, I've partially implemented some changes for choosing multiple alternative constraints largely on the LLVM side. The Clang change is to output the

On Aug 25, 2010, at 12:45 PM, John Thompson wrote: > Hi, > > I'm looking for some feedback on the changes represented in the > attached patches, which I'll describe below. > > I'm sending this to both the LLVM and Clang list because it affects > both, though the main focus here is LLVM. > Basically, I've partially implemented some changes for choosing