Re: AS, and saving and restoring .cpu directive on ARM?

[Jeffrey Walton <noloader at gmail dot com>]

On Thu, Apr 20, 2017 at 11:18 AM, Nick Clifton <nickc@redhat.com> wrote:
>
>>      __inline unsigned int GCC_INLINE_ATTRIB
>>      CRC32B(unsigned int crc, unsigned char v)
>>      {
>>          unsigned int r;
>>          asm (".cpu generic+fp+simd+crc+crypto  \n"
>>               "crc32b %w2, %w1, %w0             \n"
>>               : "=r"(r) : "r"(crc), "r"((unsigned int)v));
>>          return r;
>>      }
>
>> 1) Does the .cpu directive need to be saved and restored in the inline
>> assembly block?
>
> Yes.  But ... since you have already specified that if this instruction
> is executed then runtime code has already checked and ensured that the
> hardware is present.  In which case it probably will not matter that you
> leave the .cpu directive in its altered state.

Thanks. I thought that might be the case, but I did not want to make any leaps.

>> 2) If so, then how do I do it under ARM?
>
> You can't. :-(
>
> Instead you will need a workaround.  Here are some suggestions:
>
>   * Compile the function in its own file.  That way it does not
>     matter that you do not restore the .cpu setting after
>     encoding the crc instruction.  Of course you lose the advantage
>     of inlining.
>
>   * If you know what the original .cpu settings were, then you can
>     always restore them afterwards.
>
>   * Construct the instruction by hand and insert it directly into the
>     assembler output.  This is a bit tedious, but code like this might
>     work:
>
>     unsigned int
>     CRC32B(unsigned int crc, unsigned char v)
>       {
>           unsigned int r;
>           asm (".set crcr2,2\n");
>           asm (".set crcr3,3\n");
>           asm (".inst (0x1ac04000 + crc%2 + (crc%1 << 5) + (crc%0 << 16))\n"
>              : "=r"(r) : "r"(crc), "r"((unsigned int)v));
>           return r;
>       }
>
>     The advantage here is that you do not need the .cpu directive to
>     select the desired architecture.

Thanks again. I'm testing the third method now.

I like the second method, but we have no idea what a user is going to
select as their CFLAGS or CXXFLAGS. It was the driving force behind
trying to save and restore .cpu.

We could not opt-in to the first method because of a C++ class
library. Some of this stuff is going into headers. And we don't want
to tell users to create two versions of some of their files and
compile with different settings.

Thanks again.

Jeff