[Bug tree-optimization/69352] [6 Regression] profiledbootstrap failure with --with-build-config=bootstrap-lto

["jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69352

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Eric Botcazou from comment #12)
> [Sorry for the delay, email hiccup over the last couple of days]
> 
> > CCing Eric on whether REF_REVERSE_STORAGE_ORDER should be checked in
> > operand_equal_p and whether TYPE_REVERSE_STORAGE_ORDER doesn't have to be
> > tested in useless_type_conversion_p (perhaps the latter is ok, if it is not
> > possible for two aggregates with the same TYPE_CANONICAL to have different
> > TYPE_REVERSE_STORAGE_ORDER).
> 
> The design is that memory references are always accessed in the same storage
> order, i.e. there will be no references to the same memory location
> differing only by the storage order in the program; in other words,
> operand_equal_p need not bother about REF_REVERSE_STORAGE_ORDER if
> everything works as designed.

How do you ensure that?  You could (perhaps through aliasing violation or union
or what) access the same memory slot through two different MEMs, and if one of
them has reverse and the other does not...

> Likewise for useless_type_conversion_p: TYPE_REVERSE_STORAGE_ORDER is a
> property of canonical types and cannot differ between types with the same
> canonical type.

Is TYPE_REVERSE_STORAGE_ORDER only used for aggregates, or even scalar types?
Because for the latter, useless_type_conversion_p usually only cares about
precision and signedness and nothing else, doesn't care about TYPE_CANONICAL.