This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Modes on CONST_INTs
- To: geoffk at redhat dot com
- Subject: Re: Modes on CONST_INTs
- From: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- Date: Mon, 27 Nov 2000 21:33:54 +0100
- CC: hans-peter dot nilsson at axis dot com, bernds at redhat dot com, gcc at gcc dot gnu dot org
> Date: Sun, 26 Nov 2000 13:01:54 -0800
> From: Geoff Keating <geoffk@geoffk.org>
> > Date: Sun, 26 Nov 2000 15:19:43 +0100
> > From: Hans-Peter Nilsson <hans-peter.nilsson@axis.com>
> > I was going in the direction of canonicalizing CONST_INTs by
> > sign-extension, as indicated by Geoff in response to a recent
> > patch of mine. Perhaps that would solve those problems with a
> > smaller change than caring for an associated mode with each
> > constant; it doesn't seem like there are a large enough amount
> > of failing codes and test-cases to warrant such a huge change.
>
> These are orthogonal. You still have to fix canonicalization
> even if you have the mode information. Having a mode may make this
> easier; you can certainly find any bugs in the canonicalization much faster.
Right. Also, having the signedness/unsignedness property
available would find more bugs, as Michael Meissner pointed out.
You can't really have a canonical representation of a number
unless you know how it was used. Currently we have two
representations, for example both 255 and -1 for
all-bits-in-a-byte to track that, with inevitable bugs like the
ones at the URL; "QImode/U -1" might be an alternative.
If those CONST_INT changes are too big to go in 3.0, please consider
<URL:http://gcc.gnu.org/ml/gcc-patches/2000-11/msg01349.html> as
a piece of string to tie up one end of the situation. I might
be able to do something useful with sign-extend-canonicalization,
but right now I see an open can with crawly things inside in that
direction.
brgds, H-P