llvm dev - Sep 2010 - [LLVMdev] inline asm constraints examples/tests

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 my 64-bit Linux box.  However, it still has a problem
on 32-bit Windows and 32-bit Linux:

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, %reg16402<def>, 10, %reg16403<def>, 10,
%reg16404<def>,
10, %reg16405<def>, 10, %reg16406<def>, 10, %reg16407<def>,
2147483657,
%EAX, 2147549193, %ECX, 2147614729, %EDX, 2147680265, %ESI, 2147745801,
%EDI, 2147811337, %EBX, 2147876873, %EBP, 2147942409, %reg16403, 2148007945,
%reg16404, 2148073481, %reg16405, 2148139017, %reg16406, 2148204553,
%reg16407, 14, %EFLAGS<earlyclobber,imp-def>, <<badref>>;
GR32:%reg16396,16397,16398,16399,16400,16401,16402,16403,16404,16405,16406,16407,16403,16404,16405,16406,16407
For the code:

int a, b, c, d, e, f, g, h, i, j, k, l;
void
f1 (void)
{
  __asm__ volatile (""
      : [a] "+r" (a), [b] "+r" (b), [c] "+r" (c),
[d] "+r" (d),
        [e] "+r" (e), [f] "+r" (f), [g] "+r" (g),
[h] "+r" (h),
        [i] "+r" (i), [j] "+r" (j), [k] "+r" (k),
[l] "+r" (l));
}
This confused me since it doesn't use multiple-alternative constraints,
meaning it should fall back to the original logic.  I'm thinking this
problem probably isn't related to my code.  To try to confirm this, I built
an LLVM tree I had checked out on August 24 (rev 111968) and I see the same
error.

If you agree, I'll go ahead and check in my patches, and file a bug on the
above error.

The llvmmultalt8.patch and the clangmultalt8.patch files have a little extra
stuff I had just added previous to this, namely adding partial support for
the E, F, and p constraint characters I saw from the GCC docs, and which
should be benign.

Sorry for the hassle.

-John

On Tue, Sep 21, 2010 at 10:08 AM, Dale Johannesen <dalej at apple.com>
wrote:
>
>  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 install, which is trying to put it
> /usr/local/bin rather than /usr/bin like the package manager did, so I left
> it alone for now.  But the dejagnu tree is adjacent to the gcc test suite
> tree.  Should I try to resolve the install problems?  Running runtest
> --version:
>
> Expect version is 5.43.0
> Tcl version is 8.4
> Framework version is 1.4.99
>
> In my first run, only 95 tests passed, 516 unexpected failures, etc.  So
> either I still need some kind of configuration fix, or this particular snap
> of the tests doesn't work on my particular Linux box.  I'm using
the triple
> i386-unknown-linux in Daniel's makefile.
>
>
> There should be far more than 600 tests run, more like 40000 for C alone.
>  You're doing something basic wrong.
>
> I did ask you to run this before checking in your patch.  Please don't
> skimp on testing in the future.
>
>  I'm running the tests again adding the -v option to runtest to see if
> that gives me any more information, plus using the Release+Asserts version
> of the clang binaries.
>
> But I'm hoping you or Daniel can straighten me out.
> Thanks again,
>
> -John
> On Mon, Sep 20, 2010 at 4:46 PM, Stuart Hastings <stuart at
apple.com> wrote:
>
>>
>> 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
>
>
>
>
> --
> John Thompson
> John.Thompson.JTSoftware at gmail.com
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>

