Kenneth Zadeck <zad...@naturalbridge.com> writes: > There are several problems with just dropping a mode into the already > existing mode field of an rtx constant. > 1) There may be places where the a back end is testing equality to see > if constants of different modes are in fact the same value. > 2) Most of the places what build int constants use GEN_INT which does > not take a mode, even though about 95% of those places have a mode right > there and the rest just take a little work. There are constructor > that do take a mode, but in the end they just throw the mode on the floor. > 3) The canonical test to see if a CONST_DOUBLE contains an int or float > is to test if the mode is VOIDmode. > > Any port that is converted to have TARGET_SUPPORTS_WIDE_INT has no more > of problem (3). I admit that rooting out (1) is likely to be the worst > of the problems. But we were careful to at least make this work move > us in the correct direction.
I agree with that, and FWIW, there are others. Two off the top of my head: 4) Many places use const0_rtx instead of CONST0_RTX (mode) (correctly, according to current representation) 5) All const_ints in the .md files would need to be given a mode (except for those places where const_int actually represents a C++ constant, such as in attributes). I realise your list wasn't supposed to be exhaustive, and neither's mine :-) Richard
