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.
Jakub
