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
>

Reply via email to