llvm dev - Feb 2013 - [LLVMdev] Asm syntax of Mips m[tf]cX coprocessor instructions

Jeremy,

Could you send/attach a small test case that demonstrates the problem?

It doesn't need to go past the stage that creates a .o.

Also, what version of gnu as are you using?

Unless it conflicts with a fundamental llvm/clang philosophy, we are trying to
keep Mips assembly compatible with AS.

Also, keep in mind that the Mips llvm assembler is current development and is
not considered "prime time" for production. Thus, a test case is
always welcome.

Thanks,

Jack

On 02/08/2013 10:53 AM, Jeremy Fitzhardinge wrote:> Hi
all,
>
> I'm experimenting with compiling some Mips code which is normally built
> with a gcc cross toolchain with clang instead.  This code targets the
> Cavium Octeon, and uses some of that CPU's crypto engine features which
> are implemented in coprocessor 2.
>
> The inline asm for the crypto code uses instructions of the form
"dmtc2
> %0, 0xNNNN" - that is the coprocessor register is represented as a
> constant, which is the only syntax that gas seems to accept
> (specifically, an expression which evaluates to a constant).  Clang's
> integrated-as, however, only accepts "dmtc2 %0, $0xNNNN", that
is, a
> coprocessor register number.
>
> I think clang is correct here, but for cross-tool compatibility it would
> be useful if it could also accept the same syntax as gas.  I could hack
> up the Octeon SDK headers to switch syntax depending on the compiler,
> but I'd really prefer to avoid that (esp since it really depends on the
> assembler in use, and I'm not sure if there's preprocessor symbols
to
> detect whether integrated-as is enabled).
>
> I've had a look at Mips(64)InstrInfo.td which seems to be where the
> syntax is defined, but since this is my first encounter with
> clang/llvm's internals, I'm not sure how to go about making the
change.
> Could someone give me some pointers?  Is this something that InstAlias
> can handle?
>
> An alternative workaround would be to just use gas as-is, but it gets
> upset by the .cfi_section directives that clang emits.  Is there some
> way to suppress those (while keeping the rest of the cfi directives that
> this version of gas does understand)?
>
> Thanks,
>      J
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130208/0dde63f3/attachment.html>

On 02/08/2013 03:47 PM, Carter, Jack wrote:
> Jeremy,
>
> Could you send/attach a small test case that demonstrates the problem?
>
> It doesn't need to go past the stage that creates a .o.
>
> Also, what version of gnu as are you using?
>
> Unless it conflicts with a fundamental llvm/clang philosophy, we are
> trying to keep Mips assembly compatible with AS.
>
> Also, keep in mind that the Mips llvm assembler is current development
> and is not considered "prime time" for production. Thus, a test
case
> is always welcome.
Sure!

This file:

$ cat t.c
int foo()
{
	int c0;

	/* OK for clang */
	asm("dmfc2 %0,$1" : "=r" (c0));

	/* OK for gcc */
	asm("dmfc2 %0,1" : "=r" (c0));

	return c0;
}

produces:

$ mips64-octeon-linux-gnu-gcc -c t.c
t.s: Assembler messages:
t.s:19: Error: illegal operands `dmfc2 $1,$1'

$ clang -target mips64 -integrated-as -c t.c
t.c:9:6: error: invalid operand for instruction
        asm("dmfc2 %0,1" : "=r" (c0));
            ^
<inline asm>:1:11: note: instantiated into assembly here
        dmfc2 $1,1
                 ^

The assembler is from the Cavium Octeon SDK:

$ mips64-octeon-linux-gnu-as --version
GNU assembler (Cavium Networks Version: 2_2_0 build 113) 2.19
Copyright 2007 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `mips64-octeon-linux-gnu'.

I have not compared its behaviour with upstream gas (either the
equivalent version or a more recent one).

Thanks,

    J
>
> Thanks,
>
> Jack
>
> On 02/08/2013 10:53 AM, Jeremy Fitzhardinge wrote:> Hi all,
> >
> > I'm experimenting with compiling some Mips code which is normally
built
> > with a gcc cross toolchain with clang instead.  This code targets the
> > Cavium Octeon, and uses some of that CPU's crypto engine features
which
> > are implemented in coprocessor 2.
> >
> > The inline asm for the crypto code uses instructions of the form
"dmtc2
> > %0, 0xNNNN" - that is the coprocessor register is represented as
a
> > constant, which is the only syntax that gas seems to accept
> > (specifically, an expression which evaluates to a constant). 
Clang's
> > integrated-as, however, only accepts "dmtc2 %0, $0xNNNN",
that is, a
> > coprocessor register number.
> >
> > I think clang is correct here, but for cross-tool compatibility it
would
> > be useful if it could also accept the same syntax as gas.  I could
hack
> > up the Octeon SDK headers to switch syntax depending on the compiler,
> > but I'd really prefer to avoid that (esp since it really depends
on the
> > assembler in use, and I'm not sure if there's preprocessor
symbols to
> > detect whether integrated-as is enabled).
> >
> > I've had a look at Mips(64)InstrInfo.td which seems to be where
the
> > syntax is defined, but since this is my first encounter with
> > clang/llvm's internals, I'm not sure how to go about making
the change.
> > Could someone give me some pointers?  Is this something that InstAlias
> > can handle?
> >
> > An alternative workaround would be to just use gas as-is, but it gets
> > upset by the .cfi_section directives that clang emits.  Is there some
> > way to suppress those (while keeping the rest of the cfi directives
that
> > this version of gas does understand)?
> >
> > Thanks,
> >      J
> >
>