https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82703
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 42478
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42478&action=edit
gcc7-pr82703.patch
The fix (untested so far) is simple, i386 backend, please meet
avoid_constant_pool_references. While that function existed already when
maybe_get_pool_constant was introduced, at that point it didn't delegitimize
addresses, which is presumably the point why it has been added. But it does
now. On the other side, maybe_get_pool_constant didn't bother with mode
changes. In particular, the issue here is we have a (mem:V2DF) that
get_pool_constant returns a (const_vector:V1TI) for and sees that all but the
first element (there are no such ones) are zeros, so it must be zero extended.
Of course, any other kind of VCE could have similar issues, e.g. if (mem:V4SF)
has (const_vector:V2DF) pool and the second DF is 0, but second 32-bits of the
first DF are not, etc.
