Fix msp430 port WRT fallthru

This patch just tweaks a comment so that we no longer warn. Installing on the trunk. Jeff commit 7aa35b20124373889e039a054076dd8d5288c9e2 Author: law Date: Wed Oct 26 15:49:25 2016 + * config/msp430/msp430.c

[PATCH] Fix undefined behaviour in msp430 port

; Date: Mon Sep 28 19:24:56 2015 -0400 [PATCH] Fix undefined behaviour in msp430 port * config/msp430/msp430.c (msp430_legitimate_constant): Fix undefined left shift behaviour. * config/msp430/constraints.md ('L' constraint): Similarly.

Re: msp430 port

so... can I get an official ok to commit with you and Nick as maintainers then?

Re: msp430 port

On 08/23/2013 01:52 PM, DJ Delorie wrote: so... can I get an official ok to commit with you and Nick as maintainers then? Just need to clear it with the steering committee, which for this sort of thing has been pretty trivial. Basically it has to pass the technical review (which y'all have

Re: msp430 port

On 08/19/2013 07:04 PM, Mike Stump wrote: On Aug 19, 2013, at 1:54 PM, Jeff Law l...@redhat.com wrote: On 08/19/2013 02:49 PM, DJ Delorie wrote: I'd say it's not as simple as you make it out to be. You can't blindly combine operations on volatile memory. I'm not blindly combining them, I'm

Re: msp430 port

On 07/30/2013 09:24 PM, DJ Delorie wrote: [nickc added for comments about the bits he wrote] ... define these as (define_predicate msp_general_operand (match_code mem,reg,subreg,const_int,const,symbol_ref,label_ref { int save_volatile_ok = volatile_ok; volatile_ok = 1; int ret =

Re: msp430 port

On 08/19/2013 02:32 PM, Jeff Law wrote: Ok, I think I got it all covered... ended up copying most of the pushm/popm from rx, added return but not simple_return, and merged added a peephole for and-bic. [ ... ignore ... hit send in the wrong window ]

Re: msp430 port

On 08/14/2013 02:55 PM, DJ Delorie wrote: +#endif /* GCC_MSP430_PROTOS_H */ Index: gcc/config/msp430/predicates.md === --- gcc/config/msp430/predicates.md (revision 0) +++ gcc/config/msp430/predicates.md (revision 0) +

Re: msp430 port

I'd say it's not as simple as you make it out to be. You can't blindly combine operations on volatile memory. I'm not blindly combining them, I'm combining them when I know the hardware will do the volatile-correct thing. ie, the programmer may have written them as separate statements and

Re: msp430 port

On 08/19/2013 02:49 PM, DJ Delorie wrote: I'd say it's not as simple as you make it out to be. You can't blindly combine operations on volatile memory. I'm not blindly combining them, I'm combining them when I know the hardware will do the volatile-correct thing. You're missing the point. If

Re: msp430 port

You're missing the point. If the programmer wrote two statements which hit volatile memory and you've got some pattern which matches those two statements, then with your change you'll end up combining them, that's wrong. I see nothing in the ISO spec that says you can't combine a volatile

Re: msp430 port

register int a; extern volatile int b; a = b; a |= 0x54; b = a; The ISO spec seems to allow gcc to perform those operations in a single physical insn, as long as the operations on 'b' are all performed, and in the correct sequence. And I believe it's also

Re: msp430 port

On Mon, 2013-08-19 at 16:49 -0400, DJ Delorie wrote: I'd say it's not as simple as you make it out to be. You can't blindly combine operations on volatile memory. I'm not blindly combining them, I'm combining them when I know the hardware will do the volatile-correct thing. ie, the

Re: msp430 port

will not work on the msp430 port, if this is done?

Re: msp430 port

On Aug 19, 2013, at 1:54 PM, Jeff Law l...@redhat.com wrote: On 08/19/2013 02:49 PM, DJ Delorie wrote: I'd say it's not as simple as you make it out to be. You can't blindly combine operations on volatile memory. I'm not blindly combining them, I'm combining them when I know the hardware

Re: msp430 port

comma comma comma comma comma comma got it ;-)

Re: msp430 port

On Tue, 23 Jul 2013, DJ Delorie wrote: Ok, I think I covered everything... ...except one comma. ;-) Index: gcc/doc/contrib.texi === -Nick Clifton for arm, mcore, fr30, v850, m32r, rx work, +Nick Clifton for arm, mcore, fr30,

Re: msp430 port

On 07/20/2013 01:32 AM, DJ Delorie wrote: Every pattern that is using (subreg:SI (thing:PSI)) needs to be explained on this list and given an explicit clearance. It really looks like you're just papering over problems elsewhere. Most of them are just optimizations, but the problem with

Re: msp430 port

What I really need is an int20_t type in the core of gcc, so I can set Pmode to *that*, to avoid the SImode stuff completely. But that's a core change, not a target change. Sometimes you have to make core changes for a new port. This sounds like something that really should be fixed

Re: msp430 port

Hi DJ, Hi Richard, +;; The next two patterns are here to support a feature of how GCC implements +;; varargs. When a function uses varargs and the *second* to last named +;; argument is split between argument registers and the stack, gcc expects the +;; callee to allocate space on the stack

Re: msp430 port

On 07/30/2013 05:24 PM, DJ Delorie wrote: Fixed. Perhaps gen* could error on those? I know they're ignored, I just keep forgetting that splits are special. (alternately, why can't they be included in the matching logic?) (Because pre-reload, pseudos don't have register classes, mostly)

Re: msp430 port

The first doesn't have a clobber, though... Hmm. Missed that. So the only reason you'd care to include the bic in the regular and pattern is if it were a smaller encoding than the regular r/0/i alternative. It is, but the separate pattern picks that out just fine. You need to

Re: msp430 port

On Jul 30, 2013, at 8:24 PM, DJ Delorie d...@redhat.com wrote: [nickc added for comments about the bits he wrote] ... define these as (define_predicate msp_general_operand (match_code mem,reg,subreg,const_int,const,symbol_ref,label_ref { int save_volatile_ok = volatile_ok;

Re: msp430 port

On 07/31/2013 07:08 AM, DJ Delorie wrote: The first doesn't have a clobber, though... Hmm. Missed that. So the only reason you'd care to include the bic in the regular and pattern is if it were a smaller encoding than the regular r/0/i alternative. It is, but the separate pattern picks

Re: msp430 port

On 07/25/2013 05:36 PM, DJ Delorie wrote: I tried to reproduce the original bugs that led to these patterns, but was unable. Testsuite results are the same with and without, and eembc code size doesn't change. So, I'm removing these patterns from the port. The remaining (subreg...) patterns

Re: msp430 port

On 07/23/2013 04:08 PM, DJ Delorie wrote: Index: gcc/cfgexpand.c === --- gcc/cfgexpand.c (revision 201184) +++ gcc/cfgexpand.c (working copy) I thought I already approved this. Go ahead and install it. Index:

Re: msp430 port

Index: gcc/cfgexpand.c === --- gcc/cfgexpand.c (revision 201184) +++ gcc/cfgexpand.c (working copy) I thought I already approved this. Go ahead and install it. Sorry, I forgot to split out those three patches when I

Re: msp430 port

So it's a little unclear to me which patterns you removed. Your message has two patterns attached with comments they were to work around reload issues. Are these the patterns you removed? Yes. I was unable to reproduce the reload problems to which those comments referred. First, if you

Re: msp430 port

On 07/23/2013 12:08 PM, DJ Delorie wrote: === --- gcc/simplify-rtx.c(revision 201184) +++ gcc/simplify-rtx.c(working copy) @@ -5884,12 +5884,23 @@ simplify_immed_subreg (enum machine_mode /* Simplify

Re: msp430 port

On 07/30/2013 12:47 PM, DJ Delorie wrote: +; Note: using POPM.A #1 is two bytes smaller than using POPX.A + +(define_insn movsipsi2 + [(set (match_operand:PSI0 register_operand =r) + (subreg:PSI (match_operand:SI 1 register_operand r) 0))] + TARGET_LARGE + PUSH.W %H1 {

Re: msp430 port

On 07/30/2013 12:51 PM, DJ Delorie wrote: First, if you can handle ASHIFT directly in PSImode, that's advantageous for address calculations. Yup, I have patterns for 1 and 2 bit shifts, which are all that really happen. They look remarkably like your patterns, but use a subreg on 0 instead

Re: msp430 port

[nickc added for comments about the bits he wrote] ... define these as (define_predicate msp_general_operand (match_code mem,reg,subreg,const_int,const,symbol_ref,label_ref { int save_volatile_ok = volatile_ok; volatile_ok = 1; int ret = general_operand (op, mode);

Re: msp430 port

I tried to reproduce the original bugs that led to these patterns, but was unable. Testsuite results are the same with and without, and eembc code size doesn't change. So, I'm removing these patterns from the port. The remaining (subreg...) patterns are just optimizations. ; This pattern is

Re: msp430 port

On 07/19/2013 05:32 PM, DJ Delorie wrote: Every pattern that is using (subreg:SI (thing:PSI)) needs to be explained on this list and given an explicit clearance. It really looks like you're just papering over problems elsewhere. Most of them are just optimizations, but the problem with reload