https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79649
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
clear_storage_hints has
if (CONST_INT_P (size)
&& targetm.use_by_pieces_infrastructure_p (INTVAL (size), align,
CLEAR_BY_PIECES,
optimize_insn_for_speed_p ()))
clear_by_pieces (object, INTVAL (size), align);
else if (set_storage_via_setmem (object, size, const0_rtx, align,
expected_align, expected_size,
min_size, max_size, probable_max_size))
;
else if (ADDR_SPACE_GENERIC_P (MEM_ADDR_SPACE (object)))
return set_storage_via_libcall (object, size, const0_rtx,
method == BLOCK_OP_TAILCALL);
else
gcc_unreachable ();
not sure if we can rely on the FEs never emitting memset() or = {} for
objects in non-default address-space. We can't:
struct A { unsigned char a[256]; } __seg_gs a;
void foo ()
{
a = (struct A){};
}
ICEs with -O0 for example.
Note it is loop distribution pattern detection that creates a memset out of
your loop and yes, that's probably something we should avoid if the memory
involves non-generic address-spaces (well, just to make our live easier).
I am testing a patch for the loop distribution issue. Leaving the generic
middle-end issue to somebody else (eventually the generic storage copying
routines used by memcpy / memmove expansion have the same issue).
