Re: CONST fixes

[Geoff Keating <geoffk at cygnus dot com>]

> Date: Wed, 2 Aug 2000 13:51:35 +0200
> From: Jan Hubicka <jh@suse.cz>
> Cc: jh@suse.cz, gcc-patches@gcc.gnu.org
> 
> > 
> > I'm not convinced that the mode of CONST should always be Pmode,
> > I suspect there are cases when it can be something else, for instance
> > 
> > (const:HI (truncate:HI (minus:SI (label_ref 1) (label_ref 2)) 0))
> > 
> I guess that it is cleaner to put CONST inside truncate and
> make it Pmode tought.
> > in RTL representing a folded pc-relative switch statement.  I guess if
> > there is code to check this, then if it ever happens we'll find about
> > it :-).
> > 
> > Since CONST doesn't change the value of the thing inside it, it should
> > certainly have the same mode, just like NEG should have the same mode
> > as its operand.
> The purpose why my checker accepted this is that it generally accept VOIDmode
> at the place of othe rmodes - since (neg:SI (const_int 0)) is valid.  It also

This is a special case for CONST_INT and CONST_DOUBLE.  It's not valid
anywhere else.  It's also required; CONST_INT must always be VOIDmode
and CONST_DOUBLE must be VOIDmode or a FP mode.

> can't refuse VOIDmode on unspec IMO, thats why it don't see it and the rtl is
> probably valid, even when in weird way. I guess I can get rid of most
> unspecs there - the code just does valid operations, like loading value of
> symbol to register, even when it does it in complex steps.

VOIDmode is valid on unspec, but only when the unspec is the top-level
thing in an insn:

(insn 13 14 15
  (unspec [(reg 32)] 10) )

in that case, the unspec truly has no value and so VOIDmode is
correct.

> Does idea of allowing other modes on CONST (and modifying the docs
> in this way) sound fine to everyone?


-- 
- Geoffrey Keating <geoffk@cygnus.com>