llvm dev - Jun 2011 - [LLVMdev] ARM thumb-2 instruction used for non-thumb2 CPUs

On Jun 22, 2011, at 9:00 AM, Renato Golin wrote:
> On 22 June 2011 16:50, Jim Grosbach <grosbach at apple.com> wrote:
>>> This sounds like a dead end as newer binutils are GPLv3.
>> 
>> Yeah, that's definitely a very real concern and a big motivation to
get the MC based asm parser whipped into usable shape. We're much more in
control of our own destiny then.
> 
> So, how do we solve the problem until then?
In general, it's a tricky thing. If it were only a few instructions, we
could just switch to the older mnemonic as a special case w/ a FIXME saying that
we should change it when newer assemblers become available on FreeBSD.
That's unfortunately not really the case, though. For example, all of the
VFP instructions use newer mnemonics, and the predicated condition code setting
arithmetic instructions have changed the order of the 's' and
'cc' suffices (e.g., addseq vs. addeqs).

I suspect we'll care about all of them, as we're wanting to handle
userspace apps, not just kernel code, here, right? This is the system assembler
that's too old.

If so, the best answer is to teach the assembler the new mnemonics. To help with
that, the majority of the work for v7 was released under GPLv2, even though it
didn't make it into an official binutils release until post-v3 changeover.
There are GPLv2 CodeSourcery drops which contain v7 support, for example,
including binutils support for unified syntax. While there are some bugs (Anton
can probably give more details), they do generally work and would likely provide
a good starting point so that the support wouldn't have to be done from
scratch.

-Jim

On Jun 22, 2011, at 6:15 PM, Jim Grosbach wrote:
> 
> On Jun 22, 2011, at 9:00 AM, Renato Golin wrote:
> 
>> On 22 June 2011 16:50, Jim Grosbach <grosbach at apple.com>
wrote:
>>>> This sounds like a dead end as newer binutils are GPLv3.
>>> 
>>> Yeah, that's definitely a very real concern and a big
motivation to get the MC based asm parser whipped into usable shape. We're
much more in control of our own destiny then.
>> 
>> So, how do we solve the problem until then?
> 
> In general, it's a tricky thing. If it were only a few instructions, we
could just switch to the older mnemonic as a special case w/ a FIXME saying that
we should change it when newer assemblers become available on FreeBSD.
That's unfortunately not really the case, though. For example, all of the
VFP instructions use newer mnemonics, and the predicated condition code setting
arithmetic instructions have changed the order of the 's' and
'cc' suffices (e.g., addseq vs. addeqs).
> 
> I suspect we'll care about all of them, as we're wanting to handle
userspace apps, not just kernel code, here, right? This is the system assembler
that's too old.
> 
> If so, the best answer is to teach the assembler the new mnemonics. To help
with that, the majority of the work for v7 was released under GPLv2, even though
it didn't make it into an official binutils release until post-v3
changeover. There are GPLv2 CodeSourcery drops which contain v7 support, for
example, including binutils support for unified syntax. While there are some
bugs (Anton can probably give more details), they do generally work and would
likely provide a good starting point so that the support wouldn't have to be
done from scratch.
I will try to find those pre-v3 patches.

In meantime I wrote a patch which changes to old mnemonics for shift
instructions.
This fixes compiling on the freebsd.

