On 12/17/20 8:44 AM, Nathan Sidwell wrote:
> On 12/17/20 10:38 AM, Richard Sandiford via Gcc-patches wrote:
>> Tom Tromey <t...@tromey.com> writes:
>>>>>>>> "Richard" == Richard Sandiford via Gcc-patches
>>>>>>>> <gcc-patches@gcc.gnu.org> writes:
>>>
>>> Richard> +// A class that stores a choice "A or B", where A has type
>>> T1 * and B has
>>> Richard> +// type T2 *. Both T1 and T2 must have an alignment
>>> greater than 1, since
>>> Richard> +// the low bit is used to identify B over A. T1 and T2
>>> can be the same.
>>>
>>> It seems like the alignment requirement could be static_assert'd, which
>>> would make using this class a bit safer.
>>
>> Yeah, I wondered about doing that, but in principle there's nothing
>> to stop people using the class for something like a char*, provided that
>> the start is suitably aligned. So having gcc_checking_assert is a
>> compromise: it only provides run-time checking rather than compile-time
>> checking, but it doesn't place any artificial limits on how the class
>> can be used.
>
> I don;t know whether our optimizers are smart enough (credulous
> enough?) to know that the low bits of any pointer to an aligned type
> must be zero, and therefore optimize the assert away in those cases?
>
> If they're not something like
>
> assert (align (T) > 1 || !(reinterpret_cast<intptr_t> (ptr) & 1))
I believe both gimple optimizers and the RTL optimizers are aware of the
restrictions on the low bits for STRICT_ALIGNMENT targets and should be
able to optimize the assert away.
jeff
