On Fri, May 3, 2013 at 2:48 PM, Richard Sandiford <rdsandif...@googlemail.com> wrote: > 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)
As it's easy from the context to get at a mode just drop const0_rtx and fix the fallout? (and complicate the CONST0_RTX macro to dispatch to const_int_rtx for integer modes) > 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 :-) Now, do you think it is a good idea to assign integer constants a mode or not? Richard. > Richard
