> On Oct 14, 2021, at 12:02 PM, Qing Zhao via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
>
>>
>> For !is_gimple_reg vars, yes, something like clear_padding_type_has_padding_p
>> could be useful to avoid unnecessary IL growth, but it should be implemented
>> more efficiently,
Another thought on this:
The current “clear_padding_type_may_have_padding_p” might be enough, no need
for a new
“clear_padding_type_has_padding_p”.
The reason is: the computation to decide whether the type has padding is
unavoidable.
If we just use “clear_padding_type_may_have_padding_p”, then the computation to
decide
the type has padding is done by “gimple_fold_builtin_clear_padding”;
The new “clear_padding_type_has_padding_p” just move this computation from
“gimple_fold_builtin_clear_padding” to
this new routine. No actual compilation time can be saved.
Qing
>
> You mean the following is not efficient enough:
>
> /* Return true if TYPE contains any padding bits. */
>
> bool
> clear_padding_type_has_padding_p (tree type)
> {
> bool has_padding = false;
> if (BITS_PER_UNIT == 8
> && CHAR_BIT == 8
> && clear_padding_type_may_have_padding_p (type))
> {
> HOST_WIDE_INT sz = int_size_in_bytes (type), i;
> gcc_assert (sz > 0);
> unsigned char *buf = XALLOCAVEC (unsigned char, sz);
> memset (buf, ~0, sz);
> clear_type_padding_in_mask (type, buf);
> for (i = 0; i < sz; i++)
> if (buf[i] != (unsigned char) ~0)
> {
> has_padding = true;
> break;
> }
> }
> return has_padding;
> }
>
>