--- a/contrib/llvm/lib/Target/ARM/InstPrinter/ARMInstPrinter.cpp
+++ b/contrib/llvm/lib/Target/ARM/InstPrinter/ARMInstPrinter.cpp
@@ -44,17 +44,18 @@ void ARMInstPrinter::printInst(const MCInst *MI, raw_ostream
&O) {
     const MCOperand &MO2 = MI->getOperand(2);
     const MCOperand &MO3 = MI->getOperand(3);
 
-    O << '\t' <<
ARM_AM::getShiftOpcStr(ARM_AM::getSORegShOp(MO3.getImm()));
+    O << '\t' << "mov";
     printSBitModifierOperand(MI, 6, O);
     printPredicateOperand(MI, 4, O);
 
     O << '\t' << getRegisterName(Dst.getReg())
-      << ", " << getRegisterName(MO1.getReg());
+      << ", " << getRegisterName(MO1.getReg())
+      << ", " <<
ARM_AM::getShiftOpcStr(ARM_AM::getSORegShOp(MO3.getImm()));;
 
     if (ARM_AM::getSORegShOp(MO3.getImm()) == ARM_AM::rrx)
       return;
 
-    O << ", ";
+    O << " ";
 
     if (MO2.getReg()) {
       O << getRegisterName(MO2.getReg());

On Jun 22, 2011, at 10:03 AM, Damjan Marion wrote:
> 
> On Jun 22, 2011, at 6:15 PM, Jim Grosbach wrote:
> 
>> 
>> On Jun 22, 2011, at 9:00 AM, Renato Golin wrote:
>> 
>>> On 22 June 2011 16:50, Jim Grosbach <grosbach at apple.com>
wrote:
>>>>> This sounds like a dead end as newer binutils are GPLv3.
>>>> 
>>>> Yeah, that's definitely a very real concern and a big
motivation to get the MC based asm parser whipped into usable shape. We're
much more in control of our own destiny then.
>>> 
>>> So, how do we solve the problem until then?
>> 
>> In general, it's a tricky thing. If it were only a few
instructions, we could just switch to the older mnemonic as a special case w/ a
FIXME saying that we should change it when newer assemblers become available on
FreeBSD. That's unfortunately not really the case, though. For example, all
of the VFP instructions use newer mnemonics, and the predicated condition code
setting arithmetic instructions have changed the order of the 's' and
'cc' suffices (e.g., addseq vs. addeqs).
>> 
>> I suspect we'll care about all of them, as we're wanting to
handle userspace apps, not just kernel code, here, right? This is the system
assembler that's too old.
>> 
>> If so, the best answer is to teach the assembler the new mnemonics. To
help with that, the majority of the work for v7 was released under GPLv2, even
though it didn't make it into an official binutils release until post-v3
changeover. There are GPLv2 CodeSourcery drops which contain v7 support, for
example, including binutils support for unified syntax. While there are some
bugs (Anton can probably give more details), they do generally work and would
likely provide a good starting point so that the support wouldn't have to be
done from scratch.
> 
> I will try to find those pre-v3 patches.
> 
> In meantime I wrote a patch which changes to old mnemonics for shift
instructions.
> This fixes compiling on the freebsd.
If this is really the only issue you're seeing, we may be lucky and your
binutils already have support for lots of the changes necessary to handle llvm
assembly. Let's cross our fingers that's the case.
> 
> --- a/contrib/llvm/lib/Target/ARM/InstPrinter/ARMInstPrinter.cpp
> +++ b/contrib/llvm/lib/Target/ARM/InstPrinter/ARMInstPrinter.cpp
> @@ -44,17 +44,18 @@ void ARMInstPrinter::printInst(const MCInst *MI,
raw_ostream &O) {
>     const MCOperand &MO2 = MI->getOperand(2);
>     const MCOperand &MO3 = MI->getOperand(3);
> 
> -    O << '\t' <<
ARM_AM::getShiftOpcStr(ARM_AM::getSORegShOp(MO3.getImm()));
> +    O << '\t' << "mov";
>     printSBitModifierOperand(MI, 6, O);
>     printPredicateOperand(MI, 4, O);
> 
>     O << '\t' << getRegisterName(Dst.getReg())
> -      << ", " << getRegisterName(MO1.getReg());
> +      << ", " << getRegisterName(MO1.getReg())
> +      << ", " <<
ARM_AM::getShiftOpcStr(ARM_AM::getSORegShOp(MO3.getImm()));;
> 
>     if (ARM_AM::getSORegShOp(MO3.getImm()) == ARM_AM::rrx)
>       return;
> 
> -    O << ", ";
> +    O << " ";
> 
>     if (MO2.getReg()) {
>       O << getRegisterName(MO2.getReg());

Does your assembler support the other shift mnemonics (e.g., "LSL")?
This will change the output for all of them.

-Jim