On Tue, Dec 10, 2013 at 11:05 AM, Tejas Belagod <tbela...@arm.com> wrote: > H.J. Lu wrote: >> >> On Tue, Dec 10, 2013 at 9:26 AM, Tejas Belagod <tbela...@arm.com> wrote: >>> >>> H.J. Lu wrote: >>>> >>>> On Tue, Dec 10, 2013 at 9:04 AM, Kirill Yukhin <kirill.yuk...@gmail.com> >>>> wrote: >>>>> >>>>> On 10 Dec 08:23, H.J. Lu wrote: >>>>>> >>>>>> What is wrong to pass the correct offset to >>>>>> CANNOT_CHANGE_MODE_CLASS? Backends are free to >>>>>> ignore it. >>>>> >>>>> Yes, but as fas as understand this hook as a predicate >>>>> saying if it not-safe to change mode1 to mode2 for given >>>> >>>> >>>> In many places, the macro is used with the known offset. >>>> I have a follow up patch which improves x86 code generation, >>>> in cases like: >>>> >>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45198 >>>> >>> What is it that subreg_get_info () can't resolve that >>> CANNOT_CHANGE_MODE_CLASS with an offset can? >>> >> >> We have >> >> int >> simplify_subreg_regno (unsigned int xregno, enum machine_mode xmode, >> unsigned int offset, enum machine_mode ymode) >> { >> struct subreg_info info; >> unsigned int yregno; >> >> #ifdef CANNOT_CHANGE_MODE_CLASS >> /* Give the backend a chance to disallow the mode change. */ >> if (GET_MODE_CLASS (xmode) != MODE_COMPLEX_INT >> && GET_MODE_CLASS (xmode) != MODE_COMPLEX_FLOAT >> && REG_CANNOT_CHANGE_MODE_P (xregno, xmode, ymode) >> /* We can use mode change in LRA for some transformations. */ >> && ! lra_in_progress) >> return -1; >> #endif >> >> CANNOT_CHANGE_MODE_CLASS is checked before subreg_get_info is >> called. When REG_CANNOT_CHANGE_MODE_P returns false, >> there is nothing subreg_get_info can do. >> > > So, if (subreg:DI (match_operand:V4SF 1 "register_operand" "x,x") 0) is a > valid subreg, why not allow it in CANNOT_CHANGE_MODE_CLASS (like in Kirill's > patch http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00987.html) and resolve > the actual register later in subreg_get_info ()?
Let's wait for Kirill's results on GCC testsuite. > In general, as I understand it, CANNOT_CHANGE_MODE_CLASS doesn't need an > offset because it only checks for validity of a mode-change in a regclass > from the point of view of bit-correct-representation (eg. a register when > subreg'ed still has the same order of bits) - the actual register reference > is done elsewhere using the offset. > > Thanks, > Tejas. > -- H.J.
