On Tue, 15 Apr 2025, Jakub Jelinek wrote:
> On Tue, Apr 15, 2025 at 01:56:25PM +0200, Richard Biener wrote:
> > On Tue, 15 Apr 2025, Jakub Jelinek wrote:
> >
> > > On Mon, Mar 31, 2025 at 03:34:07PM +0200, Martin Jambor wrote:
> > > > This patch just introduces a form of dumping of widest ints that only
> > > > have zeros in the lowest 128 bits so that instead of printing
> > > > thousands of f's the output looks like:
> > > >
> > > > Bits: value = 0xffff, mask = all ones folled by
> > > > 0xffffffffffffffffffffffffffff0000
> > > >
> > > > and then makes sure we use the function not only to print bits but
> > > > also to print masks where values like these can also occur.
> > >
> > > Shouldn't that be followed by instead?
> > > And the widest_int checks seems to be quite expensive (especially for
> > > large widest_ints), I think for the first one we can just == -1
> > > and for the second one wi::arshift (value, 128) == -1 and the zero
> > > extension
> > > by using wi::zext.
> > >
> > > Anyway, I wonder if it wouldn't be better to use something shorter,
> > > the variant patch uses 0xf..f prefix before the 128-bit hexadecimal
> > > number (maybe we could also special case the even more common bits 64+
> > > are all ones case). Or it could be 0xf*f prefix. Or printing such
> > > numbers as -0x prefixed negative, though that is not a good idea for
> > > masks.
> >
> > I'd accept 0xf..f as reasonable, possibly 0xf<repeated N times>f
> > when there are more than sizeof("repeated N times") fs inbetween.
> > It does make matching up masks more difficult when tracking changes
> > (from my experience with bit-CCP debugging, where such large masks
> > appear as well). So IMO we can live with large 0xffffff but for
> > all-ones we could print -1 if that's the common noisy thing.
>
> There is already -1 special case, the problem which Martin was trying
> to solve is that the 0xf<32762 times f>f0000 and similar cases were
> still way too common.
> The primary problem is using wrong type for it, IMHO both ipa-cp and
> tree-ssa-ccp should be using wide_int with the precision of the particular
> SSA_NAME etc., rather than widest_int. But there is no chance rewriting
> that now for GCC 15.
ISTR at least CCP _prints_ wide_int (or it's tree form), not widest_int
(but the lattice has widest_int indeed). But CCP knows the precision
of the lattice entry (which is for an SSA name), possibly IPA CP
doesn't.
Richard.
