On Fri, Aug 28, 2020 at 12:47 PM Jakub Jelinek <ja...@redhat.com> wrote: > > On Fri, Aug 28, 2020 at 12:36:00PM +0200, Richard Biener wrote: > > Guess this would work indeed. It's probably quite common to have > > both vector and non-vector constants because of vectorization > > and scalar epilogues. But note that elsewhere we're using > > the largest component mode to emit vector constant pool entries > > to share { -1, -1, -1, -1 } and {-1l, -1l } for example so while the > > below code works for FP modes it likely will break down for > > integer modes? > > I don't see why it would break, it will not optimize { -1LL, -1LL } > vs. -1 scalar, sure, but it uses the hash and equality function the > rtl constant pool uses, which means it compares both the constants > (rtx_equal_p) and mode we have recorded for it.
Oh, I thought my patch for PR54201 was installed but it was not (I grepped my patch folder...). PR54201 complains about something similar but then different ;) Guess post-processing that would also be possible but also a bit awkward. Maybe we should hash the full byte representation instead of the components. Richard. > Of course, on x86_64 integer scalar constants will pretty much never appear > in the constant pool, so guess we'll need a different target for testing > that. > > Jakub >