This is the mail archive of the
mailing list for the GCC project.
Re: Commit: MSP430: Pass -md on to assembler
- From: Mike Stump <mikestump at comcast dot net>
- To: nick clifton <nickc at redhat dot com>
- Cc: "gcc-patches at gcc dot gnu dot org Patches" <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 23 Sep 2013 09:42:42 -0700
- Subject: Re: Commit: MSP430: Pass -md on to assembler
- Authentication-results: sourceware.org; auth=none
- References: <87bo3q3697 dot fsf at redhat dot com> <762529D8-82F8-4027-926B-E367AB72C660 at comcast dot net> <523B189E dot 7030905 at redhat dot com> <AF7D9CCD-7921-4D47-90B7-9BA83A0AE30A at comcast dot net> <523C2D6C dot 5050406 at redhat dot com> <588686F0-EACF-412D-9DEA-3DC2968F87BE at comcast dot net> <52405D47 dot 5010104 at redhat dot com>
On Sep 23, 2013, at 8:24 AM, nick clifton <email@example.com> wrote:
>> +(define_insn "extendpsisi2"
>> + [(set (match_operand:SI 0 "nonimmediate_operand" "=r")
>> + (sign_extend:SI (match_operand:PSI 1 "nonimmediate_operand" "0")))]
>> + "TARGET_LARGE"
>> + "# extend psi to si in %0"
>> ;; Look for cases where integer/pointer conversions are suboptimal due
> Works like a charm. The strange thing though is that the pattern never has to generate any code. (I added a gcc_unreachable() to detect if the pattern was ever used to generate assembler).
> I must say though, it seems wrong to have to provide a sign-extend pointer pattern when pointers (on the MSP430) are unsigned.
Agreed. If we instead ask, is it sane for gcc to ever want to signed extend in this case, the answer appears to be no. Why does it, ptr_mode is SImode, and expand_builtin_next_arg is used to perform the addition in this mode. It 'just' knows that is can be signed extended… and just does it that way. This seems like it is wrong.
--- builtins.c (revision 202634)
+++ builtins.c (working copy)
@@ -4094,7 +4094,7 @@ expand_builtin_next_arg (void)
return expand_binop (ptr_mode, add_optab,
- NULL_RTX, 0, OPTAB_LIB_WIDEN);
+ NULL_RTX, POINTERS_EXTEND_UNSIGNED > 0, OPTAB_LIB_WIDEN);
/* Make it easier for the backends by protecting the valist argument
would fix this problem. If this is done, the unmodified test case then doesn't abort. Arguably, the extension should be done as the port directs. It isn't clear to me why they do not.