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]

Re: Reload bug


> I think you're completely right: the reload pass has no specific
> infrastructure for dealing with invalid subregs. It may "fix" these
> subregs, but only if it happens that the operand needs reloading because
> of the insn constraints.

I've found why: the code has been disabled in find_reloads()

		  /* This following hunk of code should no longer be
		     needed at all with SUBREG_BYTE.  If you need this
		     code back, please explain to me why so I can
		     fix the real problem.  -DaveM */
#if 0
		  /* Subreg of a hard reg which can't handle the subreg's mode
		     or which would handle that mode in the wrong number of
		     registers for subregging to work.  */
		  || (GET_CODE (operand) == REG
		      && REGNO (operand) < FIRST_PSEUDO_REGISTER
		      && ((GET_MODE_SIZE (operand_mode[i]) <= UNITS_PER_WORD
			   && (GET_MODE_SIZE (GET_MODE (operand))
			       > UNITS_PER_WORD)
			   && ((GET_MODE_SIZE (GET_MODE (operand))
				/ UNITS_PER_WORD)
			       != HARD_REGNO_NREGS (REGNO (operand),
						    GET_MODE (operand))))
			  || ! HARD_REGNO_MODE_OK (REGNO (operand) + offset,
						   operand_mode[i])))
#endif

Re-enabling it fix PR target/10286.

Now the question: what is the replacement machinery that is supposed to be 
doing the work?

-- 
Eric Botcazou


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