On Thu, Aug 21, 2014 at 12:34 PM, James Greenhalgh
<james.greenha...@arm.com> wrote:
>
> Hi,
>
> Andrew is quite right, we break the contract for volatile struct copies
> if we start double copying bytes.
>
> But, the generic code will call memcpy - at which point anything could
> happen. So, we must not put out a call to memcpy if either our source or
> destination operands are volatile. The same is true of memset, so also
> disable that call for volatile operands, and add a fallback loop
> implementation.
>
> Bootstrapped on x86, Arm and AArch64 with no issues.
>
> OK?
Umm... using a byte-wise clearing loop is surely always the wrong
thing for an access that _really_ cares about volatile.
I see we do the same for the block-move case... ugh.
I still say we need to solve the issue at language level - that is,
try to figure out what the language standard says about
volatile struct X x, y;
x = y;
or about
struct X { volatile int x; } x, y;
x = y;
where we don't even _have_ MEM_VOLATILE set on x or y.
I expect that most structs have volatile for a bogus reason
anyway and we slow down and enlarge code for no good reason.
So - why bother fixing this? ISTR reading in the C standard
that structure assignments are expected to compile to memcpy.
Richard.
> Thanks,
> James
>
> ---
> gcc/
>
> 2014-08-21 James Greenhalgh <james.greenha...@arm.com>
>
> * expr.c (set_storage_via_loop): New.
> (emit_block_move_hints): Do not call memcpy with volatile operands.
> (emit_block_move_via_movmem): Clarify that targets do have to care
> about volatile operands.
> (clear_storage_hints): Do not call memset for volatile operands,
> fall back to a loop implementation.
>
> gcc/testsuite/
>
> 2014-08-21 James Greenhalgh <james.greenha...@arm.com>
>
> * gcc.dg/large-volatile-struct-copy-1.c: New.
> * gcc.dg/large-volatile-struct-set-1.c: Likewise.
