Re: ARMv8, GCC 4.9 and necessary code optimized away?

[Andrew Haley <aph at redhat dot com>]

On 01/06/16 09:18, Jeffrey Walton wrote:
> On Wed, Jun 1, 2016 at 3:32 AM, Andrew Haley <aph@redhat.com> wrote:
>> On 31/05/16 21:37, Jeffrey Walton wrote:
>>>> Like Florian said, 'w' is not being used so the compiler may optimise the
>>>> whole sequence away.
>>>
>>> I'm pretty sure this is another instance of a language defect. The
>>> C/C++ language does not allow us to properly express ourselves, and
>>> the result is the removal of critical code.
>>
>> The problem here is that GCC knows that the CRC instructions have
>> no side effects beyond their operands.  So GCC doesn't generate
>> the instructions.
> 
> That's presuming some things that miss the mark in this case.
> 
> I'm still sorting it out in my mind, but ... Computer programs are
> code and data. Most of the time optimizers are correct in guessing
> that an unused result is dead and the accompanying code is dead. One
> of the most fundamental problems seems to be: why is all this guessing
> going on?

I don't think that there's any guessing going on at all.  The
processor and the language have their specifications.

> A memset to zeroize sensitive data in memory has both code and data.
> It needs to survive.
> 
> An statement to test for the presence of an instruction is only code.

This is a mistake by the programmer.  To test for the presence of an
instruction, they need to emit the instruction.  Asm statements do
that.

> It needs to survive.
> 
> A set of statements to flush cpu cache lines has both code and data.
> It needs to survive.
> 
> In all the cases, the C/C++ language does not allow me to express the
> code and sometimes the data needs to survive.

That is certainly true.  C and C++, like all programming languages,
deal in behaviour which is observable by programs.

The above cases are handled with assembly language, because their
effects are only observable at the machine level.  The memory
zeroing case, though, is more problematic.  I think volatile can
be used for that, though.

> At best, volatile is an abuse under GCC
> (http://www.airs.com/bl). At worst, its fragile and
> going to break in the future as GCC analysis gets better. And its only
> going to get trickier as link-time optimizations are added to the mix.

Probably.

>> In your case I'd just use the result as an input operand into an
>> asm.
> 
> Then I loose the portability of C/C++ and intrinsics.

I don't believe so.  But how much sense would it make?  You're testing
for the presence of a specific instruction, so you should use that
instruction.  Otherwise GCC might just emit a CRC subroutine.

> I'm trying to
> increase portability and reduce maintenance, not turn it on its head
> :)
> 
> Also, the inline assembler is not the easiest to work with, and its
> another can can of worms I prefer not to open. I'm still confounded by
> how difficult it is to use extended asm to save some registers,
> calculate a result, save the result and then pop the registers. I
> still can't figure out how to do it (the pain point is: save the
> result and then pop the registers).

Think of it as a learning opportunity.  I'm here to help.

Andrew.