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 (msp430_legitimate_address_p): Adjust
fallthru comment.
-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.
('Ys' constraint): Si
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
so... can I get an official "ok to commit with you and Nick as maintainers"
then?
On 08/19/2013 07:04 PM, Mike Stump wrote:
On Aug 19, 2013, at 1:54 PM, Jeff Law 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 w
On Aug 19, 2013, at 1:54 PM, Jeff Law 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 will
;& ! volatile_ok && MEM_VOLATILE_P (op))
return 0;
/* Use the mem's mode, since it will be reloaded thus. */
So that others know exactly what I'm thinking about. Targets that fix their
port to be clean with respect to volatile (you must not read or write in a
manner other than is directly allowed if volatile is set) can turn it one and
go on with life.
So, does anyone have a concrete example of what will not work on the msp430
port, if this is done?
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.
>
> >
> 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
> 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 volatil
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
> 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 an
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)
+
+(def
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 ]
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
comma comma comma comma comma comma
got it ;-)
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
> > 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
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
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 pat
On Jul 30, 2013, at 8: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;
>> volati
> > 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 im
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)
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 t
[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);
>
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 o
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"
+ "
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 SUBREG:O
> 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
> > 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
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: gcc/simplif
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 ar
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 i
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
> 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 is
that an SImode register *can't* h
> GPL + exception seems like the way to go, except in those cases where
> the code is coming from a 3rd party.
Already pointed out and fixed, but I'll double check that they're all
GPL+E.
> I'm assuming you documented all the MSP430 options. I didn't check them
> closely. I'm also assuming t
Might as well clarify copyright status on *all* the msp430 files in
libgcc. While one might claim some are so trivially small and thus not
suitable for copyright protection, I'd rather not rely on that for
anything in libgcc since those bits get included into user code and
lawyers look at them
37 matches
Mail list logo
