middle-end: Prefer no RMW in __builtin_clear_padding implementation where possible

middle-end: Prefer no RMW in __builtin_clear_padding implementation where possible

Currently the __builtin_clear_padding expansion code emits no code for
full words that don't have any padding bits, and most of the time if
the only padding bytes are from the start of the word it attempts to merge
them with previous padding store (via {}) or if the only padding bytes are
from the end of the word, it attempts to merge it with following padding
bytes.  For everything else it was using a RMW, except when it found
an aligned char/short/int covering all the padding bytes and all those
padding bytes were all ones in that store.

The following patch changes it, such that we only use RMW if the padding has
any bytes which have some padding and some non-padding bits (i.e. bitfields
are involved), often it is the same amount of instructions in the end and
avoids being thread-unsafe unless necessary (and avoids having to wait for
the reads to make it into the CPU).  So, if there are no bitfields,
the function will just store some zero bytes, shorts, ints, long longs etc.
where needed.

2020-11-24  Jakub Jelinek  <jakub@redhat.com>

	* gimple-fold.c (clear_padding_flush): If a word contains only 0
	or 0xff bytes of padding other than all set, all clear, all set
	followed by all clear or all clear followed by all set, don't emit
	a RMW operation on the whole word or parts of it, but instead
	clear the individual bytes of padding.  For paddings of one byte
	size, don't use char[1] and {}, but instead just char and 0.