On 07/13/2017 03:02 AM, Richard Sandiford wrote: > This patch treats the mode associated with an integer constant as a > scalar_mode. We can't use the more natural-sounding scalar_int_mode > because we also use (const_int 0) for bounds-checking modes. (It might > be worth adding a bounds-specific code instead, but that's for another > day.) Is that the only reason why we can't use scalar_int_mode here -- the bounds checking stuff? What if it were to just magically disappear?
> > This exposes a latent bug in simplify_immed_subreg, which for > vectors of CONST_WIDE_INTs would pass the vector mode rather than > the element mode to rtx_mode_t. > > I think the: > > /* We can get a 0 for an error mark. */ > || GET_MODE_CLASS (mode) == MODE_VECTOR_INT > || GET_MODE_CLASS (mode) == MODE_VECTOR_FLOAT An interesting nugget. It appears Aldy's commit message, but not in the approved patch from June 2002. > > in immed_double_const is dead. trunc_int_mode (via gen_int_mode) > would go on to ICE if the mode fitted in a HWI, and surely plenty > of other code would be confused to see a const_int be interpreted > as a vector. We should instead be using CONST0_RTX (mode) if we > need a safe constant for a particular mode. Yea, if we wanted to use 0 as an error mark, we should be using it via CONST0_RTX (mode). > > We didn't try to make these functions take scalar_mode arguments > because in many cases that would be too invasive at this stage. > Maybe it would become feasible in future. Also, the long-term > direction should probably be to add modes to constant integers > rather than have then as VOIDmode odd-ones-out. That would remove > the need for rtx_mode_t and thus remove the question whether they > should use scalar_int_mode, scalar_mode or machine_mode. THe lack of a mode on CONST_INTs is a long standing wart. It's been eons since we really thought about how to fix it. I'd have to dig real deep to remember why we've let the wart stand so long > > The patch also uses scalar_mode for the CONST_DOUBLE handling > in loc_descriptor. In that case the mode can legitimately be > either floating-point or integral. > > 2017-07-13 Richard Sandiford <richard.sandif...@linaro.org> > Alan Hayward <alan.hayw...@arm.com> > David Sherwood <david.sherw...@arm.com> > > gcc/ > * emit-rtl.c (immed_double_const): Use is_a <scalar_mode> instead > of separate mode class checks. Do not allow vector modes here. > (immed_wide_int_const): Use as_a <scalar_mode>. > * explow.c (trunc_int_for_mode): Likewise. > * rtl.h (wi::int_traits<rtx_mode_t>::get_precision): Likewise. > (wi::shwi): Likewise. > (wi::min_value): Likewise. > (wi::max_value): Likewise. > * dwarf2out.c (loc_descriptor): Likewise. > * simplify-rtx.c (simplify_immed_subreg): Fix rtx_mode_t argument > for CONST_WIDE_INT. OK. jeff
