"H.J. Lu" <hongjiu...@intel.com> writes:
> @@ -706,7 +706,13 @@ precompute_register_parameters (int num_actuals, struct
> arg_data *args,
> pseudo now. TLS symbols sometimes need a call to resolve. */
> if (CONSTANT_P (args[i].value)
> && !targetm.legitimate_constant_p (args[i].mode, args[i].value))
> - args[i].value = force_reg (args[i].mode, args[i].value);
> + {
> + if (GET_MODE (args[i].value) != args[i].mode)
> + args[i].value = convert_to_mode (args[i].mode,
> + args[i].value,
> + args[i].unsignedp);
> + args[i].value = force_reg (args[i].mode, args[i].value);
> + }
But if GET_MODE (args[i].value) != args[i].mode, then the call to
targetm.legitimate_constant_p looks wrong. The mode passed in the
first argument is supposed to the mode of the second argument.
Is there any reason why this and the following:
/* If we are to promote the function arg to a wider mode,
do it now. */
if (args[i].mode != TYPE_MODE (TREE_TYPE (args[i].tree_value)))
args[i].value
= convert_modes (args[i].mode,
TYPE_MODE (TREE_TYPE (args[i].tree_value)),
args[i].value, args[i].unsignedp);
need to be done in the current order? I can't think of any off-hand.
If not, would swapping them also fix the bug?
(I can't review this either way, of course.)
Richard
