This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Suspicious code in assign_parms


I'm seeing extra zero/sign extension operations on argument registers
and came to the following code in ``assign_parms'':

                if (GET_CODE (tempreg) == SUBREG
		  && GET_MODE (tempreg) == nominal_mode
		  && GET_CODE (SUBREG_REG (tempreg)) == REG
		  && nominal_mode == passed_mode
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
		  && GET_MODE (SUBREG_REG (tempreg)) == GET_MODE (entry_parm)
		  && GET_MODE_SIZE (GET_MODE (tempreg))
		     < GET_MODE_SIZE (GET_MODE (entry_parm)))
		{
		  /* The argument is already sign/zero extended, so note it
		     into the subreg.  */
		  SUBREG_PROMOTED_VAR_P (tempreg) = 1;
		  SUBREG_PROMOTED_UNSIGNED_SET (tempreg, unsignedp);
		}

Note the underlined comparison.  Does it look right ?  I thought that
should be ``promoted_nominal_mode == passed_mode''.

Could somebody explain the meaning of and difference between the
variables ``promoted_mode'' and ``promoted_nominal_mode'' throughout
``assign_parms'' ?

~velco

PS. Changing above ``nominal_mode'' to ``promoted_nominal_mode'' seems
to get rid of the extra conversions on v850e.

Bootstrapping + regtesting on i686-pc-linux-gnu (though it wouldn't
make a difference, I guess) and regtesting on arm-unknown-elf in
progress.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]