FIX_REGISTER_CHECK

Jim Wilson wilson@cygnus.com
Thu Oct 8 15:10:00 GMT 1998


	I didn't write versions of FIX_REGISTER_CHECK for all the other
	ports because I don't know the list of invalid registers for
	each port.

I don't expect you to fix all ports.  It would be nice if you had a plan
for how to deal with this problem though.  For instance, adding a testcase
to the testsuite to give an expected failure for all ports which don't have
a definition of FIX_REGISTER_CHECK.  That way a port maintainer could at
least see the problem everytime the testsuite is run.  Or perhaps emitting
a generic warning message if this macro is not defined, e.g. "this option
may not be safe".  Or perhaps offering to contact the individual port
maintainers and see that they all write a version of this macro.

	My intent was to provide a place maintainers who knew 
	the list for a particular port could encode it.  

You should have mentioned this.  If I see an incomplete patch, I will assume
it is wrong, I won't assume that you are planning to finish it later.

	I considard using CONDITIONAL_REGISTER_USAGE for this as Jeff
	suggests, but at that point we no longer have the name for the
	register that the user specified in the -fcall* option.

It would be possible to get the option name, but very inconvenient.  You
can use reg_names to get a register name string.  It might not be the
same name used in the option though.  You can check save_argv to look
for the option.  And if you haven't found it yet, you can check
ADDITIONAL_REGISTER_NAMES the same way.  I wouldn't recommend doing this
though.  It would be easier to emit the canonical name for the register,
and expect the user to understand the error message.

However, looking at CONDITIONAL_REGISTER_USAGE, I see another problem with your
patch.  It is impossible to determine all problems at the time that you
see the -f{call-used,saved,fixed}-X option, because other command line
options affect what registers are valid.  For instance, using the mips as
an example, this is OK:
	-fcall-saved-\$f31
but this is not OK:
	-fcall-saved-\$f31 -msoft-float
because we can't make a non-existent register be call-saved.  Your patch
can't handle the second situation though, because at the time that we see
the -fcall-saved-\$f31 option, we haven't seen the -msoft-float option yet.
Another example, this is not OK (irix6):
	-ffixed-\$8
because r8 is in the middle of the parameter registers, but this is OK:
	-ffixed-\$8 -mabi=32
because now r8 isn't a parameter registers.

Given these examples, I think that we would have to wait until after all
options are parsed in order to do this correctly.  That would argue for
doing it in CONDITIONAL_REGISTER_USAGE, even if we can't get the right
register name in the error message.  Even that isn't enough though, because
we can't detect bad options that leave the fixed_regs/call_used_regs arrays
unchanged.  -fcall-saved-\$f31 from my first example is a case of this.
So we would need extra info somehwere, to indicate which fields had been
set by an option, and to indicate whether the option set or cleared the field.
That still leaves the task of writing the code to check for all possible
cases, which is going to be rather complicated in the case of the mips,
since you need to deal with every ABI, mips16, soft-float, 32-bit vs 64-bit
processors, architecture levels, etc.

It would be easier to just leave things alone, and tell the user that he
shouldn't use these -f{call-used,saved,fixed}-X options unless he knows
what he is doing.

Jim



More information about the Gcc-patches mailing list