-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100921/4b033ab5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvmmultalt8.patch
Type: application/octet-stream
Size: 3223 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100921/4b033ab5/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: clangmultalt8.patch
Type: application/octet-stream
Size: 555 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100921/4b033ab5/attachment-0001.obj>

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, %reg16402<def>, 10,
%reg16403<def>, 10, %reg16404<def>, 10, %reg16405<def>, 10,
%reg16406<def>, 10, %reg16407<def>, 2147483657, %EAX, 2147549193,
%ECX, 2147614729, %EDX, 2147680265, %ESI, 2147745801, %EDI, 2147811337, %EBX,
2147876873, %EBP, 2147942409, %reg16403, 2148007945, %reg16404, 2148073481,
%reg16405, 2148139017, %reg16406, 2148204553, %reg16407, 14,
%EFLAGS<earlyclobber,imp-def>, <<badref>>;
GR32:%reg16396,16397,16398,16399,16400,16401,16402,16403,16404,16405,16406,16407,16403,16404,16405,16406,16407
> For the code:
>  
> int a, b, c, d, e, f, g, h, i, j, k, l;
> void
> f1 (void)
> {
>   __asm__ volatile (""
>       : [a] "+r" (a), [b] "+r" (b), [c] "+r"
(c), [d] "+r" (d),
>         [e] "+r" (e), [f] "+r" (f), [g] "+r"
(g), [h] "+r" (h),
>         [i] "+r" (i), [j] "+r" (j), [k] "+r"
(k), [l] "+r" (l));
> }
> This confused me since it doesn't use multiple-alternative constraints,
meaning it should fall back to the original logic.  I'm thinking this
problem probably isn't related to my code.  To try to confirm this, I built
an LLVM tree I had checked out on August 24 (rev 111968) and I see the same
error.
Yes, this test asks for 12 different registers, so there's no way it could
pass on x86-32, which has only 6 (at most).

Thanks, Dale.  I guess this also means I should be running the gcc tests in
x86-64 mode.  I'm giving that a spin on my Linux box.

Is Daniel going to package it up with a configure and so forth and make it
part of the Clang tests, or like the llvm test-suite?

Also, it would be really nice if the gcc tests could run on Windows, and
especially also the LLVM regression tests and projects/test-suite.  At
present, I develop on Windows and then copy a patch over to Linux, as using
command-line GDB is very painful for me

How do you guys debug on your systems?  Is there something comparible to the
Visual Studio debugger?  I've tried a few GDB GUI wrappers I found from
googling a while ago, but I couldn't get any of them to work well enough to
use.
-John
On Tue, Sep 21, 2010 at 2:58 PM, Dale Johannesen <dalej at apple.com>
wrote:
>
> 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, %reg16402<def>, 10, %reg16403<def>,
10, %reg16404<def>,
> 10, %reg16405<def>, 10, %reg16406<def>, 10,
%reg16407<def>, 2147483657,
> %EAX, 2147549193, %ECX, 2147614729, %EDX, 2147680265, %ESI, 2147745801,
> %EDI, 2147811337, %EBX, 2147876873, %EBP, 2147942409, %reg16403,
2148007945,
> %reg16404, 2148073481, %reg16405, 2148139017, %reg16406, 2148204553,
> %reg16407, 14, %EFLAGS<earlyclobber,imp-def>, <<badref>>;
>
GR32:%reg16396,16397,16398,16399,16400,16401,16402,16403,16404,16405,16406,16407,16403,16404,16405,16406,16407
> > For the code:
> >
> > int a, b, c, d, e, f, g, h, i, j, k, l;
> > void
> > f1 (void)
> > {
> >   __asm__ volatile (""
> >       : [a] "+r" (a), [b] "+r" (b), [c]
"+r" (c), [d] "+r" (d),
> >         [e] "+r" (e), [f] "+r" (f), [g]
"+r" (g), [h] "+r" (h),
> >         [i] "+r" (i), [j] "+r" (j), [k]
"+r" (k), [l] "+r" (l));
> > }
> > This confused me since it doesn't use multiple-alternative
constraints,
> meaning it should fall back to the original logic.  I'm thinking this
> problem probably isn't related to my code.  To try to confirm this, I
built
> an LLVM tree I had checked out on August 24 (rev 111968) and I see the same
> error.
>
> Yes, this test asks for 12 different registers, so there's no way it
could
> pass on x86-32, which has only 6 (at most).
>
>

-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100921/b28eae1e/attachment.html>

On Sep 21, 2010, at 2:45 PM, John Thompson wrote:
> 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 my 64-bit Linux box.
I don't have an opinion, as I haven't had time to look at the original
patch yet.  If it fixes the test failure on x86-64 and you are confident in it,
please go ahead and apply it.  In the clang tests you can force x86-64 by
specifying -mtriple.

-Chris