This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Modes on CONST_INTs


On Mon, Nov 27, 2000 at 03:04:50PM +0000, Bernd Schmidt wrote:
> On Mon, 27 Nov 2000, Michael Meissner wrote:
> 
> > Ummm, as desirable as the change may be, I suspect we probably want to delay
> > doing this until after GCC 3.0 ships.
> 
> Oh, I'm not suggesting we immediately make the constants have modes.  The
> first steps should be purely adding infrastructure while still keeping
> VOIDmode for constants.  Then, once all the dubious code has been cleaned
> up, we can make the switch.  It may even be possible during a transition
> phase to add a target macro that says whether a port has been converted
> to use proper modes.  Then we wouldn't have to update all the ports at
> once.
> 
> > Secondarily, I would prefer to see a more encompassing approach that handles
> > multi-word integers, including the ability to create 128 bit integer constants
> > on 32-bit machines.
> 
> How would you suggest to do this?  By eliminating CONST_INT entirely and just
> using CONST_DOUBLE for everything?

I suspect not having CONST_INT will make things even worse in terms of the flag
day, but is desirable long term.  We probably should have an abstract integer
type that occupies just one RTL slot.  Then define functions that do all
arithmetic, comparisons, etc.

> > Third, we still haven't solved the sign-extends/zero-extends problem.  To
> > really solve that problem, I think we either need a bit in the
> > CONST_INT/CONST_whatever that says to apply zero extension or we need unsigned
> > varients of all of the basic/vector integer types.
> 
> I don't see yet why this is necessary.  Surely we have no such problem for
> other rtx objects such as REG or MEM; why should constants be different?  If
> any piece of code needs a wider version of a given constant, doesn't it also
> have to know whether it wants a sign extension or a zero extension?
> Comparisons shouldn't be a problem either, since we distinguish between
> unsigned and signed variants.

I would argue we do have the problem for REGs and MEMs.  We just paper it over
by passing an out of band flag in most places that says whether to sign
extended or zero extend.

> > > 2. In a similar way, replace uses of const0_rtx etc. with CONST0_RTX(MODE).
> > >    We'll also need a few new macros, e.g. CONSTM1_RTX(MODE) etc.
> > 
> > Delete const0_rtx and friends so that the change is more apparent.
> 
> Eventually, yes, once everything has been converted.

I would rather do it as soon as the MI files are converted, since it will make
it obvious that a port is broken.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]