[PATCH] [MSP430] Fix PR/86662
As reported in PR/86662, use of __int20 in a program built with -mlarge and
-flto causes a segfault for msp430 due to endless recursion in
gimple_get_alias_set.
The attached patch fixes this.
The segfault can be observed on the gcc-7 and gcc-8 branches, and on trunk.
The testcase works in gcc-6
Successfully boostrapped and regtested on x86_64-pc-linux-gnu and msp430-elf.
This fixes many LTO C and C++ tests for msp430 when the testsuite is invoked
with the -mlarge target flag.
Ok for gcc-7-branch, gcc-8-branch, and trunk?
>From 01f8e76dbf50265ae9a3f5f665d27ac8cf811b0c Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Tue, 24 Jul 2018 23:24:41 +0100
Subject: [PATCH][MSP430] Fix PR86662
2018-07-27 Jozef Lawrynowicz
PR target/86662
* gcc/tree.c (build_common_tree_nodes): Initialize integer_types array
with all enabled __intN types.
* gcc/testsuite/gcc.target/msp430/pr86662.c: New test.
---
gcc/testsuite/gcc.target/msp430/pr86662.c | 13 +
gcc/tree.c| 3 +--
2 files changed, 14 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/msp430/pr86662.c
diff --git a/gcc/testsuite/gcc.target/msp430/pr86662.c b/gcc/testsuite/gcc.target/msp430/pr86662.c
new file mode 100644
index 000..1144b3e
--- /dev/null
+++ b/gcc/testsuite/gcc.target/msp430/pr86662.c
@@ -0,0 +1,13 @@
+/* PR/86662 */
+
+/* { dg-do link } */
+/* -nostdlib prevents link errors due to mismatched code models for
+ libgloss objects. */
+/* { dg-options "-mlarge -flto -nostdlib" } */
+/* { dg-skip-if "" { *-*-* } { "-mcpu=msp430" } } */
+
+int main(void)
+{
+ __int20 n = 5;
+ return 0;
+}
diff --git a/gcc/tree.c b/gcc/tree.c
index bace9c8..54384ad 100644
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -9802,8 +9802,7 @@ build_common_tree_nodes (bool signed_char)
int_n_trees[i].signed_type = make_signed_type (int_n_data[i].bitsize);
int_n_trees[i].unsigned_type = make_unsigned_type (int_n_data[i].bitsize);
- if (int_n_data[i].bitsize > LONG_LONG_TYPE_SIZE
- && int_n_enabled_p[i])
+ if (int_n_enabled_p[i])
{
integer_types[itk_intN_0 + i * 2] = int_n_trees[i].signed_type;
integer_types[itk_unsigned_intN_0 + i * 2] = int_n_trees[i].unsigned_type;
--
2.7.4
[PATCH] Fix PR middle-end/86705
pr45678-2.c ICEs for msp430-elf with -mlarge, because an alignment of POINTER_SIZE is attempted. POINTER_SIZE with -mlarge is 20-bits, so further code in the middle-end that expects this to be a power or 2 causes odd alignments to be set, in this case eventually resulting in an ICE. The test ICEs on gcc-7-branch, gcc-8-branch, and current trunk. It successfully builds on gcc-6-branch. The failure is caused by r235172. Successfully bootstrapped and regtested the attached patch for x86-64-pc-linux-gnu, and msp430-elf with -mlarge, on trunk. Ok for gcc-7-branch, gcc-8-branch and trunk? >From e655a518a06a848dc398504f28272750e1a2be9f Mon Sep 17 00:00:00 2001 From: Jozef Lawrynowicz Date: Tue, 13 Mar 2018 11:25:56 + Subject: [PATCH] When aligning to POINTER_SIZE, round alignment to largest power of 2 that is <= POINTER_SIZE PR middle-end/86705 * gcc/cfgexpand.c (set_parm_rtl): Before using POINTER_SIZE as an alignment value, round it to the largest power of 2 less than or equal to itself. (expand_one_ssa_partition): Likewise. (expand_one_var): Likewise. --- gcc/cfgexpand.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c index d6e3c38..a56db7a 100644 --- a/gcc/cfgexpand.c +++ b/gcc/cfgexpand.c @@ -1258,9 +1258,12 @@ set_parm_rtl (tree parm, rtx x) pointer. ??? We've got a pseudo for sure here, do we actually dynamically allocate its spilling area if needed? ??? Isn't it a problem when POINTER_SIZE also exceeds - MAX_SUPPORTED_STACK_ALIGNMENT, as on cris and lm32? */ + MAX_SUPPORTED_STACK_ALIGNMENT, as on cris and lm32? + POINTER_SIZE may not be a power of 2 e.g. for msp430-elf with the large + data model, so align to the largest power of 2 that is + <= POINTER_SIZE. */ if (align > MAX_SUPPORTED_STACK_ALIGNMENT) - align = POINTER_SIZE; + align = (unsigned)1 << floor_log2 (POINTER_SIZE); record_alignment_for_reg_var (align); } @@ -1381,7 +1384,7 @@ expand_one_ssa_partition (tree var) /* If the variable alignment is very large we'll dynamicaly allocate it, which means that in-frame portion is just a pointer. */ if (align > MAX_SUPPORTED_STACK_ALIGNMENT) -align = POINTER_SIZE; +align = (unsigned)1 << floor_log2 (POINTER_SIZE); record_alignment_for_reg_var (align); @@ -1608,7 +1611,7 @@ expand_one_var (tree var, bool toplevel, bool really_expand) /* If the variable alignment is very large we'll dynamicaly allocate it, which means that in-frame portion is just a pointer. */ if (align > MAX_SUPPORTED_STACK_ALIGNMENT) - align = POINTER_SIZE; + align = (unsigned)1 << floor_log2 (POINTER_SIZE); } record_alignment_for_reg_var (align); -- 2.7.4
Re: [PATCH] Fix PR middle-end/86705
On 30/07/18 14:29, Richard Biener wrote: On Sun, Jul 29, 2018 at 6:27 PM Jozef Lawrynowicz wrote: pr45678-2.c ICEs for msp430-elf with -mlarge, because an alignment of POINTER_SIZE is attempted. POINTER_SIZE with -mlarge is 20-bits, so further code in the middle-end that expects this to be a power or 2 causes odd alignments to be set, in this case eventually resulting in an ICE. The test ICEs on gcc-7-branch, gcc-8-branch, and current trunk. It successfully builds on gcc-6-branch. The failure is caused by r235172. Successfully bootstrapped and regtested the attached patch for x86-64-pc-linux-gnu, and msp430-elf with -mlarge, on trunk. Ok for gcc-7-branch, gcc-8-branch and trunk? I wonder if most (if not all) places you touch want to use get_mode_alignment (Pmode) instead? (or ptr_mode) Anyhow, the patch is otherwise obvious though factoring the thing might be nice (thus my suggestion above...) Richard. Thanks for the suggestion, using GET_MODE_ALIGNMENT does seem like a neater idea. After retesting, I went ahead and committed the below patch onto trunk, will backport to gcc-7/8-branch later. diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c index d6e3c38..7353d5d 100644 --- a/gcc/cfgexpand.c +++ b/gcc/cfgexpand.c @@ -1257,10 +1257,10 @@ set_parm_rtl (tree parm, rtx x) allocate it, which means that in-frame portion is just a pointer. ??? We've got a pseudo for sure here, do we actually dynamically allocate its spilling area if needed? - ??? Isn't it a problem when POINTER_SIZE also exceeds - MAX_SUPPORTED_STACK_ALIGNMENT, as on cris and lm32? */ + ??? Isn't it a problem when Pmode alignment also exceeds + MAX_SUPPORTED_STACK_ALIGNMENT, as can happen on cris and lm32? */ if (align > MAX_SUPPORTED_STACK_ALIGNMENT) - align = POINTER_SIZE; + align = GET_MODE_ALIGNMENT (Pmode); record_alignment_for_reg_var (align); } @@ -1381,7 +1381,7 @@ expand_one_ssa_partition (tree var) /* If the variable alignment is very large we'll dynamicaly allocate it, which means that in-frame portion is just a pointer. */ if (align > MAX_SUPPORTED_STACK_ALIGNMENT) -align = POINTER_SIZE; +align = GET_MODE_ALIGNMENT (Pmode); record_alignment_for_reg_var (align); @@ -1608,7 +1608,7 @@ expand_one_var (tree var, bool toplevel, bool really_expand) /* If the variable alignment is very large we'll dynamicaly allocate it, which means that in-frame portion is just a pointer. */ if (align > MAX_SUPPORTED_STACK_ALIGNMENT) - align = POINTER_SIZE; + align = GET_MODE_ALIGNMENT (Pmode); } record_alignment_for_reg_var (align);
Re: [PATCH] Add -fgnu-retain/-fno-gnu-retain
On Tue, Feb 16, 2021 at 05:45:47PM +0100, Jakub Jelinek via Gcc-patches wrote: > On Mon, Feb 15, 2021 at 02:35:07PM -0800, H.J. Lu via Gcc-patches wrote: > > When building Linux kernel, ld in bninutils 2.36 with GCC 11 generates > > thousands of > > > > ld: warning: orphan section `.data.event_initcall_finish' from > > `init/main.o' being placed in section `.data.event_initcall_finish' > > ld: warning: orphan section `.data.event_initcall_start' from `init/main.o' > > being placed in section `.data.event_initcall_start' > > ld: warning: orphan section `.data.event_initcall_level' from `init/main.o' > > being placed in section `.data.event_initcall_level' > > > > Since these sections are marked with SHF_GNU_RETAIN, they are placed in > > separate sections. They become orphan sections since they aren't expected > > in the Linux kernel linker script. But orphan sections normally don't work > > well with the Linux kernel linker script and the resulting kernel crashed. > > > > Add -fgnu-retain to disable SHF_GNU_RETAIN for Linux kernel build with > > -fno-gnu-retain. > > I'd say this shows that the changing of meaning of "used" attribute wasn't > really a good idea, the Linux kernel certainly won't be the only problem > and people use "used" attribute for many reasons and don't necessarily want > the different sections or different behavior of those sections if they use > it. > > So, can't we instead: > 1) restore the old behavior of "used" by default > 2) add "retain" attribute that implies the SHF_GNU_RETAIN stuff and fails >if the configured assembler/linker doesn't support those > 3) add a non-default option through which one could opt in for "used" >attribute to imply retain attribute too for projects that want that? > In previous discussions, it seemed to me that there was general support for the "used" attribute implying SHF_GNU_RETAIN and saving symbols from linker garbage collection[1]. Of course, the current implementation results in undesirable behavior - the thought that all linker scripts not supporting uniquely named sections would need to be updated is quite alarming. It's a shame that all this extra complication is required, just because we cannot have a ".retain ", directive. My preferred vision for this functionality was: - SHF_GNU_RETAIN section flag indicates a section should be saved from linker garbage collection. - ".retain " assembler directive applies SHF_GNU_RETAIN to the section containing . - GCC "used" attribute emits a ".retain " directive for the symbol declaration is is applied to. Applying the "used" attribute to a symbol declaration does not change the structure of the object file, beyond applying SHF_GNU_RETAIN to the section containing that symbol. H.J. vetoed ".retain "[2], since it fails the predicate: Assembler directive referring to a symbol must operate on the symbol table. So because of this veto, we have compromised on "code quality" so far, since any linker script not supporting named sections, used to link an application containing "used" symbols (now put into their own section) has potential undefined behavior. With the new proposed change to use a "retain" attribute, we now compromise on functionality, since the "used" attribute saving symbols from linker garbage collection is disabled by default. All because we cannot introduce an exception to the above predicate. I would like to re-open discussions on whether a ".retain directive is acceptable. This would enable "used" to imply SHF_GNU_RETAIN, without changing the structure of the object file, thereby allowing the new functionality to be used without linker script modifications. If a Binutils global maintainer could side one way or the other on ".retain " (an opinion was never given by the Binutils maintainers when we had the discussions on that mailing list, although Jeff did support .retain in the GCC discussions[3]), then it will be easier to proceed knowing definitively that ".retain" is rejected and we have no choice but to go this route of having a separate "retain" attribute. Thanks, Jozef [1] https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557097.html [2] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558123.html [3] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558398.html
Re: [PATCH] Add -fgnu-retain/-fno-gnu-retain
On Thu, Feb 18, 2021 at 11:19:50AM +0100, Richard Biener via Binutils wrote: > On Wed, Feb 17, 2021 at 12:25 PM Jozef Lawrynowicz > wrote: > > > > On Tue, Feb 16, 2021 at 05:45:47PM +0100, Jakub Jelinek via Gcc-patches > > wrote: > > > On Mon, Feb 15, 2021 at 02:35:07PM -0800, H.J. Lu via Gcc-patches wrote: > > > > When building Linux kernel, ld in bninutils 2.36 with GCC 11 generates > > > > thousands of > > > > > > > > ld: warning: orphan section `.data.event_initcall_finish' from > > > > `init/main.o' being placed in section `.data.event_initcall_finish' > > > > ld: warning: orphan section `.data.event_initcall_start' from > > > > `init/main.o' being placed in section `.data.event_initcall_start' > > > > ld: warning: orphan section `.data.event_initcall_level' from > > > > `init/main.o' being placed in section `.data.event_initcall_level' > > > > > > > > Since these sections are marked with SHF_GNU_RETAIN, they are placed in > > > > separate sections. They become orphan sections since they aren't > > > > expected > > > > in the Linux kernel linker script. But orphan sections normally don't > > > > work > > > > well with the Linux kernel linker script and the resulting kernel > > > > crashed. > > > > > > > > Add -fgnu-retain to disable SHF_GNU_RETAIN for Linux kernel build with > > > > -fno-gnu-retain. > > > > > > I'd say this shows that the changing of meaning of "used" attribute wasn't > > > really a good idea, the Linux kernel certainly won't be the only problem > > > and people use "used" attribute for many reasons and don't necessarily > > > want > > > the different sections or different behavior of those sections if they use > > > it. > > > > > > So, can't we instead: > > > 1) restore the old behavior of "used" by default > > > 2) add "retain" attribute that implies the SHF_GNU_RETAIN stuff and fails > > >if the configured assembler/linker doesn't support those > > > 3) add a non-default option through which one could opt in for "used" > > >attribute to imply retain attribute too for projects that want that? > > > > > > > In previous discussions, it seemed to me that there was general support > > for the "used" attribute implying SHF_GNU_RETAIN and saving symbols from > > linker garbage collection[1]. Of course, the current implementation > > results in undesirable behavior - the thought that all linker scripts > > not supporting uniquely named sections would need to be updated is quite > > alarming. > > > > It's a shame that all this extra complication is required, just because > > we cannot have a ".retain ", directive. > > > > My preferred vision for this functionality was: > > - SHF_GNU_RETAIN section flag indicates a section should be saved > > from linker garbage collection. > > - ".retain " assembler directive applies SHF_GNU_RETAIN > > to the section containing . > > - GCC "used" attribute emits a ".retain " directive for > > the symbol declaration is is applied to. Applying the "used" > > attribute to a symbol declaration does not change the structure of > > the object file, beyond applying SHF_GNU_RETAIN to the section > > containing that symbol. > > > > H.J. vetoed ".retain "[2], since it fails the predicate: > > Assembler directive referring to a symbol must operate on the symbol > > table. > > > > So because of this veto, we have compromised on "code quality" so far, > > since any linker script not supporting named sections, used to link an > > application containing "used" symbols (now put into their own section) has > > potential undefined behavior. > > > > With the new proposed change to use a "retain" attribute, we now > > compromise on functionality, since the "used" attribute saving symbols > > from linker garbage collection is disabled by default. > > > > All because we cannot introduce an exception to the above predicate. > > > > I would like to re-open discussions on whether a ".retain > > directive is acceptable. This would enable "used" to imply > > SHF_GNU_RETAIN, without changing the structure of the object file, > >
Re: [PATCH] Add -fgnu-retain/-fno-gnu-retain
On Thu, Feb 18, 2021 at 11:22:42PM +1030, Alan Modra via Binutils wrote: > On Wed, Feb 17, 2021 at 11:23:12AM +0000, Jozef Lawrynowicz wrote: > > In previous discussions, it seemed to me that there was general support > > for the "used" attribute implying SHF_GNU_RETAIN and saving symbols from > > linker garbage collection[1]. Of course, the current implementation > > results in undesirable behavior - the thought that all linker scripts > > not supporting uniquely named sections would need to be updated is quite > > alarming. > > > > It's a shame that all this extra complication is required, just because > > we cannot have a ".retain ", directive. > > Is that true? Isn't the problem really that retained sections are > named as if -ffunction-sections/-fdata-sections were in force? And > that is due to wanting separate sections so that garbage collection > works, since SHF_GNU_RETAIN is all about linker garbage collection. > > I don't see how having a ".retain " would help much. In the early GCC implementations, there were issues getting the default "unnamed" section names for symbols in GCC[1]. This prevented us from being able to simply emit a .section directive, replacing a .text/.data etc. directive. H.J. improved upon my initial attempt for doing this, but then the approach was changed to always put "used" symbols in uniquely named sections, and I don't know why. Hopefully H.J. can clarify why "used" symbols had to be put in sections with unique names. With a ".retain " directive, GCC doesn't need to work out the section associated with a symbol, alleviating the above issues, so we don't need to change the section a symbol is in to apply SHF_GNU_RETAIN to that section. The bugs we are seeing now (e.g. PR 99113) are because some linker scripts aren't set up to handle uniquely named sections. With ".retain ", the linker scripts will work without issues because we have not changed the layout of sections. > > > My preferred vision for this functionality was: > > - SHF_GNU_RETAIN section flag indicates a section should be saved > > from linker garbage collection. > > - ".retain " assembler directive applies SHF_GNU_RETAIN > > to the section containing . > > - GCC "used" attribute emits a ".retain " directive for > > the symbol declaration is is applied to. Applying the "used" > > attribute to a symbol declaration does not change the structure of > > the object file, beyond applying SHF_GNU_RETAIN to the section > > containing that symbol. > > That description seems to say that a ".retain foo" would mean > everything in foo's section is kept. If foo's section was the usual > .data, you've kept virtually everything from garbage collection. Yes, sort of. Everything from .data in the input object file - only the .data containing foo. Unused .data sections from other object files will be garbage collected, as required. The user has marked "foo" as used after all, so the linker is treating it as if it is linked to the entry point of the program in some way. Since garbage collection only works at the section level, we can't do any better - unless -ffunction/fdata-sections is used. > Surely you don't expect ".retain foo" to create a separate .data > section for foo? If you do, I'm strongly against that idea. No, I don't want ".retain" to change anything about the structure or contents of a section, beyond applying SHF_GNU_RETAIN to it. > > Note that gas indeed supports multiple sections named .data that can > serve the same purpose as -fdata-sections. See the gas doc for the > optional .section field "unique". That might be the best way to avoid > an under-the-hood -ffunction-sections/-fdata-sections. As mentioned above, there were issues getting the default "unnamed" section names for symbols in GCC. If we can reliably get the name of an unnamed section, then we could potentially do away with .retain. "unique" would allow finer granularity of garbage collection, but it is changing the structure of the object file, which I think we should try to avoid, as it leads to issues like we are seeing now. Thanks, Jozef [1] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557914.html > > -- > Alan Modra > Australia Development Lab, IBM
Re: [PATCH] Add -fgnu-retain/-fno-gnu-retain
On Thu, Feb 18, 2021 at 01:08:54PM +0100, Jakub Jelinek via Gcc-patches wrote: > On Thu, Feb 18, 2021 at 12:00:59PM +0000, Jozef Lawrynowicz wrote: > > If we can add ".retain " to GAS, then I agree, current GCC > > SHF_GNU_RETAIN behavior should be removed. For GCC 12 we leverage > > .retain to implement the functionality where "used" saves symbols form > > linker garbage collection, without modifying section names or the > > structure of the object file. > > Even in that case I think it is a bad idea to change the "used" attribute > behavior, not everyone using "used" attribute needs or wants that behavior, > so it should be a functionality provided by a separate new attribute. I think it is a enhancement, and true to the spirit of the attribute, for "used" to save a symbol from linker garbage collection. Why should "used" mean: Save this symbol from compiler optimization, but allow the linker to remove it. I can't currently think of a use case where a "used" symbol should be kept by the compiler but removed by the linker. Often we see KEEP directives in linker scripts accompanying "used" in the source code. libgcc/crtstuff.c is a good example. GNU linker scripts need many specific KEEP directives to handle all the "used" symbols. If a developer marks a symbol as "used" in the source code, I think the intuitive thing is for that symbol to be present in the linked output file. Jozef
Re: [PATCH] Add -fgnu-retain/-fno-gnu-retain
On Thu, Feb 18, 2021 at 03:38:46PM +0100, Jakub Jelinek via Gcc-patches wrote: > On Thu, Feb 18, 2021 at 02:22:35PM +0000, Jozef Lawrynowicz wrote: > > I think it is a enhancement, and true to the spirit of the attribute, > > for "used" to save a symbol from linker garbage collection. > > > > Why should "used" mean: > > Save this symbol from compiler optimization, but allow the linker to > > remove it. > > > > I can't currently think of a use case where a "used" symbol should be > > kept by the compiler but removed by the linker. > > > > Often we see KEEP directives in linker scripts accompanying > > "used" in the source code. libgcc/crtstuff.c is a good example. GNU > > linker scripts need many specific KEEP directives to handle all the > > "used" symbols. > > > > If a developer marks a symbol as "used" in the source code, I think the > > intuitive thing is for that symbol to be present in the linked output > > file. > > There are many reasons why a symbol is marked "used", one of the very often > seen ones is e.g. that the symbol is referenced from inline asm. > You don't need to guard such symbols against GC. I suppose, for the cases where you cannot use extended ASM and therefore cannot specify the symbol as an operand to the asm statement. I wonder if that really could not be worked around though, since it would only be required for statics, and if it would even have a negative impact in practice. I am just conflicted because when I first proposed this new functionality, (as a separate "retain" attribute in fact), the feedback from a few different people was that it would be better to leverage "used" instead of creating a separate attribute. It seemed like a good idea to me. At this point, a separate "retain" attribute seems like an OK compromise. Thanks, Jozef
[RFC] Add support for the "retain" attribute utilizing SHF_GNU_RETAIN
a declaration, there is merit to having a separate "retain"
attribute that has this behavior.
To summarize the talking points:
- Any downsides to the new "retain" attribute creating a new, uniquely
named section for the declaration, with SHF_GNU_RETAIN applied?
- Should the "used" attribute apply SHF_GNU_RETAIN in some way?
- Is "retain" even required, could "used" be modified to create a new,
uniquely named section for the declaration with SHF_GNU_RETAIN
applied?
Currently, my opinion is that the best way forward is:
- New "retain" attribute places the declaration in a new, uniquely named
section with SHF_GNU_RETAIN applied
- "used" attribute is modified so the section containing the declaration
has SHF_GNU_RETAIN applied (option 1 from above) ..
* .. as long as there are no negative consequences to "used" affecting
linker behavior for the wider ecosystem of targets, and
* the technical challenges for implementing it with this method can be
solved.
I've attached 3 patches for reference:
- Binutils handling of SHF_GNU_RETAIN in binutils-SHF_GNU_RETAIN.patch
- New "retain" GCC attribute in gcc-retain-attribute.patch
- "used" applies SHF_GNU_RETAIN (by creating a new section) in
gcc-used-applies-SHF_GNU_RETAIN.patch
Thanks,
Jozef
>From 84515f9caed188ebe36ac45217f491f082d9d3e9 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Tue, 8 Sep 2020 20:41:03 +0100
Subject: [PATCH] Add support for "retain" attribute
---
gcc/c-family/c-attribs.c | 43 +++
gcc/cfgexpand.c| 5 +-
gcc/config.in | 6 ++
gcc/configure | 36 ++
gcc/configure.ac | 9 +++
gcc/doc/extend.texi| 23 ++
gcc/output.h | 3 +-
gcc/testsuite/c-c++-common/attr-retain-1.c | 83 ++
gcc/testsuite/c-c++-common/attr-retain-2.c | 70 ++
gcc/testsuite/c-c++-common/attr-retain-3.c | 81 +
gcc/testsuite/c-c++-common/attr-retain-4.c | 10 +++
gcc/testsuite/lib/target-supports.exp | 9 +++
gcc/tree-core.h| 1 +
gcc/tree.h | 7 ++
gcc/varasm.c | 8 ++-
15 files changed, 390 insertions(+), 4 deletions(-)
create mode 100644 gcc/testsuite/c-c++-common/attr-retain-1.c
create mode 100644 gcc/testsuite/c-c++-common/attr-retain-2.c
create mode 100644 gcc/testsuite/c-c++-common/attr-retain-3.c
create mode 100644 gcc/testsuite/c-c++-common/attr-retain-4.c
diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
index 70b00037d98..e9051832252 100644
--- a/gcc/c-family/c-attribs.c
+++ b/gcc/c-family/c-attribs.c
@@ -153,6 +153,7 @@ static tree handle_designated_init_attribute (tree *, tree,
tree, int, bool *);
static tree handle_patchable_function_entry_attribute (tree *, tree, tree,
int, bool *);
static tree handle_copy_attribute (tree *, tree, tree, int, bool *);
+static tree handle_retain_attribute (tree *, tree, tree, int, bool *);
/* Helper to define attribute exclusions. */
#define ATTR_EXCL(name, function, type, variable) \
@@ -491,6 +492,8 @@ const struct attribute_spec c_common_attribute_table[] =
handle_noinit_attribute, attr_noinit_exclusions },
{ "access",1, 3, false, true, true, false,
handle_access_attribute, NULL },
+ { "retain",0, 0, true, false, false, false,
+ handle_retain_attribute, NULL },
{ NULL, 0, 0, false, false, false, false, NULL, NULL }
};
@@ -2562,6 +2565,46 @@ handle_alias_ifunc_attribute (bool is_alias, tree *node,
tree name, tree args,
decl, is_alias ? "alias" : "ifunc");
}
+ return NULL_TREE;
+}
+
+/* Handle a "retain" attribute; arguments as in
+ struct attribute_spec.handler. */
+
+static tree
+handle_retain_attribute (tree * pnode ATTRIBUTE_UNUSED,
+tree name ATTRIBUTE_UNUSED,
+tree args ATTRIBUTE_UNUSED,
+intflags ATTRIBUTE_UNUSED,
+bool *no_add_attrs ATTRIBUTE_UNUSED)
+{
+#if HAVE_GAS_SECTION_RETAIN
+ tree node = *pnode;
+
+ if (!targetm_common.have_named_sections)
+{
+ warning (OPT_Wattributes, "%qE attribute not supported by this target",
+ name);
+ *no_add_attrs = true;
+}
+ else if (TREE_CODE (node) == FUNCTION_DECL
+ || (VAR_P (node) && TREE_STATIC (node)))
+{
+ TREE_USED (node) = 1;
+ DECL_PRESERVE_P (node) = 1;
+ DECL_RETAIN_P (node) = 1;
+ if
[PATCH][MSP430] Use hardware multiply routine to perform HImode widening multiplication (mulhisi3)
For MSP430 in some configurations, GCC will generate code for mulhisi3 by
inserting instructions to widen each 16-bit operand before calling a library
routine for mulsi3.
However, there exists a hardware multiply routine to perform this widening
multiplication, but it is only made use of at -O3 where it is inserted
inline into program.
We can reduce code size and improve performance by always calling the mspabi
helper function to perform this widening multiplication when hardware multiply
is available.
I also benchmarked the effect of using a library function for mulsidi3
but it resulted in slower execution both with and without hardware multiply
support. It also increased code size for a variety of programs.
Successfully regtested on trunk.
Additionally regtested msp430.exp at -O1, -O2, -O3 and -Os.
There are tests which check each supported hardware multiply option
executes correctly, so running at these optimization levels verifies the changes
in this patch.
Ok for trunk?
>From 695ae0e560396034bc1fc2e9d9e601ab7b3d901b Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Wed, 23 Oct 2019 13:19:45 +0100
Subject: [PATCH] MSP430: Use mspabi helper function to perform HImode widening
multiplication
gcc/ChangeLog:
2019-10-23 Jozef Lawrynowicz
* config/msp430/msp430.c (msp430_expand_helper): Support expansion of
calls to __mspabi_mpy* functions.
* config/msp430/msp430.md (mulhisi3): New define_expand.
(umulhisi3): New define_expand.
(*mulhisi3_inline): Use old mulhisi3 define_insn.
(*umulhisi3_inline): Use old umulhisi3 define_insn.
---
gcc/config/msp430/msp430.c | 69 ++---
gcc/config/msp430/msp430.md | 46 +++--
2 files changed, 101 insertions(+), 14 deletions(-)
diff --git a/gcc/config/msp430/msp430.c b/gcc/config/msp430/msp430.c
index cd394333983..8a5579f8bce 100644
--- a/gcc/config/msp430/msp430.c
+++ b/gcc/config/msp430/msp430.c
@@ -53,6 +53,7 @@
static void msp430_compute_frame_info (void);
+static bool use_32bit_hwmult (void);
@@ -2710,7 +2711,7 @@ void
msp430_expand_helper (rtx *operands, const char *helper_name,
bool const_variants)
{
- rtx c, f;
+ rtx c, fusage, fsym;
char *helper_const = NULL;
int arg1 = 12;
int arg2 = 13;
@@ -2719,8 +2720,14 @@ msp430_expand_helper (rtx *operands, const char *helper_name,
machine_mode arg1mode = GET_MODE (operands[1]);
machine_mode arg2mode = GET_MODE (operands[2]);
int have_430x = msp430x ? 1 : 0;
+ int expand_mpy = strncmp (helper_name, "__mspabi_mpy",
+ sizeof ("__mspabi_mpy") - 1) == 0;
+ /* This function has been used incorrectly if CONST_VARIANTS is TRUE for a
+ hwmpy function. */
+ gcc_assert (!(expand_mpy && const_variants));
- if (CONST_INT_P (operands[2]))
+ /* Emit size-optimal insns for small shifts we can easily do inline. */
+ if (CONST_INT_P (operands[2]) && !expand_mpy)
{
int i;
@@ -2737,6 +2744,10 @@ msp430_expand_helper (rtx *operands, const char *helper_name,
}
}
+ if (arg1mode != VOIDmode && arg2mode != VOIDmode)
+/* Modes of arguments must be equal if not constants. */
+gcc_assert (arg1mode == arg2mode);
+
if (arg1mode == VOIDmode)
arg1mode = arg0mode;
if (arg2mode == VOIDmode)
@@ -2749,12 +2760,13 @@ msp430_expand_helper (rtx *operands, const char *helper_name,
}
else if (arg1mode == DImode)
{
- /* Shift value in R8:R11, shift amount in R12. */
arg1 = 8;
arg1sz = 4;
arg2 = 12;
}
+ /* Use the "const_variant" of a shift library function if requested.
+ These are faster, but have larger code size. */
if (const_variants
&& CONST_INT_P (operands[2])
&& INTVAL (operands[2]) >= 1
@@ -2768,25 +2780,58 @@ msp430_expand_helper (rtx *operands, const char *helper_name,
(int) INTVAL (operands[2]));
}
+ /* Setup the arguments to the helper function. */
emit_move_insn (gen_rtx_REG (arg1mode, arg1),
operands[1]);
if (!helper_const)
emit_move_insn (gen_rtx_REG (arg2mode, arg2),
operands[2]);
- c = gen_call_value_internal (gen_rtx_REG (arg0mode, 12),
- gen_rtx_SYMBOL_REF (VOIDmode, helper_const
- ? helper_const
- : helper_name),
- GEN_INT (0));
+ if (expand_mpy)
+{
+ if (msp430_use_f5_series_hwmult ())
+ fsym = gen_rtx_SYMBOL_REF (VOIDmode, concat (helper_name,
+ "_f5hw", NULL));
+ else if (use_32bit_hwmult ())
+ {
+ /* When the arguments are 16-bits, the 16-bit hardware multiplier is
+ used. */
+ if (arg1mode == HImode)
+ fsym = gen_rtx_SYMBOL_REF (VOIDmode, concat (helper_name,
+ "_hw", NULL));
+ else
+ fsym = gen_rtx_SYMBOL_REF (VOIDmode, concat (helper_name,
+ "_hw32", NULL));
+ }
+ /* 16-bit hardware multiply. */
+ else if (msp430_has_hwmult ())
[COMMITTED][MSP430] Cleanup code in hardware multiply library
The libgcc hardware multiply library for MSP430 uses its own naming scheme, which has some similarities, but is still different, to how TI names the registers across the documentation for all its MSP430 devices. Furthermore, 32-bit and f5series specific hwmult registers have their addresses hard-coded into the assembly code which prepares the hardware multiply routines. The attached patch standardizes the naming scheme to match how TI names the registers. It also defines new symbols for the currently hard-coded 32-bit and f5series hardware multiply registers, to improve readability, ease the effort in implementing further hardware multiply support and help prevent bugs from mis-typed addresses. The patch also has a small fix to the syntax used in some assembly code. This code doesn't appear to ever actually get run but is retained in case we need it in the future. Regtested and applied on trunk as obvious. >From 6f6e061fa292c7afd699294163a67e39732aedec Mon Sep 17 00:00:00 2001 From: jozefl Date: Wed, 23 Oct 2019 16:52:47 + Subject: [PATCH] 2019-10-23 Jozef Lawrynowicz * config/msp430/lib2hw_mul.S: Fix wrong syntax in branch instruction. s/RESULT_LO/RESLO, s/RESULT_HI/RESHI, s/MPY_OP1/MPY, s/MPY_OP1_S/MPYS, s/MAC_OP1/MAC, s/MPY_OP2/OP2, s/MAC_OP2/OP2. Define symbols for 32-bit and f5series hardware multiply register addresses. Replace hard-coded register addresses with symbols. Fix "_mspabi*" typo. Fix whitespace. * config/msp430/lib2mul.c: Add comment. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@277340 138bc75d-0d04-0410-961f-82ee72b054a4 --- libgcc/ChangeLog | 12 +++ libgcc/config/msp430/lib2hw_mul.S | 170 ++ libgcc/config/msp430/lib2mul.c| 3 + 3 files changed, 118 insertions(+), 67 deletions(-) diff --git a/libgcc/ChangeLog b/libgcc/ChangeLog index ed0e9006377..99199944652 100644 --- a/libgcc/ChangeLog +++ b/libgcc/ChangeLog @@ -1,3 +1,15 @@ +2019-10-23 Jozef Lawrynowicz + + * config/msp430/lib2hw_mul.S: Fix wrong syntax in branch instruction. + s/RESULT_LO/RESLO, s/RESULT_HI/RESHI, s/MPY_OP1/MPY, + s/MPY_OP1_S/MPYS, s/MAC_OP1/MAC, s/MPY_OP2/OP2, s/MAC_OP2/OP2. + Define symbols for 32-bit and f5series hardware multiply + register addresses. + Replace hard-coded register addresses with symbols. + Fix "_mspabi*" typo. + Fix whitespace. + * config/msp430/lib2mul.c: Add comment. + 2019-10-15 John David Anglin * config/pa/fptr.c (_dl_read_access_allowed): Change argument to diff --git a/libgcc/config/msp430/lib2hw_mul.S b/libgcc/config/msp430/lib2hw_mul.S index 1a0e6e84ee9..894c551cbf0 100644 --- a/libgcc/config/msp430/lib2hw_mul.S +++ b/libgcc/config/msp430/lib2hw_mul.S @@ -81,9 +81,9 @@ .type \gcc_name , @function \gcc_name: #ifdef __MSP430X_LARGE__ - BRA \eabi_soft_name + BRA #\eabi_soft_name #else - BR \eabi_soft_name + BR #\eabi_soft_name #endif .size \gcc_name , . - \gcc_name .popsection @@ -109,7 +109,7 @@ MOV.W &\RESULT, r12 ; Move result into return register .endm -.macro mult1632 OP1, OP2, RESULT_LO, RESULT_HI +.macro mult1632 OP1, OP2, RESLO, RESHI ;* * 16-bit hardware multiply with a 32-bit result: ;* int32 = int16 * int16 ;* uint32 = uint16 * uint16 @@ -127,11 +127,11 @@ MOV.W r12, &\OP1 ; Load operand 1 into multiplier MOV.W r13, &\OP2 ; Load operand 2 which triggers MPY - MOV.W &\RESULT_LO, r12 ; Move low result into return register - MOV.W &\RESULT_HI, r13 ; Move high result into return register + MOV.W &\RESLO, r12 ; Move low result into return register + MOV.W &\RESHI, r13 ; Move high result into return register .endm -.macro mult32 OP1, OP2, MAC_OP1, MAC_OP2, RESULT_LO, RESULT_HI +.macro mult32 OP1, OP2, MAC_OP1, MAC_OP2, RESLO, RESHI ;* * 32-bit hardware multiply with a 32-bit result using 16 multiply and accumulate: ;* int32 = int32 * int32 ;* @@ -149,16 +149,16 @@ MOV.W r12, &\OP1 ; Load operand 1 Low into multiplier MOV.W r14, &\OP2 ; Load operand 2 Low which triggers MPY MOV.W r12, &\MAC_OP1 ; Load operand 1 Low into mac - MOV.W &\RESULT_LO, r12 ; Low 16-bits of result ready for return - MOV.W &\RESULT_HI, &\RESULT_LO; MOV intermediate mpy high into low + MOV.W &\RESLO, r12 ; Low 16-bits of result ready for return + MOV.W &\RESHI, &\RESLO ; MOV intermediate mpy high into low MOV.W r15, &\MAC_OP2 ; Load operand 2 High, trigger MAC MOV.W r13, &\MAC_OP1 ; Load operand 1 High MOV.W r14, &\MAC_OP2 ; Load operand 2 Lo, trigger MAC - MOV.W &\RESULT_LO, r13; Upper 16-bits result ready for return + MOV.W &\RESLO, r13 ; Upper 16-bits result ready for return .endm -.macro mult32_hw OP1_LO OP1_HI OP2_LO OP2_HI RESULT_LO RESULT_HI +.macro mult32_hw OP1_LO OP1_HI OP2_LO OP2_HI RESLO RESHI ;* * 32-bit hardware multiply with a 32-bit result ;* int32 = int32 * int32 ;* @@ -177,8 +177,8 @@ MOV.W
[COMMITTED][MSP430] Fix incorrect determination of hardware multiply support
Some areas of the MSP430 backend modify code generation based on whether the
target device has hardware multiply support. However comparisons of the form
"msp430_hwmult_type != MSP430_HWMULT_NONE" are invalid, since MSP430_HWMULT_AUTO
might be set (to infer hwmult support from the MCU specified with -mmcu), and
the target might still not have hardware multiply support.
This is causing hardware multiply instructions to be generated for 16-bit and
32-bit widening multiplication at -O3, when the target does not have hardware
multiply support. This results in incorrect execution.
This patch fixes that and replaces the msp430_no_hwmult() function with
msp430_has_hwmult(), since the former was only ever used as
"!msp430_no_hwmult()".
Regtested and applied on trunk as obvious.
>From c5edfbaf16a73b91faa30a8b4ce9204f0ff02d3e Mon Sep 17 00:00:00 2001
From: jozefl
Date: Wed, 23 Oct 2019 16:55:44 +
Subject: [PATCH] 2019-10-23 Jozef Lawrynowicz
* config/msp430/msp430-protos.h (msp430_has_hwmult): New.
* config/msp430/msp430.c (msp430_no_hwmult): Remove.
(msp430_has_hwmult): New.
(msp430_output_labelref):
s/msp430_hwmult_type != MSP430_HWMULT_NONE/msp430_has_hwmult ()/
* config/msp430/msp430.md (mulhisi3): Likewise.
(umulhisi3): Likewise.
(mulsidi3): Likewise.
(umulsidi3): Likewise.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@277341 138bc75d-0d04-0410-961f-82ee72b054a4
---
gcc/ChangeLog | 12
gcc/config/msp430/msp430-protos.h | 1 +
gcc/config/msp430/msp430.c| 22 --
gcc/config/msp430/msp430.md | 8
4 files changed, 29 insertions(+), 14 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index ad2cb01d49a..7dc6885399c 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,15 @@
+2019-10-23 Jozef Lawrynowicz
+
+ * config/msp430/msp430-protos.h (msp430_has_hwmult): New.
+ * config/msp430/msp430.c (msp430_no_hwmult): Remove.
+ (msp430_has_hwmult): New.
+ (msp430_output_labelref):
+ s/msp430_hwmult_type != MSP430_HWMULT_NONE/msp430_has_hwmult ()/
+ * config/msp430/msp430.md (mulhisi3): Likewise.
+ (umulhisi3): Likewise.
+ (mulsidi3): Likewise.
+ (umulsidi3): Likewise.
+
2019-10-23 Jan Hubicka
PR ipa/92074
diff --git a/gcc/config/msp430/msp430-protos.h b/gcc/config/msp430/msp430-protos.h
index 37ca48297ac..98470ef647e 100644
--- a/gcc/config/msp430/msp430-protos.h
+++ b/gcc/config/msp430/msp430-protos.h
@@ -48,6 +48,7 @@ int msp430_split_addsi (rtx *);
voidmsp430_start_function (FILE *, const char *, tree);
rtx msp430_subreg (machine_mode, rtx, machine_mode, int);
boolmsp430_use_f5_series_hwmult (void);
+bool msp430_has_hwmult (void);
bool msp430_op_not_in_high_mem (rtx op);
#endif /* GCC_MSP430_PROTOS_H */
diff --git a/gcc/config/msp430/msp430.c b/gcc/config/msp430/msp430.c
index 31029395c3d..cd394333983 100644
--- a/gcc/config/msp430/msp430.c
+++ b/gcc/config/msp430/msp430.c
@@ -3097,20 +3097,22 @@ use_32bit_hwmult (void)
/* Returns true if the current MCU does not have a
hardware multiplier of any kind. */
-static bool
-msp430_no_hwmult (void)
+bool
+msp430_has_hwmult (void)
{
static const char * cached_match = NULL;
static bool cached_result;
if (msp430_hwmult_type == MSP430_HWMULT_NONE)
-return true;
+return false;
+ /* TRUE for any other explicit hwmult specified. */
if (msp430_hwmult_type != MSP430_HWMULT_AUTO)
-return false;
+return true;
+ /* Now handle -mhwmult=auto. */
if (target_mcu == NULL)
-return true;
+return false;
if (target_mcu == cached_match)
return cached_result;
@@ -3119,11 +3121,11 @@ msp430_no_hwmult (void)
msp430_extract_mcu_data (target_mcu);
if (extracted_mcu_data.name != NULL)
-return cached_result = extracted_mcu_data.hwmpy == 0;
+return cached_result = extracted_mcu_data.hwmpy != 0;
/* If we do not recognise the MCU name, we assume that it does not support
any kind of hardware multiply - this is the safest assumption to make. */
- return cached_result = true;
+ return cached_result = false;
}
/* This function does the same as the default, but it will replace GCC
@@ -3143,13 +3145,13 @@ msp430_output_labelref (FILE *file, const char *name)
/* If we have been given a specific MCU name then we may be
able to make use of its hardware multiply capabilities. */
- if (msp430_hwmult_type != MSP430_HWMULT_NONE)
+ if (msp430_has_hwmult ())
{
if (strcmp ("__mspabi_mpyi", name) == 0)
{
if (msp430_use_f5_series_hwmult ())
name = "__mulhi2_f5";
- else if (! msp430_no_hwmult ())
+ else
name = "__mulhi2";
}
else if (strcmp ("__mspabi_mpyl", name) == 0)
@@ -3158,7 +3160,7 @@ msp430_output_labelref (FILE *file, const char *name)
name = "__mulsi2_f5";
else if (use_32bit_hwmult ())
name = "__mulsi2_hw32";
- else if (!
[COMMITTED][MSP430] Tweaks to generation of 430X instructions
This patch makes a couple of simple tweaks to improve code generation for the
MSP430 430X ISA.
"Address-word instructions" support 20-bit operands without the extension word
required by regular 430X instructions. Using them where possible reduces code
size and improves performance.
We use the "Ya" constraint to indicate special cases the address-word "MOVA"
instruction can be used. The indirect auto-increment addressing mode can be
used with the source operand of a MOVA instructions, so this patch allows
the Ya constraint to match the (mem (post_inc)) RTX.
Similarly, the RRAM and RLAM rotate instructions do not use the extension word
that their RRAX and RLAX counterparts require. However, their use is limited to
shifting a register by a constant between 1 and 4 bits. This patch ensures they
get used when possible by extending the 430x_shift_left and
430x_arithmetic_shift_right insn patterns.
Successfully regtested for msp430-elf on trunk in the small and large memory
models.
Committed to trunk as obvious.
>From 47e4f7397a43c86a7d483da1aa914018d52d9e5d Mon Sep 17 00:00:00 2001
From: jozefl
Date: Thu, 24 Oct 2019 13:34:54 +
Subject: [PATCH] MSP430: Tweaks to generation of 430X instructions
gcc/ChangeLog:
2019-10-24 Jozef Lawrynowicz
* config/msp430/constraints.md: Allow post_inc for "Ya" constraint.
* config/msp430/msp430.md (430x_shift_left): Use RLAM when the constant
shift amount is between 1 and 4.
(430x_arithmetic_shift_right): Use RRAM when the constant shift amount
is between 1 and 4.
gcc/testsuite/ChangeLog:
2019-10-24 Jozef Lawrynowicz
* gcc.target/msp430/emulate-slli.c: Skip for -mcpu=msp430.
Add shift by a constant 5 bits.
Update scan-assembler directives.
* gcc.target/msp430/emulate-srai.c: Likewise.
* gcc.target/msp430/emulate-srli.c: Skip for -mcpu=msp430.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@277394 138bc75d-0d04-0410-961f-82ee72b054a4
---
gcc/ChangeLog | 8
gcc/config/msp430/constraints.md | 1 +
gcc/config/msp430/msp430.md| 12
gcc/testsuite/ChangeLog| 8
gcc/testsuite/gcc.target/msp430/emulate-slli.c | 6 +-
gcc/testsuite/gcc.target/msp430/emulate-srai.c | 6 +-
gcc/testsuite/gcc.target/msp430/emulate-srli.c | 1 +
7 files changed, 36 insertions(+), 6 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index d09b72d2b16..eb0a2f9b510 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,11 @@
+2019-10-24 Jozef Lawrynowicz
+
+ * config/msp430/constraints.md: Allow post_inc for "Ya" constraint.
+ * config/msp430/msp430.md (430x_shift_left): Use RLAM when the constant
+ shift amount is between 1 and 4.
+ (430x_arithmetic_shift_right): Use RRAM when the constant shift amount
+ is between 1 and 4.
+
2019-10-24 Richard Biener
PR tree-optimization/92205
diff --git a/gcc/config/msp430/constraints.md b/gcc/config/msp430/constraints.md
index d01bcf9a242..49fc769ec74 100644
--- a/gcc/config/msp430/constraints.md
+++ b/gcc/config/msp430/constraints.md
@@ -82,6 +82,7 @@
(match_test ("CONST_INT_P (XEXP (XEXP (op, 0), 1))"))
(match_test ("IN_RANGE (INTVAL (XEXP (XEXP (op, 0), 1)), HOST_WIDE_INT_M1U << 15, (1 << 15)-1)"
(match_code "reg" "0")
+ (match_code "post_inc" "0")
)))
(define_constraint "Yc"
diff --git a/gcc/config/msp430/msp430.md b/gcc/config/msp430/msp430.md
index e5ba445c60d..ed4c370261a 100644
--- a/gcc/config/msp430/msp430.md
+++ b/gcc/config/msp430/msp430.md
@@ -875,8 +875,10 @@
(match_operand2 "immediate_operand" "n")))]
"msp430x"
"*
- if (INTVAL (operands[2]) > 0 && INTVAL (operands[2]) < 16)
-return \"rpt\t%2 { rlax.w\t%0\";
+ if (INTVAL (operands[2]) > 0 && INTVAL (operands[2]) < 5)
+return \"RLAM.W\t%2, %0\";
+ else if (INTVAL (operands[2]) >= 5 && INTVAL (operands[2]) < 16)
+return \"RPT\t%2 { RLAX.W\t%0\";
return \"# nop left shift\";
"
)
@@ -960,8 +962,10 @@
(match_operand2 "immediate_operand" "n")))]
"msp430x"
"*
- if (INTVAL (operands[2]) > 0 && INTVAL (operands[2]) < 16)
-return \"rpt\t%2 { rrax.w\t%0\";
+ if (INTVAL (operands[2]) > 0 && INTVAL (operands[2]) < 5)
+return \"RRAM.W\t%2, %0\";
+ else if (INTVAL (operands[2]) >= 5 && INTVAL (operands[2]) < 16)
+return \"RPT\t%2 { RRAX.W\t%0\";
return \"# nop arith right shift\";
"
)
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 2742e10bb6f..ee43703ea54 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,11 @@
+2019-10-24
[COMMITTED][MSP430] Remove unused msp430_hard_regno_nregs_*_padding functions
There exist implementations HARD_REGNO_NREGS_HAS_PADDING and
HARD_REGNO_NREGS_WITH_PADDING functions in the msp430 back end, but they have
never been tied to their respective target macros.
Defining the target macros so these functions are used has no effect on GCC
testresults or on code size. So it seems that subreg_get_info is handling
msp430 PSImode registers properly.
This patch removes these unused functions.
Successfully regtested for msp430-elf on trunk in the small and large memory
models.
Committed to trunk as obvious.
>From daf0305adc486dcdecf1d94efd564e0d9f187ecf Mon Sep 17 00:00:00 2001
From: jozefl
Date: Thu, 24 Oct 2019 13:36:52 +
Subject: [PATCH] MSP430: Remove unused msp430_hard_regno_nregs_*_padding
functions
2019-10-24 Jozef Lawrynowicz
* config/msp430/msp430.c (msp430_hard_regno_nregs_has_padding): Remove
and add comment.
(msp430_hard_regno_nregs_with_padding): Remove.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@277395 138bc75d-0d04-0410-961f-82ee72b054a4
---
gcc/ChangeLog | 6 ++
gcc/config/msp430/msp430.c | 25 +++--
2 files changed, 9 insertions(+), 22 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index eb0a2f9b510..7b433bf59a1 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,9 @@
+2019-10-24 Jozef Lawrynowicz
+
+ * config/msp430/msp430.c (msp430_hard_regno_nregs_has_padding): Remove
+ and add comment.
+ (msp430_hard_regno_nregs_with_padding): Remove.
+
2019-10-24 Jozef Lawrynowicz
* config/msp430/constraints.md: Allow post_inc for "Ya" constraint.
diff --git a/gcc/config/msp430/msp430.c b/gcc/config/msp430/msp430.c
index cd394333983..fe1fcc0db43 100644
--- a/gcc/config/msp430/msp430.c
+++ b/gcc/config/msp430/msp430.c
@@ -332,28 +332,9 @@ msp430_hard_regno_nregs (unsigned int, machine_mode mode)
/ UNITS_PER_WORD);
}
-/* Implements HARD_REGNO_NREGS_HAS_PADDING. */
-int
-msp430_hard_regno_nregs_has_padding (int regno ATTRIBUTE_UNUSED,
- machine_mode mode)
-{
- if (mode == PSImode && msp430x)
-return 1;
- return ((GET_MODE_SIZE (mode) + UNITS_PER_WORD - 1)
- / UNITS_PER_WORD);
-}
-
-/* Implements HARD_REGNO_NREGS_WITH_PADDING. */
-int
-msp430_hard_regno_nregs_with_padding (int regno ATTRIBUTE_UNUSED,
- machine_mode mode)
-{
- if (mode == PSImode)
-return 2;
- if (mode == CPSImode)
-return 4;
- return msp430_hard_regno_nregs (regno, mode);
-}
+/* subreg_get_info correctly handles PSImode registers, so defining
+ HARD_REGNO_NREGS_HAS_PADDING and HARD_REGNO_NREGS_WITH_PADDING
+ has no effect. */
#undef TARGET_HARD_REGNO_MODE_OK
#define TARGET_HARD_REGNO_MODE_OK msp430_hard_regno_mode_ok
--
2.17.1
[PATCH][MSP430] Add -mtiny-printf option to support reduced code size printf and puts
I added support for reduced code size printf and puts functions to Newlib for
MSP430 a while ago [1]. By removing support for reentrancy, streams and
buffering we can greatly reduce code size, which is always often a limitation
when using printf on microcontrollers.
This patch adds an interface to enable these reduced code size implementations
from GCC by using the -mtiny-printf option. The tiny printf and puts
implementations require GCC to be configured with
--enable-newlib-nano-formatted-io, so there are some modifications to configure
scripts to support the checking of that.
-mtiny-printf is merely an alias for passing "--wrap printf --wrap puts" to the
linker.
This will replace references to "printf" and "puts" in user
code with "__wrap_printf" and "__wrap_puts" respectively.
If there is no implementation of these __wrap* functions in user code,
these "tiny" printf and puts implementations will be linked into the
final executable.
The wrapping mechanism is supposed to be invisible to the user since even if
they are unaware of the "tiny" implementation, and implement their own
__wrap_printf and __wrap_puts, their own implementation will be automatically
chosen over the "tiny" printf and puts from the library.
Successfully regtested on trunk by comparing results with -mtiny-printf with a
set of testresults without the option.
The new test "gcc.target/msp430/tiny-printf.c" verifies the option behaves as
expected when GCC is configured with and without
--enable-newlib-nano-formatted-io.
Ok to apply?
[1]
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=commit;h=1e6c561d48f
>From 4d4e2b6bb92317b2b4db1d99c3f43a167a1e3288 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Thu, 24 Oct 2019 13:30:21 +0100
Subject: [PATCH] MSP430: Add -mtiny-printf option
gcc/ChangeLog:
2019-10-24 Jozef Lawrynowicz
* config.in: Regenerate.
* config/msp430/msp430.c (msp430_option_override): Emit an error if
-mtiny-printf is used without GCC being configured with
--enable-newlib-nano-formatted-io.
* config/msp430/msp430.h (LINK_SPEC): Pass
"--wrap puts --wrap printf" when -mtiny-printf is used.
* config/msp430/msp430.opt: Document -mtiny-printf.
* configure: Regenerate.
* configure.ac: Enable --enable-newlib-nano-formatted-io flag.
Define HAVE_NEWLIB_NANO_FORMATTED_IO if
--enable-newlib-nano-formatted-io is passed.
* doc/invoke.texi: Document -mtiny-printf.
gcc/testsuite/ChangeLog:
2019-10-24 Jozef Lawrynowicz
* gcc.target/msp430/tiny-printf.c: New test.
---
gcc/config.in | 7 ++
gcc/config/msp430/msp430.c| 6 +
gcc/config/msp430/msp430.h| 1 +
gcc/config/msp430/msp430.opt | 4 +++
gcc/configure | 25 +--
gcc/configure.ac | 16
gcc/doc/invoke.texi | 15 ++-
gcc/testsuite/gcc.target/msp430/tiny-printf.c | 3 +++
8 files changed, 74 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/msp430/tiny-printf.c
diff --git a/gcc/config.in b/gcc/config.in
index 9b54a4715db..7925d892cce 100644
--- a/gcc/config.in
+++ b/gcc/config.in
@@ -1675,6 +1675,13 @@
#endif
+/* Define if GCC has been configured with --enable-newlib-nano-formatted-io.
+ */
+#ifndef USED_FOR_TARGET
+#undef HAVE_NEWLIB_NANO_FORMATTED_IO
+#endif
+
+
/* Define to 1 if you have the `nl_langinfo' function. */
#ifndef USED_FOR_TARGET
#undef HAVE_NL_LANGINFO
diff --git a/gcc/config/msp430/msp430.c b/gcc/config/msp430/msp430.c
index 31029395c3d..dbbff4a6863 100644
--- a/gcc/config/msp430/msp430.c
+++ b/gcc/config/msp430/msp430.c
@@ -284,6 +284,12 @@ msp430_option_override (void)
possible to build newlib with -Os enabled. Until now... */
if (TARGET_OPT_SPACE && optimize < 3)
optimize_size = 1;
+
+#ifndef HAVE_NEWLIB_NANO_FORMATTED_IO
+ if (TARGET_TINY_PRINTF)
+error ("GCC must be configured with %<--enable-newlib-nano-formatted-io%> "
+ "to use %<-mtiny-printf%>");
+#endif
}
#undef TARGET_SCALAR_MODE_SUPPORTED_P
diff --git a/gcc/config/msp430/msp430.h b/gcc/config/msp430/msp430.h
index 73afe2e2d16..4a89f03a35e 100644
--- a/gcc/config/msp430/msp430.h
+++ b/gcc/config/msp430/msp430.h
@@ -75,6 +75,7 @@ extern bool msp430x;
"msp430_propagate_region_opt(%* %{muse-lower-region-prefix})} " \
"%{mdata-region=*:--data-region=%:" \
"msp430_propagate_region_opt(%* %{muse-lower-region-prefix})} " \
+ "%{mtiny-printf:--wrap puts --wrap printf} "
#define DRIVER_SELF_SPECS \
" %{!mlarge:%{mcode-region=*:%{mdata-region=*:%e-mcode-region and " \
diff --git a/gcc/config/msp430/msp430.opt b/gcc/config/msp430/msp430.opt
index 2db2906ca11..b451174c3
[PATCH][MSP430] Use 430 insns in the large memory model for more patterns
Where possible, it is always desirable to use 430 format instructions when
compiling for the 430X ISA and the large memory model. 430 instructions have
reduced code size and faster execution time.
This patch recognizes a couple of new patterns in which we can use 430 insns in
the large memory model.
Successfully regtested on trunk.
Ok to apply?
>From ba3a8eafeba08dc034e219f892f2784c16f94c40 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Thu, 24 Oct 2019 15:17:29 +0100
Subject: [PATCH] MSP430: Use 430 insns in the large memory model for more
patterns
gcc/ChangeLog:
2019-10-25 Jozef Lawrynowicz
* config/msp430/msp430.c (msp430_check_index_not_high_mem): New.
(msp430_check_plus_not_high_mem): New.
(msp430_op_not_in_high_mem): Use new functions to check if the operand
might be in low memory.
Indicate that a 16-bit absolute address is in lower memory.
gcc/testsuite/ChangeLog:
2019-10-25 Jozef Lawrynowicz
* gcc.target/msp430/mlarge-use-430-insn.c: New test.
---
gcc/config/msp430/msp430.c| 43 ---
.../gcc.target/msp430/mlarge-use-430-insn.c | 33 ++
2 files changed, 70 insertions(+), 6 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/msp430/mlarge-use-430-insn.c
diff --git a/gcc/config/msp430/msp430.c b/gcc/config/msp430/msp430.c
index fe1fcc0db43..a3d0d9cf64b 100644
--- a/gcc/config/msp430/msp430.c
+++ b/gcc/config/msp430/msp430.c
@@ -3232,10 +3232,37 @@ msp430_print_operand_addr (FILE * file, machine_mode /*mode*/, rtx addr)
msp430_print_operand_raw (file, addr);
}
+/* We can only allow signed 15-bit indexes i.e. +/-32K. */
+static bool
+msp430_check_index_not_high_mem (rtx op)
+{
+ if (CONST_INT_P (op)
+ && IN_RANGE (INTVAL (op), HOST_WIDE_INT_M1U << 15, (1 << 15) - 1))
+return true;
+ return false;
+}
+
+/* If this returns true, we don't need a 430X insn. */
+static bool
+msp430_check_plus_not_high_mem (rtx op)
+{
+ if (GET_CODE (op) != PLUS)
+return false;
+ rtx op0 = XEXP (op, 0);
+ rtx op1 = XEXP (op, 1);
+ if (SYMBOL_REF_P (op0)
+ && (SYMBOL_REF_FLAGS (op0) & SYMBOL_FLAG_LOW_MEM)
+ && msp430_check_index_not_high_mem (op1))
+return true;
+ return false;
+}
+
/* Determine whether an RTX is definitely not a MEM referencing an address in
the upper memory region. Returns true if we've decided the address will be
in the lower memory region, or the RTX is not a MEM. Returns false
- otherwise. */
+ otherwise.
+ The Ys constraint will catch (mem (plus (const/reg)) but we catch cases
+ involving a symbol_ref here. */
bool
msp430_op_not_in_high_mem (rtx op)
{
@@ -3251,11 +3278,15 @@ msp430_op_not_in_high_mem (rtx op)
memory. */
return true;
- /* Catch (mem (const (plus ((symbol_ref) (const_int) e.g. &addr+2. */
- if ((GET_CODE (op0) == CONST)
- && (GET_CODE (XEXP (op0, 0)) == PLUS)
- && (SYMBOL_REF_P (XEXP (XEXP (op0, 0), 0)))
- && (SYMBOL_REF_FLAGS (XEXP (XEXP (op0, 0), 0)) & SYMBOL_FLAG_LOW_MEM))
+ /* Check possibilites for (mem (plus)).
+ e.g. (mem (const (plus ((symbol_ref) (const_int) : &addr+2. */
+ if (msp430_check_plus_not_high_mem (op0)
+ || ((GET_CODE (op0) == CONST)
+ && msp430_check_plus_not_high_mem (XEXP (op0, 0
+return true;
+
+ /* An absolute 16-bit address is allowed. */
+ if ((CONST_INT_P (op0) && (IN_RANGE (INTVAL (op0), 0, (1 << 16) - 1
return true;
/* Return false when undecided. */
diff --git a/gcc/testsuite/gcc.target/msp430/mlarge-use-430-insn.c b/gcc/testsuite/gcc.target/msp430/mlarge-use-430-insn.c
new file mode 100644
index 000..efa598be685
--- /dev/null
+++ b/gcc/testsuite/gcc.target/msp430/mlarge-use-430-insn.c
@@ -0,0 +1,33 @@
+/* { dg-do compile } */
+/* { dg-skip-if "" { *-*-* } { "-mcpu=msp430" "-mcpu=430" "-msmall" } { "" } } */
+/* { dg-options "-mlarge -O1" } */
+/* { dg-final { check-function-bodies "**" "" } } */
+
+/* Test to verify cases where we can use a 430 insn even in the large memory
+ model. */
+
+int foo[2];
+
+/*
+** func: { target msp430_region_lower }
+** ...
+** MOV.W #-4088, &foo
+** MOV.W #-8531, &40960
+** MOVX.W #-16657, &106496
+** ...
+*/
+/*
+** func: { target msp430_region_not_lower }
+** ...
+** MOVX.W #-4088, &foo
+** MOV.W #-8531, &40960
+** MOVX.W #-16657, &106496
+** ...
+*/
+void
+func (void)
+{
+ foo[0] = 0xF008;
+ (*(int *)0xA000) = 0xDEAD;
+ (*(int *)0x1A000) = 0xBEEF;
+}
--
2.17.1
[COMMITTED][MSP430][TESTSUITE] Move devices-main.c test source file
In preparation for an upcoming patch, I've moved devices-main.c from gcc.target/msp430/devices-main.c to gcc.target/msp430/devices/devices-main.c and updated references to it in the test source files. Committed as obvious. >From c2c40bdeb6d8212bfe6435154e1f31882ce36478 Mon Sep 17 00:00:00 2001 From: jozefl Date: Thu, 31 Oct 2019 17:36:53 + Subject: [PATCH] 2019-10-31 Jozef Lawrynowicz * gcc.target/msp430/devices-main.c: Move to devices subdirectory. * gcc.target/msp430/devices/bad-devices-1.c: Update #include path to devices-main.c. * gcc.target/msp430/devices/bad-devices-2.c: Likewise. * gcc.target/msp430/devices/bad-devices-3.c: Likewise. * gcc.target/msp430/devices/bad-devices-4.c: Likewise. * gcc.target/msp430/devices/bad-devices-5.c: Likewise. * gcc.target/msp430/devices/bad-devices-6.c: Likewise. * gcc.target/msp430/devices/csv-device-order.c: Likewise. * gcc.target/msp430/devices/csv-msp430_00.c: Likewise. * gcc.target/msp430/devices/csv-msp430_01.c: Likewise. * gcc.target/msp430/devices/csv-msp430_02.c: Likewise. * gcc.target/msp430/devices/csv-msp430_04.c: Likewise. * gcc.target/msp430/devices/csv-msp430_08.c: Likewise. * gcc.target/msp430/devices/csv-msp430_10.c: Likewise. * gcc.target/msp430/devices/csv-msp430_11.c: Likewise. * gcc.target/msp430/devices/csv-msp430_12.c: Likewise. * gcc.target/msp430/devices/csv-msp430_14.c: Likewise. * gcc.target/msp430/devices/csv-msp430_18.c: Likewise. * gcc.target/msp430/devices/csv-msp430_20.c: Likewise. * gcc.target/msp430/devices/csv-msp430_21.c: Likewise. * gcc.target/msp430/devices/csv-msp430_22.c: Likewise. * gcc.target/msp430/devices/csv-msp430_24.c: Likewise. * gcc.target/msp430/devices/csv-msp430_28.c: Likewise. * gcc.target/msp430/devices/csv-msp430fr5969.c: Likewise. * gcc.target/msp430/devices/hard-cc430f5123.c: Likewise. * gcc.target/msp430/devices/hard-foo.c: Likewise. * gcc.target/msp430/devices/hard-msp430afe253.c: Likewise. * gcc.target/msp430/devices/hard-msp430cg4616.c: Likewise. * gcc.target/msp430/devices/hard-msp430f4783.c: Likewise. * gcc.target/msp430/devices/hard-rf430frl154h_rom.c: Likewise. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@277684 138bc75d-0d04-0410-961f-82ee72b054a4 --- gcc/testsuite/ChangeLog | 34 +++ .../gcc.target/msp430/devices/bad-devices-1.c | 2 +- .../gcc.target/msp430/devices/bad-devices-2.c | 2 +- .../gcc.target/msp430/devices/bad-devices-3.c | 2 +- .../gcc.target/msp430/devices/bad-devices-4.c | 2 +- .../gcc.target/msp430/devices/bad-devices-5.c | 2 +- .../gcc.target/msp430/devices/bad-devices-6.c | 2 +- .../msp430/devices/csv-device-order.c | 2 +- .../gcc.target/msp430/devices/csv-msp430_00.c | 2 +- .../gcc.target/msp430/devices/csv-msp430_01.c | 2 +- .../gcc.target/msp430/devices/csv-msp430_02.c | 2 +- .../gcc.target/msp430/devices/csv-msp430_04.c | 2 +- .../gcc.target/msp430/devices/csv-msp430_08.c | 2 +- .../gcc.target/msp430/devices/csv-msp430_10.c | 2 +- .../gcc.target/msp430/devices/csv-msp430_11.c | 2 +- .../gcc.target/msp430/devices/csv-msp430_12.c | 2 +- .../gcc.target/msp430/devices/csv-msp430_14.c | 2 +- .../gcc.target/msp430/devices/csv-msp430_18.c | 2 +- .../gcc.target/msp430/devices/csv-msp430_20.c | 2 +- .../gcc.target/msp430/devices/csv-msp430_21.c | 2 +- .../gcc.target/msp430/devices/csv-msp430_22.c | 2 +- .../gcc.target/msp430/devices/csv-msp430_24.c | 2 +- .../gcc.target/msp430/devices/csv-msp430_28.c | 2 +- .../msp430/devices/csv-msp430fr5969.c | 2 +- .../gcc.target/msp430/devices/devices-main.c | 6 .../msp430/devices/hard-cc430f5123.c | 2 +- .../gcc.target/msp430/devices/hard-foo.c | 2 +- .../msp430/devices/hard-msp430afe253.c| 2 +- .../msp430/devices/hard-msp430cg4616.c| 2 +- .../msp430/devices/hard-msp430f4783.c | 2 +- .../msp430/devices/hard-rf430frl154h_rom.c| 2 +- 31 files changed, 69 insertions(+), 29 deletions(-) create mode 100644 gcc/testsuite/gcc.target/msp430/devices/devices-main.c diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog index 1830b4d691f..79936089d20 100644 --- a/gcc/testsuite/ChangeLog +++ b/gcc/testsuite/ChangeLog @@ -1,3 +1,37 @@ +2019-10-31 Jozef Lawrynowicz + + * gcc.target/msp430/devices-main.c: Move to devices subdirectory. + * gcc.target/msp430/devices/bad-devices-1.c: Update #include path to + devices-main.c. + * gcc.target/msp430/devices/bad-devices-2.c: Likewise. + * gcc.target/msp430/devices/bad-devices-3.c: Likewise. + * gcc.target/msp430/devices/bad-devices-4.c: Likewise. + * gcc.target/msp430/devices/bad-devices-5.c: Likewise. + * gcc.target/msp430/devices/bad-devices-6.c: Likewise. + * gcc.target/msp430/devices/csv-device-order.c: Likewise. + * gcc.target/msp430/devices/csv-msp430_00.c: Likewise. + * gcc.target/msp430/devices/csv-msp430_01.c: Likewise. + * gcc.target/msp430/devices/csv-msp430_02.c: Likewise. + * gc
[PATCH][MSP430] Read MCU data from external file specified with environment variable or installed into toolchain subdirectory
Each different MSP430 MCU has two properties that affect code generation, which
are the the CPU ISA and the hardware multiply support. These can be manually
specified with the -mcpu= and -mhwmult= options, respectively.
The existing -mmcu= option takes an MCU name as an argument and uses the CPU
ISA and hardware multiply known to be supported for that MCU, so the user does
not have to provide the -mcpu and -mhwmult options.
Currently, the MCU data can be provided in an external "devices.csv" file, and
this file is already searched for on the paths specified with -I and -L.
This patch extends the searching behaviour so the path to the directory
containing devices.csv can either be specified with the "MSP430_GCC_INCLUDE_DIR"
environment variable, or installed into the msp430-elf/include/devices
subdirectory of the toolchain.
The msp430.exp toolchain driver has been extended to ensure these new methods
can be tested properly.
Successfully regtested on trunk.
Ok to apply?
>From f781013148c2fd242af8526dbcfa2079fe30db07 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Wed, 30 Oct 2019 21:10:38 +
Subject: [PATCH] MSP430: Read MCU data from external file specified with
environment variable or installed into toolchain subdirectory
gcc/ChangeLog:
2019-10-31 Jozef Lawrynowicz
* config/msp430/driver-msp430.c (msp430_get_linker_devices_include_path):
New spec function.
* config/msp430/msp430-devices.c (msp430_dirname): New function.
(extract_devices_dir_from_exec_prefix): New function.
(extract_devices_dir_from_collect_gcc): New function.
(msp430_check_env_var_for_devices): New function.
(msp430_check_path_for_devices): Use xstrdup instead of ASTRDUP.
(parse_devices_csv): Call msp430_check_env_var_for_devices if
devices.csv was not found using other methods.
* config/msp430/msp430-devices.h (msp430_check_env_var_for_devices):
New prototype.
(msp430_dirname): Likewise.
* config/msp430/msp430.c (msp430_register_pre_includes): New function.
* config/msp430/msp430.h (EXTRA_SPEC_FUNCTIONS): Add
msp430_get_linker_devices_include_path.
(TARGET_EXTRA_PRE_INCLUDES): Define.
* doc/invoke.texi: Document new ways of searching for support files.
gcc/testsuite/ChangeLog:
2019-10-31 Jozef Lawrynowicz
* gcc.target/msp430/devices/csv-using-env-var.c: New test.
* gcc.target/msp430/devices/csv-using-installed.c: New test.
* gcc.target/msp430/devices/csv-using-option.c: New test.
* gcc.target/msp430/devices/devices-main.c: New test source file.
* gcc.target/msp430/devices/msp430-devices.h: New test.
* gcc.target/msp430/msp430.exp (msp430_device_permutations_runtest):
Add special cases for csv-using* tests.
Define TESTING_HARD_DATA when running tests that use hard-coded device
data.
(get_installed_device_data_path): New.
(msp430_hide_installed_devices_data): New.
(msp430_restore_installed_devices_data): New.
(msp430_test_installed_device_data): New.
(msp430_install_device_data): New.
---
gcc/config/msp430/driver-msp430.c | 13 ++
gcc/config/msp430/msp430-devices.c| 133 +-
gcc/config/msp430/msp430-devices.h| 2 +
gcc/config/msp430/msp430.c| 23 +++
gcc/config/msp430/msp430.h| 12 +-
gcc/doc/invoke.texi | 29 +++-
.../msp430/devices/csv-using-env-var.c| 10 ++
.../msp430/devices/csv-using-installed.c | 9 ++
.../msp430/devices/csv-using-option.c | 9 ++
.../gcc.target/msp430/devices/devices-main.c | 4 +
.../msp430/devices/msp430-devices.h | 3 +
gcc/testsuite/gcc.target/msp430/msp430.exp| 94 -
12 files changed, 332 insertions(+), 9 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/msp430/devices/csv-using-env-var.c
create mode 100644 gcc/testsuite/gcc.target/msp430/devices/csv-using-installed.c
create mode 100644 gcc/testsuite/gcc.target/msp430/devices/csv-using-option.c
create mode 100644 gcc/testsuite/gcc.target/msp430/devices/msp430-devices.h
diff --git a/gcc/config/msp430/driver-msp430.c b/gcc/config/msp430/driver-msp430.c
index c37b169ff8b..fbe7c44ea37 100644
--- a/gcc/config/msp430/driver-msp430.c
+++ b/gcc/config/msp430/driver-msp430.c
@@ -150,6 +150,19 @@ msp430_select_hwmult_lib (int argc ATTRIBUTE_UNUSED,
return "-lmul_none";
}
+/* Spec function. Used to place the path to the MSP430-GCC support files
+ on the command line, prefixed with "-L", so the linker finds the linker
+ scripts in that directory. */
+const char *
+msp430_get_linker_devices_include_path (int argc ATTRIBUTE_UNUSED,
+ const char **argv ATTRIBUTE_UNUSED)
+{
+ char *devices_csv_path;
+ if (msp430_check_env_var_for_devices (&devices_csv_path))
+return NULL;
+ return concat ("-L", msp430_dirname (devices_csv_path), NULL);
+}
+
/* Spec function. Propagate -m{code,data}-region= to the linker, unless the
lower region has been specif
[COMMITTED] Regenerate gcc/configure
r277753 regenerated gcc/configure but the version of autoconf used for the
regeneration added lines to support "runstatedir".
The attached patch is the result of regenerating configure with the correct
version/configuration of autoconf.
>From 04f59c00115d9e2517c15755f9058832703cb494 Mon Sep 17 00:00:00 2001
From: jozefl
Date: Mon, 4 Nov 2019 11:18:24 +
Subject: [PATCH] Regenerate gcc/configure
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@23 138bc75d-0d04-0410-961f-82ee72b054a4
---
gcc/ChangeLog | 4
gcc/configure | 28
2 files changed, 12 insertions(+), 20 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index c1c6d335d04..6f0bd8381a0 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,7 @@
+2019-11-04 Jozef Lawrynowicz
+
+ * configure: Regenerate.
+
2019-11-04 Jozef Lawrynowicz
* config/msp430/driver-msp430.c
diff --git a/gcc/configure b/gcc/configure
index 023d51d78fe..fd33bc661a8 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -903,7 +903,6 @@ infodir
docdir
oldincludedir
includedir
-runstatedir
localstatedir
sharedstatedir
sysconfdir
@@ -1068,7 +1067,6 @@ datadir='${datarootdir}'
sysconfdir='${prefix}/etc'
sharedstatedir='${prefix}/com'
localstatedir='${prefix}/var'
-runstatedir='${localstatedir}/run'
includedir='${prefix}/include'
oldincludedir='/usr/include'
docdir='${datarootdir}/doc/${PACKAGE}'
@@ -1321,15 +1319,6 @@ do
| -silent | --silent | --silen | --sile | --sil)
silent=yes ;;
- -runstatedir | --runstatedir | --runstatedi | --runstated \
- | --runstate | --runstat | --runsta | --runst | --runs \
- | --run | --ru | --r)
-ac_prev=runstatedir ;;
- -runstatedir=* | --runstatedir=* | --runstatedi=* | --runstated=* \
- | --runstate=* | --runstat=* | --runsta=* | --runst=* | --runs=* \
- | --run=* | --ru=* | --r=*)
-runstatedir=$ac_optarg ;;
-
-sbindir | --sbindir | --sbindi | --sbind | --sbin | --sbi | --sb)
ac_prev=sbindir ;;
-sbindir=* | --sbindir=* | --sbindi=* | --sbind=* | --sbin=* \
@@ -1467,7 +1456,7 @@ fi
for ac_var in exec_prefix prefix bindir sbindir libexecdir datarootdir \
datadir sysconfdir sharedstatedir localstatedir includedir \
oldincludedir docdir infodir htmldir dvidir pdfdir psdir \
- libdir localedir mandir runstatedir
+ libdir localedir mandir
do
eval ac_val=\$$ac_var
# Remove trailing slashes.
@@ -1620,7 +1609,6 @@ Fine tuning of the installation directories:
--sysconfdir=DIRread-only single-machine data [PREFIX/etc]
--sharedstatedir=DIRmodifiable architecture-independent data [PREFIX/com]
--localstatedir=DIR modifiable single-machine data [PREFIX/var]
- --runstatedir=DIR modifiable per-process data [LOCALSTATEDIR/run]
--libdir=DIRobject code libraries [EPREFIX/lib]
--includedir=DIRC header files [PREFIX/include]
--oldincludedir=DIR C header files for non-gcc [/usr/include]
@@ -5905,7 +5893,7 @@ else
We can't simply define LARGE_OFF_T to be 9223372036854775807,
since some C++ compilers masquerading as C compilers
incorrectly reject 9223372036854775807. */
-#define LARGE_OFF_T off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31))
+#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721
&& LARGE_OFF_T % 2147483647 == 1)
? 1 : -1];
@@ -5951,7 +5939,7 @@ else
We can't simply define LARGE_OFF_T to be 9223372036854775807,
since some C++ compilers masquerading as C compilers
incorrectly reject 9223372036854775807. */
-#define LARGE_OFF_T off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31))
+#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721
&& LARGE_OFF_T % 2147483647 == 1)
? 1 : -1];
@@ -5975,7 +5963,7 @@ rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
We can't simply define LARGE_OFF_T to be 9223372036854775807,
since some C++ compilers masquerading as C compilers
incorrectly reject 9223372036854775807. */
-#define LARGE_OFF_T off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31))
+#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721
&& LARGE_OFF_T % 2147483647 == 1)
? 1 : -1];
@@ -6020,7 +6008,7 @@ else
We can't simply define LARGE_OFF_T to be 9223372036854775807,
since some C++ compilers masquerading as C compilers
incorrectly reject 9223372036854775807. */
-#define LARGE_OFF_T off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31))
+#define LARGE_OFF_T (((o
[COMMITTED] Fix incorrect use of USE_TM_CLONE_REGISTRY in crtstuff.c
r272769 added the --disable-tm-clone-registry configure option. This expects
defining USE_TM_CLONE_REGISTRY to 0 to remove blocks of code from
libgcc/crtstuff.c.
However, some #if blocks in crtstuff.c only check whether USE_TM_CLONE_REGISTRY
is defined, so when it is defined to 0, these will still be true.
The attached patch changes the remaining instances of "#if
defined(USE_TM_CLONE_REGISTRY)" to merely check "#if USE_TM_CLONE_REGISTRY".
A new clause at the top of the file ensures the macro is always defined to a
value.
Successfully bootstrapped and regtested for x86-64-pc-linux-gnu.
Successfully regtested for msp430-elf.
Committed as obvious.
>From 47a6db26ddbedccf6a9270718421e54a681868ee Mon Sep 17 00:00:00 2001
From: jozefl
Date: Mon, 4 Nov 2019 12:41:56 +
Subject: [PATCH] libgcc: Fix incorrect use of USE_TM_CLONE_REGISTRY
2019-11-04 Jozef Lawrynowicz
* crtstuff.c: Define USE_TM_CLONE_REGISTRY to 0 if it's undefined and
the target output object format is not ELF.
s/defined(USE_TM_CLONE_REGISTRY)/USE_TM_CLONE_REGISTRY.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@25 138bc75d-0d04-0410-961f-82ee72b054a4
---
libgcc/ChangeLog | 6 ++
libgcc/crtstuff.c | 11 +--
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/libgcc/ChangeLog b/libgcc/ChangeLog
index 806d048f5d1..c528cec2db3 100644
--- a/libgcc/ChangeLog
+++ b/libgcc/ChangeLog
@@ -1,3 +1,9 @@
+2019-11-04 Jozef Lawrynowicz
+
+ * crtstuff.c: Define USE_TM_CLONE_REGISTRY to 0 if it's undefined and
+ the target output object format is not ELF.
+ s/defined(USE_TM_CLONE_REGISTRY)/USE_TM_CLONE_REGISTRY.
+
2019-11-03 Oleg Endo
PR libgcc/78804
diff --git a/libgcc/crtstuff.c b/libgcc/crtstuff.c
index c93e1cbcaca..ae6328d317d 100644
--- a/libgcc/crtstuff.c
+++ b/libgcc/crtstuff.c
@@ -153,6 +153,8 @@ call_ ## FUNC (void) \
#if !defined(USE_TM_CLONE_REGISTRY) && defined(OBJECT_FORMAT_ELF)
# define USE_TM_CLONE_REGISTRY 1
+#elif !defined(USE_TM_CLONE_REGISTRY)
+# define USE_TM_CLONE_REGISTRY 0
#endif
/* We do not want to add the weak attribute to the declarations of these
@@ -450,8 +452,7 @@ CRT_CALL_STATIC_FUNCTION (__LIBGCC_INIT_SECTION_ASM_OP__,
__do_global_dtors_aux_1)
#endif
-#if defined(USE_EH_FRAME_REGISTRY) \
-|| defined(USE_TM_CLONE_REGISTRY)
+#if defined(USE_EH_FRAME_REGISTRY) || USE_TM_CLONE_REGISTRY
/* Stick a call to __register_frame_info into the .init section. For some
reason calls with no arguments work more reliably in .init, so stick the
call in another function. */
@@ -560,8 +561,7 @@ __do_global_dtors (void)
#endif
}
-#if defined(USE_EH_FRAME_REGISTRY) \
-|| defined(USE_TM_CLONE_REGISTRY)
+#if defined(USE_EH_FRAME_REGISTRY) || USE_TM_CLONE_REGISTRY
/* A helper function for __do_global_ctors, which is in crtend.o. Here
in crtbegin.o, we can reference a couple of symbols not visible there.
Plus, since we're before libgcc.a, we have no problems referencing
@@ -733,8 +733,7 @@ void
__do_global_ctors (void)
{
func_ptr *p;
-#if defined(USE_EH_FRAME_REGISTRY) \
-|| defined(USE_TM_CLONE_REGISTRY)
+#if defined(USE_EH_FRAME_REGISTRY) || USE_TM_CLONE_REGISTRY
__do_global_ctors_1();
#endif
for (p = __CTOR_END__ - 1; *p != (func_ptr) -1; p--)
--
2.17.1
[PATCH 0/3] libgcc/crtstuff.c tweaks to reduce code size
Some functionality in crtstuff.c will never be used for some targets,
resulting in unnecessary code bloat in the crt* object files.
For example, msp430-elf uses .{init,fini}_array, does not support shared
objects, does not support transactional memory and could be configured
to remove support for exceptions.
Therefore __do_global_dtors_aux(), frame_dummy(),
{,de}register_tm_clones could be safely removed, saving code size.
The following patches implement the generic mechanisms which enable the features
associated with the this functionality to be removed.
Successfully bootstrapped and regtested for x86_64-pc-linx-gnu.
Successfully regtested for msp430-elf.
Ok to apply?
P.S. An MSP430-specific series of patches to make use of the functionality added
here will be submitted separately.
Jozef Lawrynowicz (3):
libgcc: Add --disable-eh-frame-registry configure option
libgcc: Dont define __do_global_dtors_aux if it will be empty
libgcc: Implement TARGET_LIBGCC_REMOVE_DSO_HANDLE
gcc/doc/install.texi | 11 +++
gcc/doc/tm.texi | 11 +++
gcc/doc/tm.texi.in | 11 +++
libgcc/Makefile.in | 4 +++-
libgcc/configure | 22 ++
libgcc/configure.ac | 17 +
libgcc/crtstuff.c| 33 +++--
7 files changed, 98 insertions(+), 11 deletions(-)
--
2.17.1
[PATCH 1/3] libgcc: Add --disable-eh-frame-registry configure option
The attached patch enables the EH Frame Registry to be explicitly disabled
with a configure option "-disable-eh-frame-registry", thereby removing code to
support it in crtstuff.c
Default behaviour is unchanged since USE_EH_FRAME_REGISTRY was previously
referenced only internally in crtstuff.c, and now is only defined to 0
when it would previously have not been defined at all.
>From 31fdea3564fd0a9a25547df0d5052133d7bdc8a6 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Tue, 29 Oct 2019 12:55:11 +
Subject: [PATCH 1/3] libgcc: Add --disable-eh-frame-registry configure option
gcc/ChangeLog:
2019-11-06 Jozef Lawrynowicz
* doc/install.texi: Document --disable-eh-frame-registry.
libgcc/ChangeLog:
2019-11-06 Jozef Lawrynowicz
* Makefile.in: Add USE_EH_FRAME_REGISTRY variable.
Use USE_EH_FRAME_REGISTRY variable in CRTSTUFF_CFLAGS.
* configure: Regenerate.
* configure.ac: Support --disable-eh-frame-registry.
* crtstuff.c [!USE_EH_FRAME_REGISTRY]: Define USE_EH_FRAME_REGISTRY.
s/#ifdef USE_EH_FRAME_REGISTRY/#if USE_EH_FRAME_REGISTRY/.
s/#if defined(USE_EH_FRAME_REGISTRY)/#if USE_EH_FRAME_REGISTRY/.
---
gcc/doc/install.texi | 11 +++
libgcc/Makefile.in | 4 +++-
libgcc/configure | 22 ++
libgcc/configure.ac | 17 +
libgcc/crtstuff.c| 22 +-
5 files changed, 66 insertions(+), 10 deletions(-)
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 563de705881..af61a34a477 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -1314,6 +1314,17 @@ Disable TM clone registry in libgcc. It is enabled in libgcc by default.
This option helps to reduce code size for embedded targets which do
not use transactional memory.
+@item --disable-eh-frame-registry
+Disable the EH frame registry in libgcc. It is enabled in libgcc by default
+for most ELF targets.
+
+This should not be used unless exceptions have been disabled for the target
+configuration.
+
+This option reduces code size by removing functionality to register the
+exception handling frame information that would normally run before
+@samp{main()}.
+
@item --with-cpu=@var{cpu}
@itemx --with-cpu-32=@var{cpu}
@itemx --with-cpu-64=@var{cpu}
diff --git a/libgcc/Makefile.in b/libgcc/Makefile.in
index 5608352a900..59f7f3cc381 100644
--- a/libgcc/Makefile.in
+++ b/libgcc/Makefile.in
@@ -261,6 +261,8 @@ CET_FLAGS = @CET_FLAGS@
USE_TM_CLONE_REGISTRY = @use_tm_clone_registry@
+USE_EH_FRAME_REGISTRY = @use_eh_frame_registry@
+
# Defined in libgcc2.c, included only in the static library.
LIB2FUNCS_ST = _eprintf __gcc_bcmp
@@ -301,7 +303,7 @@ CRTSTUFF_CFLAGS = -O2 $(GCC_CFLAGS) $(INCLUDES) $(MULTILIB_CFLAGS) -g0 \
$(NO_PIE_CFLAGS) -finhibit-size-directive -fno-inline -fno-exceptions \
-fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-tree-vectorize \
-fbuilding-libgcc -fno-stack-protector $(FORCE_EXPLICIT_EH_REGISTRY) \
- $(INHIBIT_LIBC_CFLAGS) $(USE_TM_CLONE_REGISTRY)
+ $(INHIBIT_LIBC_CFLAGS) $(USE_TM_CLONE_REGISTRY) $(USE_EH_FRAME_REGSITRY)
# Extra flags to use when compiling crt{begin,end}.o.
CRTSTUFF_T_CFLAGS =
diff --git a/libgcc/configure b/libgcc/configure
index 117e9c97e57..341c609252e 100755
--- a/libgcc/configure
+++ b/libgcc/configure
@@ -605,6 +605,7 @@ solaris_ld_v2_maps
real_host_noncanonical
accel_dir_suffix
use_tm_clone_registry
+use_eh_frame_registry
force_explicit_eh_registry
CET_FLAGS
fixed_point
@@ -713,6 +714,7 @@ enable_decimal_float
with_system_libunwind
enable_cet
enable_explicit_exception_frame_registration
+enable_eh_frame_registry
enable_tm_clone_registry
with_glibc_version
enable_tls
@@ -1357,6 +1359,7 @@ Optional Features:
register exception tables explicitly at module
start, for use e.g. for compatibility with
installations without PT_GNU_EH_FRAME support
+ --disable-eh-frame-registrydisable EH frame registry
--disable-tm-clone-registrydisable TM clone registry
--enable-tlsUse thread-local storage [default=yes]
@@ -4956,6 +4959,25 @@ fi
+# EH Frame Registry is implicitly enabled by default (although it is not
+# "forced"), and libgcc/crtstuff.c will setup the support for it if it is
+# supported by the target. So we don't handle --enable-eh-frame-registry.
+# Check whether --enable-eh-frame-registry was given.
+if test "${enable_eh_frame_registry+set}" = set; then :
+ enableval=$enable_eh_frame_registry;
+use_eh_frame_registry=
+if test "$enable_eh_frame_registry" = no; then
+ if test "$enable_explicit_exception_frame_registration" = yes; then
+as_fn_error $? "Can't --disable-eh-frame-registry with
+ with --enable-explicit-exception-frame-registration" "$LINENO" 5
+ fi
+ use_eh_frame_registry=-DUSE_EH_FRAME_REGISTRY=0
+fi
+
+fi
+
+
+
# Check whether --enable-
[PATCH 2/3] libgcc: Dont define __do_global_dtors_aux if it will be empty
__do_global_dtors_aux in crtstuff.c will not do anything meaningful if:
* crtstuff.c is not being compiled for use in a shared library
* the target uses .{init,fini}_array sections
* TM clone registry is disabled
* EH frame registry is disabled
The attached patch prevents it from being defined at all if all the above
conditions are true. This saves code size in the final linked executable.
>From 967262117f0c838fe8a9226484bf6e014c86f0ba Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Tue, 29 Oct 2019 13:02:08 +
Subject: [PATCH 2/3] libgcc: Dont define __do_global_dtors_aux if it will be
empty
libgcc/ChangeLog:
2019-11-06 Jozef Lawrynowicz
* crtstuff.c (__do_global_dtors_aux): Wrap in #if so it's only defined
if it will have contents.
---
libgcc/crtstuff.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/libgcc/crtstuff.c b/libgcc/crtstuff.c
index 9a3247b7848..0b0a0b865fe 100644
--- a/libgcc/crtstuff.c
+++ b/libgcc/crtstuff.c
@@ -368,8 +368,12 @@ extern void __cxa_finalize (void *) TARGET_ATTRIBUTE_WEAK;
On some systems, this routine is run more than once from the .fini,
when exit is called recursively, so we arrange to remember where in
the list we left off processing, and we resume at that point,
- should we be re-invoked. */
+ should we be re-invoked.
+ This routine does not need to be run if none of the following clauses are
+ true, as it will not do anything, so can be removed. */
+#if defined(CRTSTUFFS_O) || !defined(FINI_ARRAY_SECTION_ASM_OP) \
+ || USE_TM_CLONE_REGISTRY || USE_EH_FRAME_REGISTRY
static void __attribute__((used))
__do_global_dtors_aux (void)
{
@@ -455,6 +459,9 @@ __do_global_dtors_aux_1 (void)
CRT_CALL_STATIC_FUNCTION (__LIBGCC_INIT_SECTION_ASM_OP__,
__do_global_dtors_aux_1)
#endif
+#endif /* defined(CRTSTUFFS_O) || !defined(FINI_ARRAY_SECTION_ASM_OP)
+ || defined(USE_TM_CLONE_REGISTRY) || defined(USE_EH_FRAME_REGISTRY) */
+
#if USE_EH_FRAME_REGISTRY || USE_TM_CLONE_REGISTRY
/* Stick a call to __register_frame_info into the .init section. For some
--
2.17.1
[PATCH 3/3] libgcc: Implement TARGET_LIBGCC_REMOVE_DSO_HANDLE
For some targets __dso_handle will never be used, and its definition in
crtstuff.c can cause a domino effect resulting in the size of the final
executable increasing much more than just the size of this piece of data.
For msp430, CRT functions to initialize global data are only included if there
is global data to initialize and it is more than feasible to write functional
programs which do not use any global data. In these cases, the definition of
__dso_handle will cause code size to increase by around 100 bytes as library
code to initialize data is linked into the executable.
Removing __dso_handle can therefore save on code size.
This does require the target to NOT use __cxa_atexit, so either
TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT must return true or -fno-use-cxa-atexit
must be used as a target flag when building GCC.
This is because __cxa_atexit includes functionality to unload dynamic shared
objects and so cp/decl.c will create a reference to __dso_handle to facilitate
this in programs with static destructors.
>From 7bc0971d2936ebe71e7b7d3d805cf1bbf9f9f5af Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Mon, 4 Nov 2019 17:38:13 +
Subject: [PATCH 3/3] libgcc: Implement TARGET_LIBGCC_REMOVE_DSO_HANDLE
gcc/ChangeLog:
2019-11-06 Jozef Lawrynowicz
* doc/tm.texi: Regenerate.
* doc/tm.texi.in: Define TARGET_LIBGCC_REMOVE_DSO_HANDLE.
libgcc/ChangeLog:
2019-11-06 Jozef Lawrynowicz
* crtstuff.c: Don't declare __dso_handle if
TARGET_LIBGCC_REMOVE_DSO_HANDLE is defined.
---
gcc/doc/tm.texi| 11 +++
gcc/doc/tm.texi.in | 11 +++
libgcc/crtstuff.c | 2 ++
3 files changed, 24 insertions(+)
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index cd9aed9874f..89ef0a8e616 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -11425,6 +11425,17 @@ from shared libraries (DLLs).
You need not define this macro if it would always evaluate to zero.
@end defmac
+@defmac TARGET_LIBGCC_REMOVE_DSO_HANDLE
+Define this macro if, for targets where dynamic shared objects cannot be used,
+the declaration of @samp{__dso_handle} in libgcc/crtstuff.c can be removed.
+
+If this macro is defined, __cxa_atexit must be disabled at GCC configure time,
+otherwise references to __dso_handle will be created when the middle-end
+creates destructors for static objects.
+
+This macro is undefined by default.
+@end defmac
+
@deftypefn {Target Hook} {rtx_insn *} TARGET_MD_ASM_ADJUST (vec& @var{outputs}, vec& @var{inputs}, vec& @var{constraints}, vec& @var{clobbers}, HARD_REG_SET& @var{clobbered_regs})
This target hook may add @dfn{clobbers} to @var{clobbers} and
@var{clobbered_regs} for any hard regs the port wishes to automatically
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index 2739e9ceec5..3a211a7658a 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -7853,6 +7853,17 @@ from shared libraries (DLLs).
You need not define this macro if it would always evaluate to zero.
@end defmac
+@defmac TARGET_LIBGCC_REMOVE_DSO_HANDLE
+Define this macro if, for targets where dynamic shared objects cannot be used,
+the declaration of @samp{__dso_handle} in libgcc/crtstuff.c can be removed.
+
+If this macro is defined, __cxa_atexit must be disabled at GCC configure time,
+otherwise references to __dso_handle will be created when the middle-end
+creates destructors for static objects.
+
+This macro is undefined by default.
+@end defmac
+
@hook TARGET_MD_ASM_ADJUST
@defmac MATH_LIBRARY
diff --git a/libgcc/crtstuff.c b/libgcc/crtstuff.c
index 0b0a0b865fe..d1d17f959d3 100644
--- a/libgcc/crtstuff.c
+++ b/libgcc/crtstuff.c
@@ -335,6 +335,7 @@ register_tm_clones (void)
in one DSO or the main program is not used in another object. The
dynamic linker takes care of this. */
+#ifndef TARGET_LIBGCC_REMOVE_DSO_HANDLE
#ifdef TARGET_LIBGCC_SDATA_SECTION
extern void *__dso_handle __attribute__ ((__section__ (TARGET_LIBGCC_SDATA_SECTION)));
#endif
@@ -346,6 +347,7 @@ void *__dso_handle = &__dso_handle;
#else
void *__dso_handle = 0;
#endif
+#endif /* TARGET_LIBGCC_REMOVE_DSO_HANDLE */
/* The __cxa_finalize function may not be available so we use only a
weak declaration. */
--
2.17.1
Re: [PATCH 1/3] libgcc: Add --disable-eh-frame-registry configure option
On Wed, 6 Nov 2019 16:16:27 + Jozef Lawrynowicz wrote: > The attached patch enables the EH Frame Registry to be explicitly disabled > with a configure option "-disable-eh-frame-registry", thereby removing code to > support it in crtstuff.c > > Default behaviour is unchanged since USE_EH_FRAME_REGISTRY was previously > referenced only internally in crtstuff.c, and now is only defined to 0 > when it would previously have not been defined at all. I retract this patch, since I have found a better solution to the problem this was going to solve. Passing "-U__LIBGCC_EH_FRAME_SECTION_NAME__" when building crtstuff.c objects completely removes references to .eh_frame. The original patch still resulted in the .eh_frame section being created, since code to add a 4byte NULL sentinel to the end of the section was retained. If someone thinks the original patch might still be useful, I can go ahead and commit it anyway.
[PATCH 0/4][MSP430] Tweaks to default configuration to reduce code size
When building small programs for MSP430, the impact of the unused functions pulled in from the CRT libraries is quite noticeable. Most of these relates to feature that will never be used for MSP430 (Transactional memory, supporting shared objects and dynamic linking), or rarely used (exception handling). The following patches change the default configuration for msp430-elf with the aim of reducing code size by removing these unsupported features. Related generic changes to GCC have been submitted here: https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00415.html (But note that the first patch to disable eh frame registry has been retracted as it's no longer necessary). I picked random C and C++ programs from the testsuite to give an indication of the size reduction: $ msp430-elf-gcc testsuite/gcc.dg/2108-1.c -Os -msim -ffunction-sections \ -fdata-sections -Wl,-gc-sections Before: textdata bss dec hex filename 708 242 28 978 3d2 2108-1.exe After: textdata bss dec hex filename 444 234 2 680 2a8 2108-1.exe $ msp430-elf-g++ -msim -Os testsuite/g++.dg/abi/covariant5.C \ -ffunction-sections -fdata-sections -Wl,-gc-sections Before: textdata bss dec hex filename 4090 396 1845041198 covariant5.exe Before (-fno-exceptions): textdata bss dec hex filename 3912 396 18432610e6 a.out After: textdata bss dec hex filename 3396 122 23520 dc0 covariant5.exe The writeup for the -minrt patch has some more code size comparisons related to that option. Successfully regtested for msp430-elf. Ok to apply? Jozef Lawrynowicz (4): MSP430: Disable TM clone registry by default MSP430: Disable exception handling by default for C++ MSP430: Disable __cxa_atexit MSP430: Remove -minrt option config-ml.in | 13 + gcc/config.gcc| 7 + gcc/config/msp430/msp430.c| 9 +++ gcc/config/msp430/msp430.h| 20 +++--- gcc/config/msp430/msp430.opt | 4 +-- gcc/config/msp430/t-msp430| 9 --- gcc/doc/install.texi | 3 +++ gcc/doc/invoke.texi | 15 --- gcc/testsuite/g++.dg/cpp1y/sized-dealloc2.C | 2 +- gcc/testsuite/g++.dg/cpp2a/explicit1.C| 2 +- gcc/testsuite/g++.dg/cpp2a/explicit2.C| 2 +- gcc/testsuite/g++.dg/cpp2a/explicit5.C| 2 +- gcc/testsuite/g++.dg/dg.exp | 9 ++- gcc/testsuite/g++.dg/eh/array1.C | 2 +- gcc/testsuite/g++.dg/eh/spec11.C | 2 +- gcc/testsuite/g++.dg/eh/spec6.C | 2 +- gcc/testsuite/g++.dg/ext/vla4.C | 2 +- gcc/testsuite/g++.dg/init/dso_handle1.C | 1 + gcc/testsuite/g++.dg/init/dso_handle2.C | 1 + gcc/testsuite/g++.dg/ipa/pr64612.C| 2 +- gcc/testsuite/g++.dg/other/cxa-atexit1.C | 1 + gcc/testsuite/g++.dg/other/error32.C | 2 +- gcc/testsuite/g++.dg/torture/dg-torture.exp | 9 ++- gcc/testsuite/g++.dg/torture/pr34850.C| 2 +- gcc/testsuite/g++.dg/tree-ssa/ivopts-3.C | 2 +- gcc/testsuite/g++.dg/tree-ssa/pr33615.C | 2 +- gcc/testsuite/g++.dg/warn/Wcatch-value-1.C| 2 +- gcc/testsuite/g++.dg/warn/Wcatch-value-2.C| 2 +- gcc/testsuite/g++.dg/warn/Wcatch-value-3.C| 2 +- .../g++.dg/warn/Wstringop-truncation-2.C | 2 +- gcc/testsuite/g++.dg/warn/Wterminate1.C | 2 +- gcc/testsuite/g++.dg/warn/pr83054.C | 2 +- gcc/testsuite/g++.old-deja/g++.other/cond5.C | 2 +- gcc/testsuite/g++.old-deja/old-deja.exp | 9 ++- gcc/testsuite/lib/gcc-dg.exp | 10 +++ gcc/testsuite/lib/target-supports.exp | 27 --- libgcc/config.host| 3 ++- libgcc/config/msp430/t-msp430 | 6 + libgcc/configure | 9 +++ libgcc/configure.ac | 8 ++ 40 files changed, 166 insertions(+), 47 deletions(-) -- 2.17.1
[PATCH 1/4] MSP430: Disable TM clone registry by default
Given that MSP430 is a resource constrained, embedded target disabling transactional memory by default is a good idea to save on code size in the runtime library. It can still be enabled by passing --enable-tm-clone-registry (although as far as I understand the feature is fundamentally incompatible with MSP430 given reliance on libitm, lack of thread support without an OS and the memory limitations of the device. >From 9dfc5fde568c5a4cd29471888bff538943a995b1 Mon Sep 17 00:00:00 2001 From: Jozef Lawrynowicz Date: Tue, 29 Oct 2019 14:49:08 + Subject: [PATCH 1/4] MSP430: Disable TM clone registry by default libgcc/ChangeLog: 2019-11-07 Jozef Lawrynowicz * configure: Regenerate. * configure.ac (tm-clone-registry): Disable by default for MSP430. --- libgcc/configure| 9 + libgcc/configure.ac | 8 2 files changed, 17 insertions(+) diff --git a/libgcc/configure b/libgcc/configure index 117e9c97e57..26d4d68a510 100755 --- a/libgcc/configure +++ b/libgcc/configure @@ -4964,6 +4964,15 @@ if test "$enable_tm_clone_registry" = no; then use_tm_clone_registry=-DUSE_TM_CLONE_REGISTRY=0 fi +else + +use_tm_clone_registry= +case $target in + msp430*) + use_tm_clone_registry=-DUSE_TM_CLONE_REGISTRY=0 + ;; +esac + fi diff --git a/libgcc/configure.ac b/libgcc/configure.ac index f63c5e736e5..0f225b84117 100644 --- a/libgcc/configure.ac +++ b/libgcc/configure.ac @@ -268,6 +268,14 @@ use_tm_clone_registry= if test "$enable_tm_clone_registry" = no; then use_tm_clone_registry=-DUSE_TM_CLONE_REGISTRY=0 fi +], +[ +use_tm_clone_registry= +case $target in + msp430*) + use_tm_clone_registry=-DUSE_TM_CLONE_REGISTRY=0 + ;; +esac ]) AC_SUBST([use_tm_clone_registry]) -- 2.17.1
[PATCH 2/4] MSP430: Disable exception handling by default for C++
The code size bloat added by building C++ programs using libraries containing
support for exceptions is significant. When using simple constructs such as
static variables, sometimes many kB from the libraries are unnecessarily
pulled in.
So this patch disable exceptions by default for MSP430 when compiling for C++,
by implicitly passing -fno-exceptions unless -fexceptions is passed.
Multilibs have been added for the -fexceptions configuration.
Since building double the multilibs does significantly increase build time,
the patch also adds a configure option --disable-exceptions. This disables the
fexceptions mulitlibs from being built.
There was a lot of fallout from the G++ testsuite caused by disabling exceptions
by default.
I've mitigated some of it by adding dg-prune strings which mark a test as
unsupported if the compiler reports exception handling is disabled. This doesn't
work for some execution tests or tests for warnings/errors/messages.
There's some further mitigation achieved by new functionality which
will pass -fexceptions as a default flag if exceptions are supported but not
enabled by default.
However, for tests with dg-options directives, this gets ignored. So
for these tests (of which there weren't *too* many, I've added -fexceptions to
the dg-options directives in the tests.
As a result of all the above there aren't any DejaGNU regressions.
>From 7844e05172d07443167c3e852cf0b695f043c0eb Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Tue, 29 Oct 2019 15:32:07 +
Subject: [PATCH 2/4] MSP430: Disable exception handling by default for C++
ChangeLog:
2019-11-07 Jozef Lawrynowicz
* config-ml.in: Support --disable-exceptions configure flag.
gcc/ChangeLog:
2019-11-07 Jozef Lawrynowicz
* config/msp430/msp430.h (STARTFILE_SPEC) [!fexceptions]: Use
crtbegin_no_eh.o.
(ENDFILE_SPEC) [!fexceptions]: Use crtend_no_eh.o.
(CC1PLUS_SPEC): Define.
* config/msp430/t-msp430: Add -fexceptions multilibs.
* doc/install.texi: Document --disable-exceptions configure option.
* doc/invoke.texi: Document that exceptions are disabled by default for
C++ for msp430-elf.
gcc/testsuite/ChangeLog:
2019-11-07 Jozef Lawrynowicz
* g++.dg/cpp1y/sized-dealloc2.C: Add -fexceptions to dg-options.
* g++.dg/cpp2a/explicit1.C: Likewise.
* g++.dg/cpp2a/explicit2.C: Likewise.
* g++.dg/cpp2a/explicit5.C: Likewise.
* g++.dg/eh/array1.C: Likewise.
* g++.dg/eh/spec11.C: Likewise.
* g++.dg/eh/spec6.C: Likewise.
* g++.dg/ext/vla4.C: Likewise.
* g++.dg/ipa/pr64612.C: Likewise.
* g++.dg/other/error32.C: Likewise.
* g++.dg/torture/pr34850.C: Likewise.
* g++.dg/tree-ssa/ivopts-3.C: Likewise.
* g++.dg/tree-ssa/pr33615.C: Likewise.
* g++.dg/warn/Wcatch-value-1.C: Likewise.
* g++.dg/warn/Wcatch-value-2.C: Likewise.
* g++.dg/warn/Wcatch-value-3.C: Likewise.
* g++.dg/warn/Wstringop-truncation-2.C: Likewise.
* g++.dg/warn/Wterminate1.C: Likewise.
* g++.dg/warn/pr83054.C: Likewise.
* g++.old-deja/g++.other/cond5.C: Likewise.
* g++.dg/dg.exp: Pass -fexceptions as a default flag if exceptions
aren't enabled by default.
* g++.dg/torture/dg-torture.exp: Likewise.
* g++.old-deja/old-deja.exp:
* lib/gcc-dg.exp: Add dg-prune messages for when exception handling is
disabled.
* lib/target-supports.exp (check_effective_target_exceptions): Check if
GCC was configured with --disable-exceptions.
(check_effective_target_exceptions_enabled_by_default): New.
libgcc/ChangeLog:
2019-11-07 Jozef Lawrynowicz
* config.host: Add crt{begin,end}_no_eh.o to "extra_parts".
* config/msp430/t-msp430: Add rules to build crt{begin,end}_no_eh.o.
---
config-ml.in | 13 ++
gcc/config/msp430/msp430.h| 11 +++--
gcc/config/msp430/t-msp430| 9 +++
gcc/doc/install.texi | 3 +++
gcc/doc/invoke.texi | 6 +++--
gcc/testsuite/g++.dg/cpp1y/sized-dealloc2.C | 2 +-
gcc/testsuite/g++.dg/cpp2a/explicit1.C| 2 +-
gcc/testsuite/g++.dg/cpp2a/explicit2.C| 2 +-
gcc/testsuite/g++.dg/cpp2a/explicit5.C| 2 +-
gcc/testsuite/g++.dg/dg.exp | 9 ++-
gcc/testsuite/g++.dg/eh/array1.C | 2 +-
gcc/testsuite/g++.dg/eh/spec11.C | 2 +-
gcc/testsuite/g++.dg/eh/spec6.C | 2 +-
gcc/testsuite/g++.dg/ext/vla4.C | 2 +-
gcc/testsuite/g++.dg/ipa/pr64612.C| 2 +-
gcc/testsuite/g++.dg/other/error32.C | 2 +-
gcc/testsuite/g++.dg/torture/dg-torture.exp | 9 ++-
gcc/testsuite/g++.dg/torture/pr34850.C| 2 +-
gcc/testsuite/g++.dg/tree-ssa/ivopts-3.C | 2 +-
gcc/testsuite/g++.dg/tree-ssa/pr33615.C | 2 +-
gcc/testsuite/g++.dg/warn/Wcatch-value-1.C| 2 +-
gcc/testsuite/g++.dg/warn/Wcatch-value-2.C| 2 +-
gcc/testsuite/g++.dg/warn/Wcatch-value-3.C| 2 +-
.../g++.dg/warn/Wstringop-t
[PATCH 3/4] MSP430: Disable __cxa_atexit
The MSP430 target does not need to support dynamic shared objects so
__cxa_atexit does not need to be used - atexit is sufficient.
Newlib atexit is a fine replacement as it also supports registration of more
than 32 functions.
By not using __cxa_atexit, we can define TARGET_LIBGCC_REMOVE_DSO_HANDLE to
remove the definition of __dso_handle from crtstuff.c, saving code size by
removing the necessity to link in functions to initialize global data in
*every* program.
>From a0086b73d0e029cab2f65a91e67a2502e4d4 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Wed, 30 Oct 2019 16:39:52 +
Subject: [PATCH 3/4] MSP430: Disable __cxa_atexit
gcc/ChangeLog:
2019-11-07 Jozef Lawrynowicz
* config.gcc (msp430*-*-*): Disable __cxa_atexit by default.
* config/msp430/msp430.c (msp430_option_override): Emit an error if
-fuse-cxa-atexit was used when __cxa_atexit was disabled at configure
time.
* config/msp430/msp430.h (TARGET_LIBGCC_REMOVE_DSO_HANDLE): Define if
__cxa_atexit was disabled at configure time.
gcc/testsuite/ChangeLog:
2019-11-07 Jozef Lawrynowicz
* g++.dg/init/dso_handle1.C: Add dg-require-cxa-atexit.
* g++.dg/init/dso_handle2.C: Likewise.
* g++.dg/other/cxa-atexit1.C: Likewise.
* lib/target-supports.exp (check_cxa_atexit_available): Add hard-coded
case for msp430.
---
gcc/config.gcc | 7 +++
gcc/config/msp430/msp430.c | 9 +
gcc/config/msp430/msp430.h | 6 ++
gcc/testsuite/g++.dg/init/dso_handle1.C | 1 +
gcc/testsuite/g++.dg/init/dso_handle2.C | 1 +
gcc/testsuite/g++.dg/other/cxa-atexit1.C | 1 +
gcc/testsuite/lib/target-supports.exp| 3 +++
7 files changed, 28 insertions(+)
diff --git a/gcc/config.gcc b/gcc/config.gcc
index d74bcbb9856..2e79101cc8f 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -2533,6 +2533,13 @@ msp430*-*-*)
tmake_file="${tmake_file} msp430/t-msp430"
extra_objs="${extra_objs} msp430-devices.o"
extra_gcc_objs="driver-msp430.o msp430-devices.o"
+
+ # __cxa_atexit increases code size, and we don't need to support dynamic
+ # shared objects on MSP430, so regular Newlib atexit is a fine
+ # replacement as it also supports registration of more than 32
+ # functions.
+ default_use_cxa_atexit=no
+
# Enable .init_array unless it has been explicitly disabled.
# The MSP430 EABI mandates the use of .init_array, and the Newlib CRT
# code since mid-2019 expects it.
diff --git a/gcc/config/msp430/msp430.c b/gcc/config/msp430/msp430.c
index fe1fcc0db43..ce8d863abd3 100644
--- a/gcc/config/msp430/msp430.c
+++ b/gcc/config/msp430/msp430.c
@@ -284,6 +284,15 @@ msp430_option_override (void)
possible to build newlib with -Os enabled. Until now... */
if (TARGET_OPT_SPACE && optimize < 3)
optimize_size = 1;
+
+#if !DEFAULT_USE_CXA_ATEXIT
+ /* By default, we enforce atexit() instead of __cxa_atexit() to save on code
+ size and remove the declaration of __dso_handle from the CRT library.
+ Configuring GCC with --enable-__cxa-atexit re-enables it by defining
+ DEFAULT_USE_CXA_ATEXIT to 1. */
+ if (flag_use_cxa_atexit)
+error ("%<-fuse-cxa-atexit%> is not supported for msp430-elf");
+#endif
}
#undef TARGET_SCALAR_MODE_SUPPORTED_P
diff --git a/gcc/config/msp430/msp430.h b/gcc/config/msp430/msp430.h
index 90ceec0e947..25944125182 100644
--- a/gcc/config/msp430/msp430.h
+++ b/gcc/config/msp430/msp430.h
@@ -509,4 +509,10 @@ typedef struct
#define ASM_OUTPUT_ALIGNED_DECL_COMMON(FILE, DECL, NAME, SIZE, ALIGN) \
msp430_output_aligned_decl_common ((FILE), (DECL), (NAME), (SIZE), (ALIGN))
+#if !DEFAULT_USE_CXA_ATEXIT
+/* We're not using __cxa_atexit, so __dso_handle isn't needed. */
+#undef TARGET_LIBGCC_REMOVE_DSO_HANDLE
+#define TARGET_LIBGCC_REMOVE_DSO_HANDLE
+#endif
+
#define SYMBOL_FLAG_LOW_MEM (SYMBOL_FLAG_MACH_DEP << 0)
diff --git a/gcc/testsuite/g++.dg/init/dso_handle1.C b/gcc/testsuite/g++.dg/init/dso_handle1.C
index 97f67cad8f4..dc92e22d12a 100644
--- a/gcc/testsuite/g++.dg/init/dso_handle1.C
+++ b/gcc/testsuite/g++.dg/init/dso_handle1.C
@@ -1,6 +1,7 @@
// PR c++/17042
// { dg-do assemble }
/* { dg-require-weak "" } */
+// { dg-require-cxa-atexit "" }
// { dg-options "-fuse-cxa-atexit" }
struct A
diff --git a/gcc/testsuite/g++.dg/init/dso_handle2.C b/gcc/testsuite/g++.dg/init/dso_handle2.C
index b219dc02611..6e151e50fa7 100644
--- a/gcc/testsuite/g++.dg/init/dso_handle2.C
+++ b/gcc/testsuite/g++.dg/init/dso_handle2.C
@@ -1,4 +1,5 @@
// PR c++/58846
+// { dg-require-cxa-atexit "" }
// { dg-options "-fuse-cxa-atexit" }
extern "C" { char* __dso_handle; }
diff --git a/gcc/testsuite/g++.dg/other/cxa-atexit1.C b/gcc/testsuite/g++.dg/other/cxa-atexit1.C
index a51f3340142..d6ab3dc4733 100644
--- a/gcc/testsuite/g++.dg/other/cxa-atexit1.C
+++ b/gcc/testsuite/g++.dg/other/cxa-atexit1.C
@@ -1
[PATCH 4/4] MSP430: Deprecate -minrt option
Support for the MSP430 -minrt option has been removed from Newlib, since all the
associated behaviour is now dynamic. Initialization code run before main is only
included when needed.
This patch removes the final traces of -minrt from GCC.
-minrt used to modify the linking process in the following ways:
* Removing .init and .fini sections, by using a reduced crt0 and excluding crtn.
* Removing crtbegin and crtend (thereby not using crtstuff.c at all).
+ This meant that even if the program had constructors for global or
static objects which must run before main, it would blindly remove them.
These causes of code bloat have been addressed by:
* switching to .{init,fini}_array instead of using .{init,fini} sections
"Lean" code to run through constructors before main is only included if
.init_array has contents.
* removing bloat (frame_dummy, *tm_clones*, *do_global_dtors*) from the
crtstuff.c with the changes in the previous patches
Here are some examples of the total size of different "barebones" C programs to
show that the size previously achieved by -minrt is now matched by default:
program |old (with -minrt) |new (without -minrt)
-
Empty main |20 |20
Looping main|14 |14
Looping main with data |94 |94
Looping main with bss |56 |56
>From 6e561b45c118540f06d5828ec386d2dd79c13b62 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Wed, 6 Nov 2019 18:12:45 +
Subject: [PATCH 4/4] MSP430: Remove -minrt option
gcc/ChangeLog:
2019-11-07 Jozef Lawrynowicz
* config/msp430/msp430.h (STARTFILE_SPEC): Remove -minrt rules.
Use "if, then, else" syntax for specs.
(ENDFILE_SPEC): Likewise.
* config/msp430/msp430.opt: Mark -minrt as deprecated.
* doc/invoke.texi: Remove -minrt documentation.
---
gcc/config/msp430/msp430.h | 9 -
gcc/config/msp430/msp430.opt | 4 ++--
gcc/doc/invoke.texi | 9 +
3 files changed, 7 insertions(+), 15 deletions(-)
diff --git a/gcc/config/msp430/msp430.h b/gcc/config/msp430/msp430.h
index 25944125182..3f013a9d315 100644
--- a/gcc/config/msp430/msp430.h
+++ b/gcc/config/msp430/msp430.h
@@ -45,15 +45,14 @@ extern bool msp430x;
while (0)
#undef STARTFILE_SPEC
-#define STARTFILE_SPEC "%{pg:gcrt0.o%s}" \
- "%{!pg:%{minrt:crt0-minrt.o%s}%{!minrt:crt0.o%s}} " \
- "%{!minrt:%{fexceptions:crtbegin.o%s}%{!fexceptions:crtbegin_no_eh.o%s}}"
+#define STARTFILE_SPEC "%{pg:gcrt0.o%s; :crt0.o%s} " \
+ "%{fexceptions:crtbegin.o%s; :crtbegin_no_eh.o%s}"
/* -lgcc is included because crtend.o needs __mspabi_func_epilog_1. */
#undef ENDFILE_SPEC
#define ENDFILE_SPEC \
- "%{!minrt:%{fexceptions:crtend.o%s}%{!fexceptions:crtend_no_eh.o%s}} " \
- "%{minrt:%:if-exists(crtn-minrt.o%s)}%{!minrt:%:if-exists(crtn.o%s)} -lgcc"
+ "%{fexceptions:crtend.o%s; :crtend_no_eh.o%s} " \
+ "%:if-exists(crtn.o%s) -lgcc"
#define ASM_SPEC "-mP " /* Enable polymorphic instructions. */ \
"%{mcpu=*:-mcpu=%*} " /* Pass the CPU type on to the assembler. */ \
diff --git a/gcc/config/msp430/msp430.opt b/gcc/config/msp430/msp430.opt
index 2db2906ca11..74fdcdf0851 100644
--- a/gcc/config/msp430/msp430.opt
+++ b/gcc/config/msp430/msp430.opt
@@ -38,8 +38,8 @@ mOs
Target Undocumented Mask(OPT_SPACE)
minrt
-Target Report Mask(MINRT) RejectNegative
-Use a minimum runtime (no static initializers or ctors) for memory-constrained devices.
+Target Undocumented WarnRemoved
+This option is deprecated in GCC10 and has no effect.
HeaderInclude
config/msp430/msp430-opts.h
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 6829b949b4b..12a360ed6a7 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -1009,7 +1009,7 @@ Objective-C and Objective-C++ Dialects}.
-mwarn-mcu @gol
-mcode-region= -mdata-region= @gol
-msilicon-errata= -msilicon-errata-warn= @gol
--mhwmult= -minrt}
+-mhwmult=}
@emph{NDS32 Options}
@gccoptlist{-mbig-endian -mlittle-endian @gol
@@ -23262,13 +23262,6 @@ The hardware multiply routines disable interrupts whilst running and
restore the previous interrupt state when they finish. This makes
them safe to use inside interrupt handlers as well as in normal code.
-@item -minrt
-@opindex minrt
-Enable the use of a minimum runtime environment - no static
-initializers or constructors. This is intended for memory-constrained
-devices. The compiler includes special symbols in some objects
-that tell the linker and runtime which code fragments are required.
-
@item -mcode-region=
@itemx -mdata-region=
@opindex mcode-region
--
2.17.1
Re: [PATCH 2/4] MSP430: Disable exception handling by default for C++
On Fri, 08 Nov 2019 09:07:39 +0900
Oleg Endo wrote:
> On Thu, 2019-11-07 at 21:37 +0000, Jozef Lawrynowicz wrote:
> > The code size bloat added by building C++ programs using libraries
> > containing
> > support for exceptions is significant. When using simple constructs such as
> > static variables, sometimes many kB from the libraries are unnecessarily
> > pulled in.
> >
> > So this patch disable exceptions by default for MSP430 when compiling for
> > C++,
> > by implicitly passing -fno-exceptions unless -fexceptions is passed.
>
> It is extremely annoying when GCC's default standard behavior differs
> across different targets. And as a consequence, you have to add a load
> of workarounds and disable other things, like fiddling with the
> testsuite. It's the same thing as setting "double = float" to get more
> "speed" by default.
>
> I would strongly advice against making such non-standard behaviors the
> default in the vanilla compiler. C++ normally has exceptions enabled.
> If a user doesn't want them and is willing to deal with it all the
> consequences, then we already have a mechanism to do that:
> --fno-exceptions
>
> Perhaps it's generally more useful to add a global configure option for
> GCC to disable exception handling by default. Then you can provide a
> turn-key toolchain to your customers as well -- just add an option to
> the configure line.
>
> Cheers,
> Oleg
>
Fair point, I probably should have realised whilst implementing all the
testsuite workarounds that this wasn't the best choice for upstream GCC and
integrating nicely with the testsuite.
So I've regtested and attached a revised patch to instead build -fno-exceptions
multilibs, so the reduced code size can still be achieved by passing with
-fno-exceptions.
And the --disable-no-exceptions multilib option is added to reduce build time
for developers.
Thanks for providing your input,
Jozef
>From fe67a5ff71bc48af05b086b2d495fbf77e1a070d Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Fri, 8 Nov 2019 10:47:26 +
Subject: [PATCH 2/4] MSP430: Add -fno-exceptions multilib
ChangeLog:
2019-11-08 Jozef Lawrynowicz
* config-ml.in: Support --disable-no-exceptions configure flag.
gcc/ChangeLog:
2019-11-08 Jozef Lawrynowicz
* config/msp430/msp430.h (STARTFILE_SPEC) [fno-exceptions]: Use
crtbegin_no_eh.o.
(ENDFILE_SPEC) [fno-exceptions]: Use crtend_no_eh.o.
* config/msp430/t-msp430: Add -fno-exceptions multilib.
* doc/install.texi: Document --disable-no-exceptions multilib configure
option.
gcc/testsuite/ChangeLog:
2019-11-08 Jozef Lawrynowicz
* lib/gcc-dg.exp: Add dg-prune messages for when exception handling is
disabled.
libgcc/ChangeLog:
2019-11-08 Jozef Lawrynowicz
* config.host: Add crt{begin,end}_no_eh.o to "extra_parts".
* config/msp430/t-msp430: Add rules to build crt{begin,end}_no_eh.o.
---
config-ml.in | 13 +
gcc/config/msp430/msp430.h| 6 --
gcc/config/msp430/t-msp430| 9 +
gcc/doc/install.texi | 3 +++
gcc/testsuite/lib/gcc-dg.exp | 10 ++
libgcc/config.host| 3 ++-
libgcc/config/msp430/t-msp430 | 6 ++
7 files changed, 43 insertions(+), 7 deletions(-)
diff --git a/config-ml.in b/config-ml.in
index 3e37f875c88..5720d38d23f 100644
--- a/config-ml.in
+++ b/config-ml.in
@@ -383,6 +383,19 @@ mips*-*-*)
done
fi
;;
+msp430-*-*)
+ if [ x$enable_no_exceptions = xno ]
+ then
+ old_multidirs="${multidirs}"
+ multidirs=""
+ for x in ${old_multidirs}; do
+ case "$x" in
+ *no-exceptions* ) : ;;
+ *) multidirs="${multidirs} ${x}" ;;
+ esac
+ done
+ fi
+ ;;
powerpc*-*-* | rs6000*-*-*)
if [ x$enable_aix64 = xno ]
then
diff --git a/gcc/config/msp430/msp430.h b/gcc/config/msp430/msp430.h
index 73afe2e2d16..4d796f67d1b 100644
--- a/gcc/config/msp430/msp430.h
+++ b/gcc/config/msp430/msp430.h
@@ -46,11 +46,13 @@ extern bool msp430x;
#undef STARTFILE_SPEC
#define STARTFILE_SPEC "%{pg:gcrt0.o%s}" \
- "%{!pg:%{minrt:crt0-minrt.o%s}%{!minrt:crt0.o%s}} %{!minrt:crtbegin.o%s}"
+ "%{!pg:%{minrt:crt0-minrt.o%s}%{!minrt:crt0.o%s}} " \
+ "%{!minrt:%{fno-exceptions:crtbegin_no_eh.o%s; :crtbegin.o%s}}"
/* -lgcc is included because crtend.o needs __mspabi_func_epilog_1. */
#undef ENDFILE_SPEC
-#define ENDFILE_SPEC "%{!minrt:crtend.o%s} " \
+#define ENDFILE_SPEC \
+ "%{!minrt:%{fno-exceptions:crtend_no_eh.o%s; :crtend.o%s}} " \
"%{minrt:%:if-exists(crtn-minrt.o%s)}%{!minrt:%:if-exists(crtn.o%s)} -lgcc"
#define ASM_SPEC "-mP " /* Enable polymorphic instructions. */ \
diff --git a/gcc/config/msp430/t-msp430 b/gcc/config/msp430/t-msp430
index f8ba7751
Re: [PATCH 0/4][MSP430] Tweaks to default configuration to reduce code size
On Fri, 08 Nov 2019 21:14:19 +0900 Oleg Endo wrote: > On Thu, 2019-11-07 at 21:31 +0000, Jozef Lawrynowicz wrote: > > When building small programs for MSP430, the impact of the unused > > functions pulled in from the CRT libraries is quite noticeable. Most of > > these > > relates to feature that will never be used for MSP430 (Transactional memory, > > supporting shared objects and dynamic linking), or rarely used (exception > > handling). > > There's a magic switch, which does the business, at least for me, most > of the time: > >-flto > > If you're trying to bring down the executable size as much as possible, > but don't use -flto, I think something is wrong. > > Cheers, > Oleg > Yes, I should have used -flto in my examples. But it doesn't help remove these CRT library functions which are normally either directly added to the list of functions to run before main (via .init, .ctors or .init_array) or used in functions which are themselves added to this list. The unnecessary functions we want to remove are: deregister_tm_clones register_tm_clones __do_global_dtors_aux frame_dummy LTO can't remove any of them. Thanks, Jozef
Re: [PATCH 0/4][MSP430] Tweaks to default configuration to reduce code size
On Fri, 08 Nov 2019 22:59:18 +0900 Oleg Endo wrote: > On Fri, 2019-11-08 at 13:27 +0000, Jozef Lawrynowicz wrote: > > > > Yes, I should have used -flto in my examples. But it doesn't help remove > > these > > CRT library functions which are normally either directly added to the > > list of functions to run before main (via .init, .ctors or .init_array) or > > used > > in functions which are themselves added to this list. > > > > The unnecessary functions we want to remove are: > > deregister_tm_clones > > register_tm_clones > > __do_global_dtors_aux > > frame_dummy > > LTO can't remove any of them. > > > > Ah, right, good point. That's not MSP430 specific actually. For those > things I usually have custom init code, which also does other things > occasionally. Stripping off global dtors is then an option in the > build system which takes care of it (in my case, I do it by modifying > the generated linker script). > > But again, as with the exceptions, it might be better to implement > these kind of things outside of the compiler, e.g. by building the app > with -nostartfiles -nodefaultlibs and providing your own substitutes. I just don't think we need to be putting up this high barrier to entry for users who want reduced code size but are building GCC from source. With these changes users are getting a highly size-optimized runtime library (14 bytes for a program that gets you to main() is always nice to see) out of the box, by simply removing features that do not make sense on the target, and they don't have to faff with any extra options. The size of the CRT code has been a long standing complaint and is some part of the reason a large chunk of the MSP430 user base still uses "mspgcc" which is the old downstream GCC port of the target, which hasn't has any development since 2012. > > Another option is to patch those things in using the OS part of the > target triplet. Interesting idea. Something like msp430-unknown-min(imum)? The thing is even with these changes the target is still ELF compliant. Although I guess supplying a configuration which disables exceptions is not very ELF-y. Thanks, Jozef > > Cheers, > Oleg >
[PATCH] "used" attribute saves decl from linker garbage collection
The attached patch implements TARGET_ASM_MARK_DECL_PRESERVED for ELF GNU
OSABI targets, so that declarations that have the "used" attribute
applied will be saved from linker garbage collection.
TARGET_ASM_MARK_DECL_PRESERVED will emit an assembler ".retain"
directive for the decl, and the assembler will apply the SHF_GNU_RETAIN
flag to the section containing the decl.
The linker will not garbage collect sections marked with the
SHF_GNU_RETAIN flag.
SHF_GNU_RETAIN is a GNU OSABI ELF extension, and it was discussed on the
GNU gABI mailing list here:
https://sourceware.org/pipermail/gnu-gabi/2020q3/000429.html
The Binutils patch to implement .retain and other SHF_GNU_RETAIN
handling is posted here:
https://sourceware.org/pipermail/binutils/2020-November/113993.html
Successfully bootstrapped and regtested for x86_64-pc-linux-gnu, and
regtested for arm-none-eabi.
Ok for trunk?
Thanks,
Jozef
>From 0827e28480b7edd07cda4f938bdd14b1cbdf1fa2 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Thu, 29 Oct 2020 21:00:07 +
Subject: [PATCH] Implement TARGET_MARK_DECL_PRESERVED for ELF GNU OSABI
targets
The GAS .retain directive will apply the SHF_GNU_RETAIN flag to the
section containing the symbol that must be preserved.
gcc/ChangeLog:
* config.in: Regenerate.
* config/elfos.h (TARGET_ASM_MARK_DECL_PRESERVED): Define for
HAVE_GAS_RETAIN.
* configure: Regenerate.
* configure.ac: Define HAVE_GAS_RETAIN.
* doc/extend.texi (used attribute): Document saving from linker garbage
collection.
* doc/sourcebuild.texi: Document "retain" effective target keyword.
* doc/tm.texi: Regenerate.
* output.h (default_elf_mark_decl_preserved): New.
* target.def (mark_decl_preserved): Mention GAS .retain directive.
* varasm.c (default_elf_mark_decl_preserved): New.
gcc/testsuite/ChangeLog:
* c-c++-common/attr-used-2.c: Test for .retain in assembler output.
* c-c++-common/attr-used.c: Likewise.
* lib/target-supports.exp (check_effective_target_retain): New.
---
gcc/config.in| 6
gcc/config/elfos.h | 7 +
gcc/configure| 35
gcc/configure.ac | 8 ++
gcc/doc/extend.texi | 6
gcc/doc/sourcebuild.texi | 3 ++
gcc/doc/tm.texi | 2 +-
gcc/output.h | 4 +++
gcc/target.def | 2 +-
gcc/testsuite/c-c++-common/attr-used-2.c | 1 +
gcc/testsuite/c-c++-common/attr-used.c | 2 ++
gcc/testsuite/lib/target-supports.exp| 9 ++
gcc/varasm.c | 13 +
13 files changed, 96 insertions(+), 2 deletions(-)
diff --git a/gcc/config.in b/gcc/config.in
index 3657c46f349..8ef075a0ff3 100644
--- a/gcc/config.in
+++ b/gcc/config.in
@@ -1346,6 +1346,12 @@
#endif
+/* Define if your assembler supports the .retain directive. */
+#ifndef USED_FOR_TARGET
+#undef HAVE_GAS_RETAIN
+#endif
+
+
/* Define if your assembler supports specifying the exclude section flag. */
#ifndef USED_FOR_TARGET
#undef HAVE_GAS_SECTION_EXCLUDE
diff --git a/gcc/config/elfos.h b/gcc/config/elfos.h
index 74a3eafda6b..fab7b0e8ea4 100644
--- a/gcc/config/elfos.h
+++ b/gcc/config/elfos.h
@@ -474,3 +474,10 @@ see the files COPYING3 and COPYING.RUNTIME respectively.
If not, see
#undef TARGET_LIBC_HAS_FUNCTION
#define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function
+
+/* If the assembler supports the .retain directive for saving a symbol
+ from linker garbage collection, define this macro. */
+#if HAVE_GAS_RETAIN
+#undef TARGET_ASM_MARK_DECL_PRESERVED
+#define TARGET_ASM_MARK_DECL_PRESERVED default_elf_mark_decl_preserved
+#endif
diff --git a/gcc/configure b/gcc/configure
index abff47d30eb..37488eac25d 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -24223,6 +24223,41 @@ cat >>confdefs.h <<_ACEOF
_ACEOF
+# Test if the assembler supports the .retain directive for saving a symbol from
+# linker garbage collection.
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking assembler for retain
directive" >&5
+$as_echo_n "checking assembler for retain directive... " >&6; }
+if ${gcc_cv_as_retain_r+:} false; then :
+ $as_echo_n "(cached) " >&6
+else
+ gcc_cv_as_retain_r=no
+ if test x$gcc_cv_as != x; then
+$as_echo '.retain retain_sym' > conftest.s
+if { ac_try='$gcc_cv_as $gcc_cv_as_flags -o conftest.o conftest.s >&5'
+ { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
+ (eval $ac_try) 2>&5
+ ac_status=$?
+ $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
+ test $ac_status = 0; }; }
+then
+ gcc_cv_as_
Re: [PATCH] "used" attribute saves decl from linker garbage collection
On Tue, Nov 03, 2020 at 09:57:58AM -0800, H.J. Lu via Gcc-patches wrote: > On Tue, Nov 3, 2020 at 9:41 AM Jozef Lawrynowicz > wrote: > > > > The attached patch implements TARGET_ASM_MARK_DECL_PRESERVED for ELF GNU > > OSABI targets, so that declarations that have the "used" attribute > > applied will be saved from linker garbage collection. > > > > TARGET_ASM_MARK_DECL_PRESERVED will emit an assembler ".retain" > > Can you use the "R" flag instead? > For the benefit of this mailing list, I have copied my response from the Binutils mailing list regarding this. The "comm_section" example I gave is actually innacurate, but you can see the examples of the variety of sections that would need to be handled by doing $ git grep -A2 "define.*SECTION_ASM_OP" gcc/ | grep "\".*\." > ... snip ... > Secondly, for seamless integration with the "used" attribute, we must be > able to to mark the symbol with the used attribute applied as "retained" > without changing its section name. For GCC "named" sections, this is > straightforward, but for "unnamed" sections it is a giant mess. > > The section name for a GCC "unnamed" section is not readily available, > instead a string which contains the full assembly code to switch to one > of these text/data/bss/rodata/comm etc. sections is encoded in the > structure. > > Backends define the assembly code to switch to these sections (some > "*ASM_OP*" macro) in a variety of ways. For example, the unnamed section > "comm_section", might correspond to a .bss section, or emit a .comm > directive. I even looked at trying to parse them to extract what the > name of a section will be, but it would be very messy and not robust. > > Meanwhile, having a .retain directive is a very simmple > solution, and keeps the GCC implementation really concise (patch > attached). The assembler will know for sure what the section containing > the symbol will be, and can apply the SHF_GNU_RETAIN flag directly. > > Finally, having a .retain directive means that we don't need to support > multiple sections with the same name, but different states for the "R" > flag. For example, and Fangrui raised this point in previous discussion, > the following is undesirable, as it violates the rule we have about > section flags set in .section directives being the same for sections of > the same name: > > .section .text,"ax",%progbits >... > .section .text,"axR",%progbits > > > > The above would be required if GCC can only mark decls are retained by > explicitly placing them in a section with the SHF_GNU_RETAIN flag > applied. The .retain directive greatly simplifies the > process for GCC. > > directive for the decl, and the assembler will apply the SHF_GNU_RETAIN > > flag to the section containing the decl. > > The linker will not garbage collect sections marked with the > > SHF_GNU_RETAIN flag. > > > > SHF_GNU_RETAIN is a GNU OSABI ELF extension, and it was discussed on the > > GNU gABI mailing list here: > > https://sourceware.org/pipermail/gnu-gabi/2020q3/000429.html > > > > The Binutils patch to implement .retain and other SHF_GNU_RETAIN > > handling is posted here: > > https://sourceware.org/pipermail/binutils/2020-November/113993.html > > > > Successfully bootstrapped and regtested for x86_64-pc-linux-gnu, and > > regtested for arm-none-eabi. > > > > Ok for trunk? > > > > Thanks, > > Jozef > > > > -- > H.J.
Re: [PATCH] "used" attribute saves decl from linker garbage collection
On Tue, Nov 03, 2020 at 11:58:04AM -0800, H.J. Lu via Gcc-patches wrote: > On Tue, Nov 3, 2020 at 10:22 AM Jozef Lawrynowicz > wrote: > > > > On Tue, Nov 03, 2020 at 09:57:58AM -0800, H.J. Lu via Gcc-patches wrote: > > > On Tue, Nov 3, 2020 at 9:41 AM Jozef Lawrynowicz > > > wrote: > > > > > > > > The attached patch implements TARGET_ASM_MARK_DECL_PRESERVED for ELF GNU > > > > OSABI targets, so that declarations that have the "used" attribute > > > > applied will be saved from linker garbage collection. > > > > > > > > TARGET_ASM_MARK_DECL_PRESERVED will emit an assembler ".retain" > > > > > > Can you use the "R" flag instead? > > > > > > > For the benefit of this mailing list, I have copied my response from the > > Binutils mailing list regarding this. > > The "comm_section" example I gave is actually innacurate, but you can > > see the examples of the variety of sections that would need to be > > handled by doing > > > > $ git grep -A2 "define.*SECTION_ASM_OP" gcc/ | grep "\".*\." > > > > > ... snip ... > > > Secondly, for seamless integration with the "used" attribute, we must be > > > able to to mark the symbol with the used attribute applied as "retained" > > > without changing its section name. For GCC "named" sections, this is > > > straightforward, but for "unnamed" sections it is a giant mess. > > > > > > The section name for a GCC "unnamed" section is not readily available, > > > instead a string which contains the full assembly code to switch to one > > > of these text/data/bss/rodata/comm etc. sections is encoded in the > > > structure. > > > > > > Backends define the assembly code to switch to these sections (some > > > "*ASM_OP*" macro) in a variety of ways. For example, the unnamed section > > > "comm_section", might correspond to a .bss section, or emit a .comm > > > directive. I even looked at trying to parse them to extract what the > > > name of a section will be, but it would be very messy and not robust. > > > > > > Meanwhile, having a .retain directive is a very simmple > > > solution, and keeps the GCC implementation really concise (patch > > > attached). The assembler will know for sure what the section containing > > > the symbol will be, and can apply the SHF_GNU_RETAIN flag directly. > > > > > Please take a look at > > https://gitlab.com/x86-gcc/gcc/-/commits/users/hjl/elf/shf_retain > > which is built in top of > > https://gcc.gnu.org/pipermail/gcc-patches/2020-February/539963.html > > I think SECTION2_RETAIN matches SHF_GNU_RETAIN well. If you > want, you extract my flags2 change and use it for SHF_GNU_RETAIN. In your patch you have to make the assumption that data_section, always corresponds to a section named .data. For just this example, c6x (which supports the GNU ELF OSABI) does not fit the rule: > c6x/elf-common.h:#define DATA_SECTION_ASM_OP "\t.section\t\".fardata\",\"aw\"" data_section for c6x corresponds to .fardata, not .data. So the use of "used" on a data declaration would place it in a different section, that if the "used" attribute was not applied. For c6x and mips, readonly_data_section does not correspond to .rodata, so that assumption cannot be made either: > c6x/elf-common.h:#define READONLY_DATA_SECTION_ASM_OP > "\t.section\t\".const\",\"a\",@progbits" > mips/mips.h:#define READONLY_DATA_SECTION_ASM_OP"\t.rdata" /* > read-only data */ The same can be said for bss_section for c6x as well. Furthermore, this is only considering the examples in default_elf_select_section - the less standard unnamed section are used in many backend's implementation of select_section, and we would need to work out what section name they correspond to to properly support SHF_GNU_RETAIN. For every unnamed section, you either have to assume what the corresponding section name is, or parse the associated assembly output string for the section. Given these edge cases which must be handled for GCC to robustly emit the "R" flag for sections containing "used" symbols, surely it is preferable to leverage the existing TARGET_ASM_MARK_DECL_PRESERVED and emit a .retain directive, which is extremely simple and doesn't require any handling of these edge cases and non-standard backend implementations. The point about multiple section directives, some with the "R" flag some without, still applies as a downside to trying to emit the .section directives for the "used" attribute. Thanks, Jozef > > -- > H.J.
Re: [PATCH] "used" attribute saves decl from linker garbage collection
On Tue, Nov 03, 2020 at 01:09:43PM -0800, H.J. Lu via Gcc-patches wrote: > On Tue, Nov 3, 2020 at 1:00 PM H.J. Lu wrote: > > > > On Tue, Nov 3, 2020 at 12:46 PM Jozef Lawrynowicz > > wrote: > > > > > > On Tue, Nov 03, 2020 at 11:58:04AM -0800, H.J. Lu via Gcc-patches wrote: > > > > On Tue, Nov 3, 2020 at 10:22 AM Jozef Lawrynowicz > > > > wrote: > > > > > > > > > > On Tue, Nov 03, 2020 at 09:57:58AM -0800, H.J. Lu via Gcc-patches > > > > > wrote: > > > > > > On Tue, Nov 3, 2020 at 9:41 AM Jozef Lawrynowicz > > > > > > wrote: > > > > > > > > > > > > > > The attached patch implements TARGET_ASM_MARK_DECL_PRESERVED for > > > > > > > ELF GNU > > > > > > > OSABI targets, so that declarations that have the "used" attribute > > > > > > > applied will be saved from linker garbage collection. > > > > > > > > > > > > > > TARGET_ASM_MARK_DECL_PRESERVED will emit an assembler ".retain" > > > > > > > > > > > > Can you use the "R" flag instead? > > > > > > > > > > > > > > > > For the benefit of this mailing list, I have copied my response from > > > > > the > > > > > Binutils mailing list regarding this. > > > > > The "comm_section" example I gave is actually innacurate, but you can > > > > > see the examples of the variety of sections that would need to be > > > > > handled by doing > > > > > > > > > > $ git grep -A2 "define.*SECTION_ASM_OP" gcc/ | grep "\".*\." > > > > > > > > > > > ... snip ... > > > > > > Secondly, for seamless integration with the "used" attribute, we > > > > > > must be > > > > > > able to to mark the symbol with the used attribute applied as > > > > > > "retained" > > > > > > without changing its section name. For GCC "named" sections, this is > > > > > > straightforward, but for "unnamed" sections it is a giant mess. > > > > > > > > > > > > The section name for a GCC "unnamed" section is not readily > > > > > > available, > > > > > > instead a string which contains the full assembly code to switch to > > > > > > one > > > > > > of these text/data/bss/rodata/comm etc. sections is encoded in the > > > > > > structure. > > > > > > > > > > > > Backends define the assembly code to switch to these sections (some > > > > > > "*ASM_OP*" macro) in a variety of ways. For example, the unnamed > > > > > > section > > > > > > "comm_section", might correspond to a .bss section, or emit a .comm > > > > > > directive. I even looked at trying to parse them to extract what the > > > > > > name of a section will be, but it would be very messy and not > > > > > > robust. > > > > > > > > > > > > Meanwhile, having a .retain directive is a very > > > > > > simmple > > > > > > solution, and keeps the GCC implementation really concise (patch > > > > > > attached). The assembler will know for sure what the section > > > > > > containing > > > > > > the symbol will be, and can apply the SHF_GNU_RETAIN flag directly. > > > > > > > > > > > > > > Please take a look at > > > > > > > > https://gitlab.com/x86-gcc/gcc/-/commits/users/hjl/elf/shf_retain > > > > > > > > which is built in top of > > > > > > > > https://gcc.gnu.org/pipermail/gcc-patches/2020-February/539963.html > > > > > > > > I think SECTION2_RETAIN matches SHF_GNU_RETAIN well. If you > > > > want, you extract my flags2 change and use it for SHF_GNU_RETAIN. > > > > > > In your patch you have to make the assumption that data_section, always > > > corresponds to a section named .data. For just this example, c6x (which > > > supports the GNU ELF OSABI) does not fit the rule: > > > > > > > c6x/elf-common.h:#define DATA_SECTION_ASM_OP > > > > "\t.section\t\".fardata\",\"aw\""
ping [PATCH 0/2] arm: "noinit" and "persistent" attributes
Ping for below
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557184.html
On Tue, Oct 27, 2020 at 11:40:33AM +, Jozef Lawrynowicz wrote:
> This patch series fixes behavior related to the "noinit" attribute, and
> makes the MSP430 "persistent" attribute generic, so it can be used for
> ARM.
> These attributes are related because they are both used to mark
> variables that should not be initialized by the target's runtime
> startup code.
>
> The "noinit" attribute is used for variables that are not initialized
> to any value by the program loader, or the runtime startup code.
> This attribute was made generic for GCC 10, whilst previously it was
> only supported for MSP430.
> There are a couple of issues when using it for arm-eabi:
> - It does not work at -O0.
> The test for it is in the torture directory but only runs at -O2,
> which is why this bug was undetected.
> - It does not work with -fdata-sections.
> Patch 1 fixes these issues.
>
> The "persistent" attribute is used for variables that *are* initialized
> by the program loader, but are not initialized by the runtime startup
> code. "persistent" variables are placed in a non-volatile area of
> memory, which allows their value to "persist" between processor resets.
>
> The "persistent" attribute is already implemented for msp430-elf, but
> patch 2 makes it generic so it can be leveraged by ARM targets. The
> ".persistent" section is pervasive in linker scripts distributed ARM
> devices by manufacturers such as ST and TI.
>
> I've attached a Binutils patch that adds the ".persistent" section to
> the default ARM linker script. I'll apply it alongside this GCC patch.
>
> Side note: There is handling of a ".persistent.bss" section, however
> this is Ada-specific and unrelated to the "noinit" and "persistent"
> attributes. The handling of the "noinit" and "persistent" attributes
> does not interfere with it.
>
> Successfully bootstrapped/regtested x86_64-pc-linux-gnu and regtested
> for arm-none-eabi.
>
> Ok for trunk?
>
> Jozef Lawrynowicz (2):
> Fix "noinit" attribute being ignored for -O0 and -fdata-sections
> Implement the "persistent" attribute
>
> gcc/c-family/c-attribs.c | 146 --
> gcc/cgraph.h | 6 +-
> gcc/cgraphunit.c | 2 +
> gcc/doc/extend.texi | 20 ++-
> gcc/lto-cgraph.c | 2 +
> .../c-c++-common/torture/attr-noinit-1.c | 7 +
> .../c-c++-common/torture/attr-noinit-2.c | 8 +
> .../c-c++-common/torture/attr-noinit-3.c | 11 ++
> .../torture/attr-noinit-invalid.c | 12 ++
> .../torture/attr-noinit-main.inc} | 37 ++---
> .../c-c++-common/torture/attr-persistent-1.c | 8 +
> .../c-c++-common/torture/attr-persistent-2.c | 8 +
> .../c-c++-common/torture/attr-persistent-3.c | 10 ++
> .../torture/attr-persistent-invalid.c | 11 ++
> .../torture/attr-persistent-main.inc | 58 +++
> gcc/testsuite/lib/target-supports.exp | 15 +-
> gcc/tree-core.h | 1 +
> gcc/tree.h| 7 +
> gcc/varasm.c | 30 +++-
> 19 files changed, 325 insertions(+), 74 deletions(-)
> create mode 100644 gcc/testsuite/c-c++-common/torture/attr-noinit-1.c
> create mode 100644 gcc/testsuite/c-c++-common/torture/attr-noinit-2.c
> create mode 100644 gcc/testsuite/c-c++-common/torture/attr-noinit-3.c
> create mode 100644 gcc/testsuite/c-c++-common/torture/attr-noinit-invalid.c
> rename gcc/testsuite/{gcc.c-torture/execute/noinit-attribute.c =>
> c-c++-common/torture/attr-noinit-main.inc} (56%)
> create mode 100644 gcc/testsuite/c-c++-common/torture/attr-persistent-1.c
> create mode 100644 gcc/testsuite/c-c++-common/torture/attr-persistent-2.c
> create mode 100644 gcc/testsuite/c-c++-common/torture/attr-persistent-3.c
> create mode 100644
> gcc/testsuite/c-c++-common/torture/attr-persistent-invalid.c
> create mode 100644
> gcc/testsuite/c-c++-common/torture/attr-persistent-main.inc
>
> --
> 2.28.0
>
>From 965de1985a21ef449d1b1477be566efcf3405f7e Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Mon, 26 Oct 2020 14:11:08 +
Subject: [PATCH 1/2] Fix "noinit" attribute being ignored for -O0 and
-fdata-sections
Variables with the "noinit" attribute are ignored at -O0 because they
are treated like a regular .bss variable and placed in the .bss secti
Re: [PATCH] "used" attribute saves decl from linker garbage collection
On Wed, Nov 04, 2020 at 05:47:28AM -0800, H.J. Lu wrote: > On Tue, Nov 3, 2020 at 2:11 PM H.J. Lu wrote: > > > > On Tue, Nov 3, 2020 at 1:57 PM Jozef Lawrynowicz > > wrote: > > > > > > On Tue, Nov 03, 2020 at 01:09:43PM -0800, H.J. Lu via Gcc-patches wrote: > > > > On Tue, Nov 3, 2020 at 1:00 PM H.J. Lu wrote: > > > > > > > > > > On Tue, Nov 3, 2020 at 12:46 PM Jozef Lawrynowicz > > > > > wrote: > > > > > > > > > > > > On Tue, Nov 03, 2020 at 11:58:04AM -0800, H.J. Lu via Gcc-patches > > > > > > wrote: > > > > > > > On Tue, Nov 3, 2020 at 10:22 AM Jozef Lawrynowicz > > > > > > > wrote: > > > > > > > > > > > > > > > > On Tue, Nov 03, 2020 at 09:57:58AM -0800, H.J. Lu via > > > > > > > > Gcc-patches wrote: > > > > > > > > > On Tue, Nov 3, 2020 at 9:41 AM Jozef Lawrynowicz > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > The attached patch implements > > > > > > > > > > TARGET_ASM_MARK_DECL_PRESERVED for ELF GNU > > > > > > > > > > OSABI targets, so that declarations that have the "used" > > > > > > > > > > attribute > > > > > > > > > > applied will be saved from linker garbage collection. > > > > > > > > > > > > > > > > > > > > TARGET_ASM_MARK_DECL_PRESERVED will emit an assembler > > > > > > > > > > ".retain" > > > > > > > > > > > > > > > > > > Can you use the "R" flag instead? > > > > > > > > > > > > > > > > > > > > > > > > > For the benefit of this mailing list, I have copied my response > > > > > > > > from the > > > > > > > > Binutils mailing list regarding this. > > > > > > > > The "comm_section" example I gave is actually innacurate, but > > > > > > > > you can > > > > > > > > see the examples of the variety of sections that would need to > > > > > > > > be > > > > > > > > handled by doing > > > > > > > > > > > > > > > > $ git grep -A2 "define.*SECTION_ASM_OP" gcc/ | grep "\".*\." > > > > > > > > > > > > > > > > > ... snip ... > > > > > > > > > Secondly, for seamless integration with the "used" attribute, > > > > > > > > > we must be > > > > > > > > > able to to mark the symbol with the used attribute applied as > > > > > > > > > "retained" > > > > > > > > > without changing its section name. For GCC "named" sections, > > > > > > > > > this is > > > > > > > > > straightforward, but for "unnamed" sections it is a giant > > > > > > > > > mess. > > > > > > > > > > > > > > > > > > The section name for a GCC "unnamed" section is not readily > > > > > > > > > available, > > > > > > > > > instead a string which contains the full assembly code to > > > > > > > > > switch to one > > > > > > > > > of these text/data/bss/rodata/comm etc. sections is encoded > > > > > > > > > in the > > > > > > > > > structure. > > > > > > > > > > > > > > > > > > Backends define the assembly code to switch to these sections > > > > > > > > > (some > > > > > > > > > "*ASM_OP*" macro) in a variety of ways. For example, the > > > > > > > > > unnamed section > > > > > > > > > "comm_section", might correspond to a .bss section, or emit a > > > > > > > > > .comm > > > > > > > > > directive. I even looked at trying to parse them to extract > > > > > > > > > what the > > > > > > > > > name of a section will be
Re: [PATCH] "used" attribute saves decl from linker garbage collection
On Wed, Nov 04, 2020 at 03:58:56PM -0800, H.J. Lu wrote: > On Wed, Nov 4, 2020 at 3:00 PM Hans-Peter Nilsson wrote: > > > > On Wed, 4 Nov 2020, H.J. Lu wrote: > > > On Wed, Nov 4, 2020 at 1:56 PM Hans-Peter Nilsson > > > wrote: > > > > On Wed, 4 Nov 2020, H.J. Lu wrote: > > > > > > > > > On Wed, Nov 4, 2020 at 1:03 PM Hans-Peter Nilsson > > > > > wrote: > > > > > > > > > > > > On Wed, 4 Nov 2020, H.J. Lu wrote: > > > > > > > On Wed, Nov 4, 2020 at 10:09 AM Hans-Peter Nilsson > > > > > > > wrote: > > > > > > > > I'm not much more than a random voice, but an assembly directive > > > > > > > > that specifies the symbol (IIUC your .retain directive) to > > > > > > > > > > > > > > But .retain directive DOES NOT adjust symbol attribute. > > > > > > > > I see I missed to point out that I was speaking about the *gcc > > > > symbol* attribute "used". > > > > > > There is no such corresponding symbol attribute in ELF. > > > > I have not missed that, nor that SHF_GNU_RETAIN is so new that > > it's not in binutils master. I have also not missed that gcc > > caters to other object formats too. A common symbol-specific > > directive such as .retain, would be better than messing with > > section attributes, for gcc. > > This is totally irrelevant to SHF_GNU_RETAIN. > > > > > It's cleaner to the compiler if it can pass on to the assembler > > > > the specific symbol that needs to be kept. > > > > > > > > > > SHF_GNU_RETAIN is for section and GCC should place the symbol, > > > which should be kept, in the SHF_GNU_RETAIN section directly, not > > > through .retain directive. > > > > This is where opinions differ. Anyway, this is now repetition; > > I'm done. > > .retain is ill-defined. For example, > > [hjl@gnu-cfl-2 gcc]$ cat /tmp/x.c > static int xyzzy __attribute__((__used__)); > [hjl@gnu-cfl-2 gcc]$ ./xgcc -B./ -S /tmp/x.c -fcommon > [hjl@gnu-cfl-2 gcc]$ cat x.s > .file "x.c" > .text > .retain xyzzy < What does it do? > .local xyzzy > .comm xyzzy,4,4 > .ident "GCC: (GNU) 11.0.0 20201103 (experimental)" > .section .note.GNU-stack,"",@progbits > [hjl@gnu-cfl-2 gcc]$ > > A symbol directive should operate on the symbol table. > With 'R' flag, we got > > .file "x.c" > .text > .section .bss.xyzzy,"awR",@nobits > .align 4 > .type xyzzy, @object > .size xyzzy, 4 > xyzzy: > .zero 4 > .ident "GCC: (GNU) 11.0.0 20201104 (experimental)" > .section .note.GNU-stack,"",@progbits I still think it is very wrong for the "used" attribute to place the symbol in a unique section. The structure of the sections in the object file should be no different whether the "used" attribute was applied to a symbol or not. I will therefore have to make changes to GCC so that we can get the name of "unnamed" sections, and emit a .section directive with the "R" flag set on that section name, in order to avoid using a .retain directive. "used" applied to a function --- Before: TEXT_SECTION_ASM_OP func: After: .section TEXT_SECTION_NAME,"axR",%progbits func: Where TEXT_SECTION_NAME is a new macro which defines the section name corresponding to TEXT_SECTION_ASM_OP. Similar new macros are required for all *SECTION_ASM_OP. Since we can't use the .retain directive, this is the cludge that will be required to robustly support all targets. The alternative is to just infer that the mapping of unnamed sections to section names is always the following: text_section-> .text,"ax",%progbits data_section-> .data,"aw" bss_section -> .bss,"aw",%nobits rodata_section -> .rodata,"a", etc. This section name assumption does not hold for a couple of ELF targets. Also, many targets omit the specification of the flags, leaving that choice to the assembler, instead the compiler will now have to infer what the assembler will do, all because we can't have the .retain directive. .retain makes life very easy for GCC, but I understand your objection from a theoretical point of view. You previously objected to .retain , to apply SHF_GNU_RETAIN to . This does not violate your rule about a directive applying flags to a different type of structure to what is named in the directive. If we can have .retain , then we don't have to make assumptions about section flags in GCC, we can just name the section use in the ASM_OP. Do you still oppose .retain ? Another alternative is to disallow "used" from applying SHF_GNU_RETAIN, unless the symbol is in a named section. Obviously this is pretty gross, but would mean we don't need to handle *SECTION_ASM_OP sections. Thanks, Jozef > > -- > H.J.
Re: [PATCH] "used" attribute saves decl from linker garbage collection
On Thu, Nov 05, 2020 at 06:21:21AM -0500, Hans-Peter Nilsson wrote:
> On Wed, 4 Nov 2020, H.J. Lu wrote:
> > .retain is ill-defined. For example,
> >
> > [hjl@gnu-cfl-2 gcc]$ cat /tmp/x.c
> > static int xyzzy __attribute__((__used__));
> > [hjl@gnu-cfl-2 gcc]$ ./xgcc -B./ -S /tmp/x.c -fcommon
> > [hjl@gnu-cfl-2 gcc]$ cat x.s
> > .file "x.c"
> > .text
> > .retain xyzzy < What does it do?
> > .local xyzzy
> > .comm xyzzy,4,4
> > .ident "GCC: (GNU) 11.0.0 20201103 (experimental)"
> > .section .note.GNU-stack,"",@progbits
> > [hjl@gnu-cfl-2 gcc]$
>
> To answer that question: it's up to the assembler, but for ELF
> and SHF_GNU_RETAIN, it seems obvious it'd tell the assembler to
> set SHF_GNU_RETAIN for the section where the symbol ends up.
> We both know this isn't rocket science with binutils.
Indeed, and my patch handles it trivially:
https://sourceware.org/pipermail/binutils/2020-November/113993.html
+void
+obj_elf_retain (int arg ATTRIBUTE_UNUSED)
snip
+ sym = get_sym_from_input_line_and_check ();
+ symbol_get_obj (sym)->retain = 1;
@@ -2624,6 +2704,9 @@ elf_frob_symbol (symbolS *symp, int *puntp)
}
}
+ if (symbol_get_obj (symp)->retain)
+elf_section_flags (S_GET_SEGMENT (symp)) |= SHF_GNU_RETAIN;
+
/* Double check weak symbols. */
if (S_IS_WEAK (symp))
{
We could check that the symbol named in the .retain directive has
already been defined, however this isn't compatible with GCC
mark_decl_preserved handling, since mark_decl_preserved is called
emitted before the local symbols are defined in the assembly output
file.
GAS should at least validate that the symbol named in the .retain
directive does end up as a symbol though.
Thanks,
Jozef
>
> brgds, H-P
ping x4 [PATCH 0/5] MSP430: Implement macros to describe relative costs of operations
4th ping for below. Patches are attached, OP linked here: https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550542.html Thanks, Jozef On Wed, Oct 14, 2020 at 04:31:30PM +0100, Jozef Lawrynowicz wrote: > 3rd ping for below. > > On Tue, Sep 15, 2020 at 09:30:22PM +0100, Jozef Lawrynowicz wrote: > > Ping x2 for below. > > > > On Fri, Aug 07, 2020 at 12:02:59PM +0100, Jozef Lawrynowicz wrote: > > > Pinging for this series of patches. > > > Attached all patches to this mail with the ammended patch 4 thanks to > > > Segher's review. > > > > > > Thanks, > > > Jozef > > > > > > On Thu, Jul 23, 2020 at 04:43:56PM +0100, Jozef Lawrynowicz wrote: > > > > The following series of patches for MSP430 implement some of the target > > > > macros used to determine the relative costs of operations. > > > > > > > > To give an indication of the overall effect of these changes on > > > > codesize, below are some size statistics collected from all the > > > > executable files from execute.exp that are built at -Os. > > > > There are around 1470 such tests (depending on the configuration). > > > > > > > > The percentage change (((new - old)/old) * 100) in text size is > > > > calculated > > > > for each test and the given metric is applied to that overall set of > > > > data. > > > > > > > > Configuration | Mean (%) | Median (%) | Delta < 0 (count) | Delta > 0 > > > > (count) > > > > - > > > > -mcpu=msp430 | -2.4| -2.7 | 1454 | 17 > > > > -mcpu=msp430x | -2.3| -2.4 | 1460 | 10 > > > > -mlarge | -1.7| -1.9 | 1412 | 37 > > > > > > > > Successfully regtested on trunk for msp430-elf, ok to apply? > > > > > > > > Jozef Lawrynowicz (5): > > > > MSP430: Implement TARGET_MEMORY_MOVE_COST > > > > MSP430: Implement TARGET_RTX_COSTS > > > > MSP430: Add defaulting to the insn length attribute > > > > MSP430: Implement TARGET_INSN_COST > > > > MSP430: Skip index-1.c test > > > > > > > > gcc/config/msp430/msp430-protos.h | 5 +- > > > > gcc/config/msp430/msp430.c| 867 -- > > > > gcc/config/msp430/msp430.h | 13 + > > > > gcc/config/msp430/msp430.md | 439 +++-- > > > > gcc/config/msp430/msp430.opt | 4 + > > > > gcc/config/msp430/predicates.md | 13 + > > > > gcc/testsuite/gcc.c-torture/execute/index-1.c | 2 + > > > > 7 files changed, 1206 insertions(+), 137 deletions(-) > > > > > > > > -- > > > > 2.27.0 > > > > > > >From e260de5a31e661afdfaaf2c8053b574a292d6826 Mon Sep 17 00:00:00 2001 From: Jozef Lawrynowicz Date: Thu, 16 Jul 2020 11:28:11 +0100 Subject: [PATCH 1/5] MSP430: Implement TARGET_MEMORY_MOVE_COST The cycle and size cost of a MOV instruction in different addressing modes can be used to calculate the TARGET_MEMORY_MOVE_COST relative to TARGET_REGISTER_MOVE_COST. gcc/ChangeLog: * config/msp430/msp430.c (struct single_op_cost): New struct. (struct double_op_cost): Likewise. (TARGET_REGISTER_MOVE_COST): Don't define but add comment. (TARGET_MEMORY_MOVE_COST): Define to... (msp430_memory_move_cost): New function. (BRANCH_COST): Don't define but add comment. --- gcc/config/msp430/msp430.c | 131 + 1 file changed, 131 insertions(+) diff --git a/gcc/config/msp430/msp430.c b/gcc/config/msp430/msp430.c index c2b24974364..9e739233fa0 100644 --- a/gcc/config/msp430/msp430.c +++ b/gcc/config/msp430/msp430.c @@ -1043,6 +1043,137 @@ msp430_legitimate_constant (machine_mode mode, rtx x) } +/* Describing Relative Costs of Operations + To model the cost of an instruction, use the number of cycles when + optimizing for speed, and the number of words when optimizing for size. + The cheapest instruction will execute in one cycle and cost one word. + The cycle and size costs correspond to 430 ISA instructions, not 430X + instructions or 430X "address" instructions. The relative costs of 430X + instructions is accurately modeled with the 430 costs. The relative costs + of some "address" instructions can differ, but these are not yet handled. + Adding support for this could improve
Re: ping x2 [PATCH 0/5] MSP430: Implement macros to describe relative costs of operations
On Fri, Nov 06, 2020 at 01:53:19PM -0700, Jeff Law via Gcc-patches wrote: > > On 9/15/20 2:30 PM, Jozef Lawrynowicz wrote: > > Ping x2 for below. > > > > On Fri, Aug 07, 2020 at 12:02:59PM +0100, Jozef Lawrynowicz wrote: > >> Pinging for this series of patches. > >> Attached all patches to this mail with the ammended patch 4 thanks to > >> Segher's review. > >> > >> Thanks, > >> Jozef > >> > >> On Thu, Jul 23, 2020 at 04:43:56PM +0100, Jozef Lawrynowicz wrote: > >>> The following series of patches for MSP430 implement some of the target > >>> macros used to determine the relative costs of operations. > >>> > >>> To give an indication of the overall effect of these changes on > >>> codesize, below are some size statistics collected from all the > >>> executable files from execute.exp that are built at -Os. > >>> There are around 1470 such tests (depending on the configuration). > >>> > >>> The percentage change (((new - old)/old) * 100) in text size is calculated > >>> for each test and the given metric is applied to that overall set of data. > >>> > >>> Configuration | Mean (%) | Median (%) | Delta < 0 (count) | Delta > 0 > >>> (count) > >>> - > >>> -mcpu=msp430 | -2.4| -2.7 | 1454 | 17 > >>> -mcpu=msp430x | -2.3| -2.4 | 1460 | 10 > >>> -mlarge | -1.7| -1.9 | 1412 | 37 > >>> > >>> Successfully regtested on trunk for msp430-elf, ok to apply? > >>> > >>> Jozef Lawrynowicz (5): > >>> MSP430: Implement TARGET_MEMORY_MOVE_COST > >>> MSP430: Implement TARGET_RTX_COSTS > >>> MSP430: Add defaulting to the insn length attribute > >>> MSP430: Implement TARGET_INSN_COST > >>> MSP430: Skip index-1.c test > >>> > >>> gcc/config/msp430/msp430-protos.h | 5 +- > >>> gcc/config/msp430/msp430.c| 867 -- > >>> gcc/config/msp430/msp430.h| 13 + > >>> gcc/config/msp430/msp430.md | 439 +++-- > >>> gcc/config/msp430/msp430.opt | 4 + > >>> gcc/config/msp430/predicates.md | 13 + > >>> gcc/testsuite/gcc.c-torture/execute/index-1.c | 2 + > >>> 7 files changed, 1206 insertions(+), 137 deletions(-) > > [ ... ] > > So it's a series of 5 patches. They LGTM.   And if there's minor > updates needed to address issues found once they're on the trunk, the > consider those updates pre-approved. Spooky, I pinged these patches the minute before you replied to this one. > > Note that defining LOGICAL_OP_NON_SHORT_CIRCUIT and BRANCH_COST impact > gimple code generation. I'm a bit surprised there wasn't more fallout > in the existing tests. IIRC, when I tried messing with LOGICAL_OP_NON_SHORT_CIRCUIT and BRANCH_COST before the full costs were implemented, they never had any effect. I'm going to hand wave here and say that whatever behavior these macros were affecting before the costs were implemented, was actually behaving as it should. Then with the full costs implemented, I had to tweak them to get back to that optimal state. Also, the only conditional instructions available for MSP430 are cbranch, i.e. there is never a choice between a cbranch and a cstore. I was surprised BRANCH_COST had any effect, but after looking at output assembly, it appeared that it did affect the number of cbranch insns emitted, vs just other insns to move data about. The changes did fix these optimization tests: gcc.dg/tree-ssa/reassoc-33.c scan-tree-dump-times reassoc1 "Optimizing range tests" 3 gcc.dg/tree-ssa/reassoc-34.c scan-tree-dump-times reassoc1 "Optimizing range tests" 1 gcc.dg/tree-ssa/reassoc-35.c scan-tree-dump-times reassoc1 "Optimizing range tests" 1 gcc.dg/tree-ssa/reassoc-36.c scan-tree-dump-times reassoc1 "Optimizing range tests" 1 Thanks for the review, I'll watch for fallout after installing on trunk. Jozef > > jeff > >
Re: [PATCH] c++: Tweaks for value_dependent_expression_p.
On Fri, Oct 30, 2020 at 02:36:00AM +, Marek Polacek via Gcc-patches wrote:
> We may not call value_dependent_expression_p on expressions that are
> not potential constant expressions, otherwise value_d could crash,
> as I saw recently (in C++98). So beef up the checking in i_d_e_p.
>
> This revealed a curious issue: when we have __PRETTY_FUNCTION__ in
> a template function, we set its DECL_VALUE_EXPR to error_mark_node
> (cp_make_fname_decl), so potential_c_e returns false when it gets it,
> but value_dependent_expression_p handles it specially and says true.
> This broke lambda-generic-pretty1.C. So take care of that.
>
> And then also tweak uses_template_parms.
>
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
Hi,
This breaks the GCC build for msp430-elf. The large memory model
(-mlarge) uses __int20 pointers.
In file included from
/home/jozef/msp430/gcc/build-msp430/msp430-elf/large/libstdc++-v3/include/sstream:38,
from
../../../../../../libstdc++-v3/src/c++20/sstream-inst.cc:30:
/home/jozef/msp430/gcc/build-msp430/msp430-elf/large/libstdc++-v3/include/istream:
In function 'std::basic_istream<_CharT, _Traits>&
std::operator>>(std::basic_istream<_CharT, _Traits>&, _CharT (&)[_Num])':
/home/jozef/msp430/gcc/build-msp430/msp430-elf/large/libstdc++-v3/include/istream:840:26:
error: non-constant condition for static assertion
840 | static_assert(_Num <=
__gnu_cxx::__numeric_traits::__max);
|
~^
/home/jozef/msp430/gcc/build-msp430/msp430-elf/large/libstdc++-v3/include/istream:840:26:
error: the value of '__gnu_cxx::__numeric_traits_integer<__int20>::__max' is
not usable in a constant expression
In file included from
/home/jozef/msp430/gcc/build-msp430/msp430-elf/large/libstdc++-v3/include/bits/stl_algobase.h:63,
from
/home/jozef/msp430/gcc/build-msp430/msp430-elf/large/libstdc++-v3/include/bits/char_traits.h:39,
from
/home/jozef/msp430/gcc/build-msp430/msp430-elf/large/libstdc++-v3/include/ios:40,
from
/home/jozef/msp430/gcc/build-msp430/msp430-elf/large/libstdc++-v3/include/istream:38,
from
/home/jozef/msp430/gcc/build-msp430/msp430-elf/large/libstdc++-v3/include/sstream:38,
from
../../../../../../libstdc++-v3/src/c++20/sstream-inst.cc:30:
/home/jozef/msp430/gcc/build-msp430/msp430-elf/large/libstdc++-v3/include/ext/numeric_traits.h:78:27:
note: '__gnu_cxx::__numeric_traits_integer<__int20>::__max' was not
initialized with a constant expression
78 | static const _Value __max = __glibcxx_max(_Value);
| ^
make[9]: *** [Makefile:550: sstream-inst.lo] Error 1
>
> gcc/cp/ChangeLog:
>
> * constexpr.c (potential_constant_expression_1): Treat
> __PRETTY_FUNCTION__ inside a template function as
> potentially-constant.
> * pt.c (uses_template_parms): Call
> instantiation_dependent_expression_p instead of
> value_dependent_expression_p.
> (instantiation_dependent_expression_p): Check
> potential_constant_expression before calling
> value_dependent_expression_p.
> ---
> gcc/cp/constexpr.c | 5 +
> gcc/cp/pt.c| 5 +++--
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
> index b46824f128d..c257dfcb2e6 100644
> --- a/gcc/cp/constexpr.c
> +++ b/gcc/cp/constexpr.c
> @@ -7716,6 +7716,11 @@ potential_constant_expression_1 (tree t, bool
> want_rval, bool strict, bool now,
> }
> return false;
> }
> + /* Treat __PRETTY_FUNCTION__ inside a template function as
> + potentially-constant. */
> + else if (DECL_PRETTY_FUNCTION_P (t)
> +&& DECL_VALUE_EXPR (t) == error_mark_node)
> + return true;
> return RECUR (DECL_VALUE_EXPR (t), rval);
> }
>if (want_rval
> diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
> index b569644514c..c419fb470ee 100644
> --- a/gcc/cp/pt.c
> +++ b/gcc/cp/pt.c
> @@ -10755,7 +10755,7 @@ uses_template_parms (tree t)
>else if (t == error_mark_node)
> dependent_p = false;
>else
> -dependent_p = value_dependent_expression_p (t);
> +dependent_p = instantiation_dependent_expression_p (t);
>
>processing_template_decl = saved_processing_template_decl;
>
> @@ -27293,7 +27293,8 @@ bool
> instantiation_dependent_expression_p (tree expression)
> {
>return (instantiation_dependent_uneval_expression_p (expression)
> - || value_dependent_expression_p (expression));
> + || (potential_constant_expression (expression)
> + && value_dependent_expression_p (expression)));
> }
>
> /* Like type_dependent_expression_p, but it also works while not processing
>
> base-commit: 4f0606fe4bbf1346f83dd4d0c9060c6b46672a7d
> --
> 2.28.0
Re: [PATCH] "used" attribute saves decl from linker garbage collection
On Fri, Nov 06, 2020 at 04:39:33PM -0800, H.J. Lu via Gcc-patches wrote:
> On Fri, Nov 6, 2020 at 4:17 PM Jeff Law wrote:
> >
> >
> > On 11/6/20 5:13 PM, H.J. Lu wrote:
> > > On Fri, Nov 6, 2020 at 4:01 PM Jeff Law wrote:
> > >>
> > >> On 11/6/20 4:45 PM, H.J. Lu wrote:
> > >>> On Fri, Nov 6, 2020 at 3:37 PM Jeff Law wrote:
> > >>>> On 11/6/20 4:29 PM, H.J. Lu wrote:
> > >>>>> On Fri, Nov 6, 2020 at 3:22 PM Jeff Law wrote:
> > >>>>>> On 11/5/20 7:34 AM, H.J. Lu via Gcc-patches wrote:
> > >>>>>>> On Thu, Nov 5, 2020 at 3:37 AM Jozef Lawrynowicz
> > >>>>>>> wrote:
> > >>>>>>>> On Thu, Nov 05, 2020 at 06:21:21AM -0500, Hans-Peter Nilsson wrote:
> > >>>>>>>>> On Wed, 4 Nov 2020, H.J. Lu wrote:
> > >>>>>>>>>> .retain is ill-defined. For example,
> > >>>>>>>>>>
> > >>>>>>>>>> [hjl@gnu-cfl-2 gcc]$ cat /tmp/x.c
> > >>>>>>>>>> static int xyzzy __attribute__((__used__));
> > >>>>>>>>>> [hjl@gnu-cfl-2 gcc]$ ./xgcc -B./ -S /tmp/x.c -fcommon
> > >>>>>>>>>> [hjl@gnu-cfl-2 gcc]$ cat x.s
> > >>>>>>>>>> .file "x.c"
> > >>>>>>>>>> .text
> > >>>>>>>>>> .retain xyzzy <<<<<<<<< What does it do?
> > >>>>>>>>>> .local xyzzy
> > >>>>>>>>>> .comm xyzzy,4,4
> > >>>>>>>>>> .ident "GCC: (GNU) 11.0.0 20201103 (experimental)"
> > >>>>>>>>>> .section .note.GNU-stack,"",@progbits
> > >>>>>>>>>> [hjl@gnu-cfl-2 gcc]$
> > >>>>>>>>> To answer that question: it's up to the assembler, but for ELF
> > >>>>>>>>> and SHF_GNU_RETAIN, it seems obvious it'd tell the assembler to
> > >>>>>>>>> set SHF_GNU_RETAIN for the section where the symbol ends up.
> > >>>>>>>>> We both know this isn't rocket science with binutils.
> > >>>>>>>> Indeed, and my patch handles it trivially:
> > >>>>>>>> https://sourceware.org/pipermail/binutils/2020-November/113993.html
> > >>>>>>>>
> > >>>>>>>> +void
> > >>>>>>>> +obj_elf_retain (int arg ATTRIBUTE_UNUSED)
> > >>>>>>>> snip
> > >>>>>>>> + sym = get_sym_from_input_line_and_check ();
> > >>>>>>>> + symbol_get_obj (sym)->retain = 1;
> > >>>>>>>>
> > >>>>>>>> @@ -2624,6 +2704,9 @@ elf_frob_symbol (symbolS *symp, int *puntp)
> > >>>>>>>> }
> > >>>>>>>>}
> > >>>>>>>>
> > >>>>>>>> + if (symbol_get_obj (symp)->retain)
> > >>>>>>>> +elf_section_flags (S_GET_SEGMENT (symp)) |= SHF_GNU_RETAIN;
> > >>>>>>>> +
> > >>>>>>>> /* Double check weak symbols. */
> > >>>>>>>> if (S_IS_WEAK (symp))
> > >>>>>>>>{
> > >>>>>>>>
> > >>>>>>>> We could check that the symbol named in the .retain directive has
> > >>>>>>>> already been defined, however this isn't compatible with GCC
> > >>>>>>>> mark_decl_preserved handling, since mark_decl_preserved is called
> > >>>>>>>> emitted before the local symbols are defined in the assembly output
> > >>>>>>>> file.
> > >>>>>>>>
> > >>>>>>>> GAS should at least validate that the symbol named in the .retain
> > >>>>>>>> directive does end up as a symbol though.
> > >>>>>>>>
> > >>>>>>> Don't add .retain.
> > >>>>>> Why? I don't see why you find it so objectionable.
> > >>>>>>
> > >>>>> An ELF symbol directive should operate
Re: [PATCH] "used" attribute saves decl from linker garbage collection
On Mon, Nov 09, 2020 at 10:36:07AM -0800, H.J. Lu via Gcc-patches wrote:
> On Mon, Nov 9, 2020 at 9:41 AM Jozef Lawrynowicz
> wrote:
> >
> > On Fri, Nov 06, 2020 at 04:39:33PM -0800, H.J. Lu via Gcc-patches wrote:
> > > On Fri, Nov 6, 2020 at 4:17 PM Jeff Law wrote:
> > > >
> > > >
> > > > On 11/6/20 5:13 PM, H.J. Lu wrote:
> > > > > On Fri, Nov 6, 2020 at 4:01 PM Jeff Law wrote:
> > > > >>
> > > > >> On 11/6/20 4:45 PM, H.J. Lu wrote:
> > > > >>> On Fri, Nov 6, 2020 at 3:37 PM Jeff Law wrote:
> > > > >>>> On 11/6/20 4:29 PM, H.J. Lu wrote:
> > > > >>>>> On Fri, Nov 6, 2020 at 3:22 PM Jeff Law wrote:
> > > > >>>>>> On 11/5/20 7:34 AM, H.J. Lu via Gcc-patches wrote:
> > > > >>>>>>> On Thu, Nov 5, 2020 at 3:37 AM Jozef Lawrynowicz
> > > > >>>>>>> wrote:
> > > > >>>>>>>> On Thu, Nov 05, 2020 at 06:21:21AM -0500, Hans-Peter Nilsson
> > > > >>>>>>>> wrote:
> > > > >>>>>>>>> On Wed, 4 Nov 2020, H.J. Lu wrote:
> > > > >>>>>>>>>> .retain is ill-defined. For example,
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> [hjl@gnu-cfl-2 gcc]$ cat /tmp/x.c
> > > > >>>>>>>>>> static int xyzzy __attribute__((__used__));
> > > > >>>>>>>>>> [hjl@gnu-cfl-2 gcc]$ ./xgcc -B./ -S /tmp/x.c -fcommon
> > > > >>>>>>>>>> [hjl@gnu-cfl-2 gcc]$ cat x.s
> > > > >>>>>>>>>> .file "x.c"
> > > > >>>>>>>>>> .text
> > > > >>>>>>>>>> .retain xyzzy <<<<<<<<< What does it do?
> > > > >>>>>>>>>> .local xyzzy
> > > > >>>>>>>>>> .comm xyzzy,4,4
> > > > >>>>>>>>>> .ident "GCC: (GNU) 11.0.0 20201103 (experimental)"
> > > > >>>>>>>>>> .section .note.GNU-stack,"",@progbits
> > > > >>>>>>>>>> [hjl@gnu-cfl-2 gcc]$
> > > > >>>>>>>>> To answer that question: it's up to the assembler, but for ELF
> > > > >>>>>>>>> and SHF_GNU_RETAIN, it seems obvious it'd tell the assembler
> > > > >>>>>>>>> to
> > > > >>>>>>>>> set SHF_GNU_RETAIN for the section where the symbol ends up.
> > > > >>>>>>>>> We both know this isn't rocket science with binutils.
> > > > >>>>>>>> Indeed, and my patch handles it trivially:
> > > > >>>>>>>> https://sourceware.org/pipermail/binutils/2020-November/113993.html
> > > > >>>>>>>>
> > > > >>>>>>>> +void
> > > > >>>>>>>> +obj_elf_retain (int arg ATTRIBUTE_UNUSED)
> > > > >>>>>>>> snip
> > > > >>>>>>>> + sym = get_sym_from_input_line_and_check ();
> > > > >>>>>>>> + symbol_get_obj (sym)->retain = 1;
> > > > >>>>>>>>
> > > > >>>>>>>> @@ -2624,6 +2704,9 @@ elf_frob_symbol (symbolS *symp, int
> > > > >>>>>>>> *puntp)
> > > > >>>>>>>> }
> > > > >>>>>>>>}
> > > > >>>>>>>>
> > > > >>>>>>>> + if (symbol_get_obj (symp)->retain)
> > > > >>>>>>>> +elf_section_flags (S_GET_SEGMENT (symp)) |=
> > > > >>>>>>>> SHF_GNU_RETAIN;
> > > > >>>>>>>> +
> > > > >>>>>>>> /* Double check weak symbols. */
> > > > >>>>>>>> if (S_IS_WEAK (symp))
> > > > >>>>>>>>{
> > > > >>>>>>>>
> > > > >>>>>>>> We could check that the symbol named in the .retain directive
Re: [PATCH] "used" attribute saves decl from linker garbage collection
On Mon, Nov 09, 2020 at 12:31:09PM -0800, H.J. Lu via Gcc-patches wrote: > On Mon, Nov 9, 2020 at 11:56 AM Jozef Lawrynowicz > wrote: > > > > On Mon, Nov 09, 2020 at 10:36:07AM -0800, H.J. Lu via Gcc-patches wrote: > > > On Mon, Nov 9, 2020 at 9:41 AM Jozef Lawrynowicz > > > wrote: > > > > > > > > On Fri, Nov 06, 2020 at 04:39:33PM -0800, H.J. Lu via Gcc-patches wrote: > > > > > On Fri, Nov 6, 2020 at 4:17 PM Jeff Law wrote: > > > > > > > > > > > > > > > > > > On 11/6/20 5:13 PM, H.J. Lu wrote: > > > > > > > On Fri, Nov 6, 2020 at 4:01 PM Jeff Law wrote: > > > > > > >> > > > > > > >> On 11/6/20 4:45 PM, H.J. Lu wrote: > > > > > > >>> On Fri, Nov 6, 2020 at 3:37 PM Jeff Law wrote: > > > > > > >>>> On 11/6/20 4:29 PM, H.J. Lu wrote: > > > > > > >>>>> On Fri, Nov 6, 2020 at 3:22 PM Jeff Law > > > > > > >>>>> wrote: > > > > > > >>>>>> On 11/5/20 7:34 AM, H.J. Lu via Gcc-patches wrote: > > > > > > >>>>>>> On Thu, Nov 5, 2020 at 3:37 AM Jozef Lawrynowicz > > > > > > >>>>>>> wrote: > > > > > > >>>>>>>> On Thu, Nov 05, 2020 at 06:21:21AM -0500, Hans-Peter > > > > > > >>>>>>>> Nilsson wrote: > > > > > > >>>>>>>>> On Wed, 4 Nov 2020, H.J. Lu wrote: > > > > > > >>>>>>>>>> .retain is ill-defined. For example, > > > > > > >>>>>>>>>> > > > > > > >>>>>>>>>> [hjl@gnu-cfl-2 gcc]$ cat /tmp/x.c > > > > > > >>>>>>>>>> static int xyzzy __attribute__((__used__)); > > > > > > >>>>>>>>>> [hjl@gnu-cfl-2 gcc]$ ./xgcc -B./ -S /tmp/x.c -fcommon > > > > > > >>>>>>>>>> [hjl@gnu-cfl-2 gcc]$ cat x.s > > > > > > >>>>>>>>>> .file "x.c" > > > > > > >>>>>>>>>> .text > > > > > > >>>>>>>>>> .retain xyzzy <<<<<<<<< What does it do? > > > > > > >>>>>>>>>> .local xyzzy > > > > > > >>>>>>>>>> .comm xyzzy,4,4 > > > > > > >>>>>>>>>> .ident "GCC: (GNU) 11.0.0 20201103 (experimental)" > > > > > > >>>>>>>>>> .section .note.GNU-stack,"",@progbits > > > > > > >>>>>>>>>> [hjl@gnu-cfl-2 gcc]$ > > > > > > >>>>>>>>> To answer that question: it's up to the assembler, but > > > > > > >>>>>>>>> for ELF > > > > > > >>>>>>>>> and SHF_GNU_RETAIN, it seems obvious it'd tell the > > > > > > >>>>>>>>> assembler to > > > > > > >>>>>>>>> set SHF_GNU_RETAIN for the section where the symbol ends > > > > > > >>>>>>>>> up. > > > > > > >>>>>>>>> We both know this isn't rocket science with binutils. > > > > > > >>>>>>>> Indeed, and my patch handles it trivially: > > > > > > >>>>>>>> https://sourceware.org/pipermail/binutils/2020-November/113993.html > > > > > > >>>>>>>> > > > > > > >>>>>>>> +void > > > > > > >>>>>>>> +obj_elf_retain (int arg ATTRIBUTE_UNUSED) > > > > > > >>>>>>>> snip > > > > > > >>>>>>>> + sym = get_sym_from_input_line_and_check (); > > > > > > >>>>>>>> + symbol_get_obj (sym)->retain = 1; > > > > > > >>>>>>>> > > > > > > >>>>>>>> @@ -2624,6 +2704,9 @@ elf_frob_symbol (symbolS *symp, > > > > > > >>>>>>>> int *puntp) > > > > > > >>>>>>
ping x2 [PATCH 0/2] "noinit" and "persistent" attributes
ping x2 for below
On Wed, Nov 04, 2020 at 01:03:33PM +, Jozef Lawrynowicz wrote:
> Ping for below
> https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557184.html
>
> On Tue, Oct 27, 2020 at 11:40:33AM +, Jozef Lawrynowicz wrote:
> > This patch series fixes behavior related to the "noinit" attribute, and
> > makes the MSP430 "persistent" attribute generic, so it can be used for
> > ARM.
> > These attributes are related because they are both used to mark
> > variables that should not be initialized by the target's runtime
> > startup code.
> >
> > The "noinit" attribute is used for variables that are not initialized
> > to any value by the program loader, or the runtime startup code.
> > This attribute was made generic for GCC 10, whilst previously it was
> > only supported for MSP430.
> > There are a couple of issues when using it for arm-eabi:
> > - It does not work at -O0.
> > The test for it is in the torture directory but only runs at -O2,
> > which is why this bug was undetected.
> > - It does not work with -fdata-sections.
> > Patch 1 fixes these issues.
> >
> > The "persistent" attribute is used for variables that *are* initialized
> > by the program loader, but are not initialized by the runtime startup
> > code. "persistent" variables are placed in a non-volatile area of
> > memory, which allows their value to "persist" between processor resets.
> >
> > The "persistent" attribute is already implemented for msp430-elf, but
> > patch 2 makes it generic so it can be leveraged by ARM targets. The
> > ".persistent" section is pervasive in linker scripts distributed ARM
> > devices by manufacturers such as ST and TI.
> >
> > I've attached a Binutils patch that adds the ".persistent" section to
> > the default ARM linker script. I'll apply it alongside this GCC patch.
> >
> > Side note: There is handling of a ".persistent.bss" section, however
> > this is Ada-specific and unrelated to the "noinit" and "persistent"
> > attributes. The handling of the "noinit" and "persistent" attributes
> > does not interfere with it.
> >
> > Successfully bootstrapped/regtested x86_64-pc-linux-gnu and regtested
> > for arm-none-eabi.
> >
> > Ok for trunk?
> >
> > Jozef Lawrynowicz (2):
> > Fix "noinit" attribute being ignored for -O0 and -fdata-sections
> > Implement the "persistent" attribute
> >
> > gcc/c-family/c-attribs.c | 146 --
> > gcc/cgraph.h | 6 +-
> > gcc/cgraphunit.c | 2 +
> > gcc/doc/extend.texi | 20 ++-
> > gcc/lto-cgraph.c | 2 +
> > .../c-c++-common/torture/attr-noinit-1.c | 7 +
> > .../c-c++-common/torture/attr-noinit-2.c | 8 +
> > .../c-c++-common/torture/attr-noinit-3.c | 11 ++
> > .../torture/attr-noinit-invalid.c | 12 ++
> > .../torture/attr-noinit-main.inc} | 37 ++---
> > .../c-c++-common/torture/attr-persistent-1.c | 8 +
> > .../c-c++-common/torture/attr-persistent-2.c | 8 +
> > .../c-c++-common/torture/attr-persistent-3.c | 10 ++
> > .../torture/attr-persistent-invalid.c | 11 ++
> > .../torture/attr-persistent-main.inc | 58 +++
> > gcc/testsuite/lib/target-supports.exp | 15 +-
> > gcc/tree-core.h | 1 +
> > gcc/tree.h| 7 +
> > gcc/varasm.c | 30 +++-
> > 19 files changed, 325 insertions(+), 74 deletions(-)
> > create mode 100644 gcc/testsuite/c-c++-common/torture/attr-noinit-1.c
> > create mode 100644 gcc/testsuite/c-c++-common/torture/attr-noinit-2.c
> > create mode 100644 gcc/testsuite/c-c++-common/torture/attr-noinit-3.c
> > create mode 100644 gcc/testsuite/c-c++-common/torture/attr-noinit-invalid.c
> > rename gcc/testsuite/{gcc.c-torture/execute/noinit-attribute.c =>
> > c-c++-common/torture/attr-noinit-main.inc} (56%)
> > create mode 100644 gcc/testsuite/c-c++-common/torture/attr-persistent-1.c
> > create mode 100644 gcc/testsuite/c-c++-common/torture/attr-persistent-2.c
> > create mode 100644 gcc/testsuite/c-c++-common/torture/attr-persistent-3.c
> > create mode 100644
> > gcc/testsuite/c-c++-common/torture/attr-persistent-invalid.c
> >
Re: [PATCH] Use SHF_GNU_RETAIN to preserve symbol definitions
On Thu, Nov 12, 2020 at 02:41:52PM -0800, H.J. Lu wrote:
> diff --git a/gcc/varasm.c b/gcc/varasm.c
> index 435c7b348a5..c48ef9692ee 100644
> --- a/gcc/varasm.c
> +++ b/gcc/varasm.c
> @@ -289,6 +289,10 @@ get_section (const char *name, unsigned int flags, tree
> decl,
>slot = section_htab->find_slot_with_hash (name, htab_hash_string (name),
> INSERT);
>flags |= SECTION_NAMED;
> +#if HAVE_GAS_SHF_GNU_RETAIN
> + if (decl != nullptr && DECL_PRESERVE_P (decl))
Minor nit, but I think this should be "decl != NULL_TREE".
We should also test that "used" with the "section" attribute applies the
"R" flag. Please apply the attached patch if this gets approved. These
new tests pass with arm-none-eabi and x86_64-pc-linux-gnu.
Thanks,
Jozef
commit cf8e26deb43d13268ab6ee231995aecbf41ba3a3
Author: Jozef Lawrynowicz
Date: Fri Nov 13 11:07:14 2020 +
Test "used" attribute in conjunction "section" attribute
diff --git a/gcc/testsuite/gcc.c-torture/compile/attr-used-retain-1.c
b/gcc/testsuite/gcc.c-torture/compile/attr-used-retain-1.c
index b7763af11e4..5f6cbca6e33 100644
--- a/gcc/testsuite/gcc.c-torture/compile/attr-used-retain-1.c
+++ b/gcc/testsuite/gcc.c-torture/compile/attr-used-retain-1.c
@@ -4,6 +4,7 @@
/* { dg-final { scan-assembler ".bss.*,\"awR\"" } } */
/* { dg-final { scan-assembler ".data.*,\"awR\"" } } */
/* { dg-final { scan-assembler ".rodata.*,\"aR\"" } } */
+/* { dg-final { scan-assembler ".data.used_foo_sec,\"awR\"" } } */
void __attribute__((used)) used_fn (void) { }
void unused_fn (void) { }
@@ -30,3 +31,5 @@ int __attribute__((used)) used_data2 = 1;
const int __attribute__((used)) used_rodata2 = 2;
int __attribute__((used)) used_comm2;
static int __attribute__((used)) used_lcomm2;
+
+int __attribute__((used,section(".data.used_foo_sec"))) used_foo = 2;
diff --git a/gcc/testsuite/gcc.c-torture/compile/attr-used-retain-2.c
b/gcc/testsuite/gcc.c-torture/compile/attr-used-retain-2.c
index e3b3cf184f8..be5f3917ac8 100644
--- a/gcc/testsuite/gcc.c-torture/compile/attr-used-retain-2.c
+++ b/gcc/testsuite/gcc.c-torture/compile/attr-used-retain-2.c
@@ -10,6 +10,7 @@
/* { dg-final { scan-assembler ".rodata.used_rodata2,\"aR\"" } } */
/* { dg-final { scan-assembler ".bss.used_lcomm,\"awR\"" { target arm-*-* } }
} */
/* { dg-final { scan-assembler ".bss.used_lcomm2,\"awR\"" { target arm-*-* } }
} */
+/* { dg-final { scan-assembler ".data.used_foo_sec,\"awR\"" } } */
/* { dg-options "-ffunction-sections -fdata-sections" } */
#include "attr-used-retain-1.c"
[PATCH 0/2] Improve MSP430 hardware multiply support
The attached patch series improves MSP430 hardware multiply support, by
improving code generation when setting up the 16-bit and 32-bit hardware
multiply functions, and adding a 64-bit hardware multiply library
function for devices that have a 32-bit hardware multiplier.
Successfully regtested GCC and G++ testsuites for:
msp430-sim
msp430-sim/-mcpu=msp430
msp430-sim/-mhwmult=f5series
msp430-sim/-mhwmult=f5series/-mlarge/-mdata-region=either/-mcode-region=either
msp430-sim/-mlarge
msp430-sim/-mlarge/-mdata-region=either/-mcode-region=either
Additionally regtested GCC execute.exp for:
msp430-sim/-mhwmult=16bit
msp430-sim/-mhwmult=32bit
msp430-sim/-mhwmult=f5series
msp430-sim/-mhwmult=none
msp430-sim/-mlarge/-mcode-region=either/-mdata-region=either/-mhwmult=16bit
msp430-sim/-mlarge/-mcode-region=either/-mdata-region=either/-mhwmult=32bit
msp430-sim/-mlarge/-mcode-region=either/-mdata-region=either/-mhwmult=f5series
msp430-sim/-mlarge/-mcode-region=either/-mdata-region=either/-mhwmult=none
Ok for trunk?
Jozef Lawrynowicz (2):
MSP430: Add mulhi, mulsi and {u,}mulsidi3 expanders
MSP430: Add 64-bit hardware multiply support
gcc/config/msp430/msp430.md | 61 ++--
libgcc/config/msp430/lib2hw_mul.S | 77 +--
libgcc/config/msp430/lib2mul.c| 52 +
libgcc/config/msp430/t-msp430 | 5 ++
4 files changed, 186 insertions(+), 9 deletions(-)
--
2.29.2
[PATCH 1/2] MSP430: Add mulhi, mulsi and {u,}mulsidi3 expanders
GCC generates better code when multiplication operations, which require
library functions to perform, are caught in early in RTL, rather than
leaving the operation to be mapped to a library function later on.
When there is hardware multiply support, it is more efficient to perform
widening multiplication using the hardware multiplier instead of letting
GCC widen the arguments before calling the multiplication routine in the
wider mode.
Successfully regtested GCC and G++ testsuites for:
msp430-sim
msp430-sim/-mcpu=msp430
msp430-sim/-mhwmult=f5series
msp430-sim/-mhwmult=f5series/-mlarge/-mdata-region=either/-mcode-region=either
msp430-sim/-mlarge
msp430-sim/-mlarge/-mdata-region=either/-mcode-region=either
Additionally regtested GCC execute.exp for:
msp430-sim/-mhwmult=16bit
msp430-sim/-mhwmult=32bit
msp430-sim/-mhwmult=f5series
msp430-sim/-mhwmult=none
msp430-sim/-mlarge/-mcode-region=either/-mdata-region=either/-mhwmult=16bit
msp430-sim/-mlarge/-mcode-region=either/-mdata-region=either/-mhwmult=32bit
msp430-sim/-mlarge/-mcode-region=either/-mdata-region=either/-mhwmult=f5series
msp430-sim/-mlarge/-mcode-region=either/-mdata-region=either/-mhwmult=none
Ok for trunk?
>From 2f9bbb5dde866627c0dc321ec102ba3ef73d591c Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Sun, 15 Nov 2020 21:03:10 +
Subject: [PATCH 1/2] MSP430: Add mulhi, mulsi and {u,}mulsidi3 expanders
GCC generates better code when multiplication operations, which require
library functions to perform, are caught in early in RTL, rather than
leaving the operation to be mapped to a library function later on.
When there is hardware multiply support, it is more efficient to perform
widening multiplication using the hardware multiplier instead of letting
GCC widen the arguments before calling the multiplication routine in the
wider mode.
gcc/ChangeLog:
* config/msp430/msp430.md (mulhi3): New.
(mulsi3): New.
(mulsidi3): Rename to *mulsidi3_inline.
(umulsidi3): Rename to *umulsidi3_inline.
(mulsidi3): New define_expand.
(umulsidi3): New define_expand.
---
gcc/config/msp430/msp430.md | 61 ++---
1 file changed, 56 insertions(+), 5 deletions(-)
diff --git a/gcc/config/msp430/msp430.md b/gcc/config/msp430/msp430.md
index 65e951774b1..714cd84a095 100644
--- a/gcc/config/msp430/msp430.md
+++ b/gcc/config/msp430/msp430.md
@@ -1724,6 +1724,28 @@ (define_insn "delay_cycles_1"
[(set_attr "length" "2")]
)
+(define_expand "mulhi3"
+ [(set (match_operand:HI 0 "register_operand" "=r")
+ (mult:HI (match_operand:HI 1 "register_operand" "%0")
+(match_operand:HI 2 "register_operand" "r")))]
+ "msp430_has_hwmult ()"
+ {
+ msp430_expand_helper (operands, "__mspabi_mpyi", false);
+ DONE;
+ }
+)
+
+(define_expand "mulsi3"
+ [(set (match_operand:SI 0 "register_operand" "=r")
+ (mult:SI (match_operand:SI 1 "register_operand" "%0")
+(match_operand:SI 2 "register_operand" "r")))]
+ "msp430_has_hwmult ()"
+ {
+ msp430_expand_helper (operands, "__mspabi_mpyl", false);
+ DONE;
+ }
+)
+
; libgcc helper functions for widening multiplication aren't currently
; generated by gcc, so we can't catch them later and map them to the mspabi
; functions.
@@ -1733,9 +1755,7 @@ (define_insn "delay_cycles_1"
; If we don't have hardware multiply support, it will generally be slower and
; result in larger code to call the mspabi library function to perform the
; widening multiplication than just leaving GCC to widen the arguments itself.
-;
-; We don't use library functions for SImode->DImode widening since its always
-; larger and slower than letting GCC widen the arguments inline.
+
(define_expand "mulhisi3"
[(set (match_operand:SI 0 "register_operand" "=r")
(mult:SI (sign_extend:SI (match_operand:HI 1 "register_operand" "%0"))
@@ -1766,6 +1786,37 @@ (define_expand "umulhisi3"
}
)
+(define_expand "mulsidi3"
+ [(set (match_operand:DI 0 "register_operand" "=r")
+ (mult:DI (sign_extend:DI (match_operand:SI 1 "register_operand" "%0"))
+(sign_extend:DI (match_operand:SI 2 "register_operand" "r"]
+ "msp430_has_hwmult ()"
+ {
+/* Leave the other case for the inline insn. */
+if (!(optimize > 2 && msp430_has_hwmult ()))
+{
+ msp430_expand_helper (operands, "__mspabi_mpysll", false);
+ DONE;
+
[PATCH 2/2] MSP430: Add 64-bit hardware multiply support
Hardware multipliers that support widening 32-bit multiplication can
be used to perform a 64-bit * 64-bit multiplication more efficiently
than a software implementation.
The following equation is used to perform 64-bit multiplication for
devices with "32bit" or "f5series" hardware multiply versions:
64bit_result = (low32_op0 * lop32_op1)
+ ((low32_op0 * high32_op1) << 32)
+ ((high32_op0 * low32_op1) << 32)
Successfully regtested GCC and G++ testsuites for:
msp430-sim
msp430-sim/-mcpu=msp430
msp430-sim/-mhwmult=f5series
msp430-sim/-mhwmult=f5series/-mlarge/-mdata-region=either/-mcode-region=either
msp430-sim/-mlarge
msp430-sim/-mlarge/-mdata-region=either/-mcode-region=either
Additionally regtested GCC execute.exp for:
msp430-sim/-mhwmult=16bit
msp430-sim/-mhwmult=32bit
msp430-sim/-mhwmult=f5series
msp430-sim/-mhwmult=none
msp430-sim/-mlarge/-mcode-region=either/-mdata-region=either/-mhwmult=16bit
msp430-sim/-mlarge/-mcode-region=either/-mdata-region=either/-mhwmult=32bit
msp430-sim/-mlarge/-mcode-region=either/-mdata-region=either/-mhwmult=f5series
msp430-sim/-mlarge/-mcode-region=either/-mdata-region=either/-mhwmult=none
Ok for trunk?
>From cb1ea86822cc8c6b0183afd06da42e320034dc43 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Sun, 15 Nov 2020 21:03:14 +
Subject: [PATCH 2/2] MSP430: Add 64-bit hardware multiply support
Hardware multipliers that support widening 32-bit multiplication can
be used to perform a 64-bit * 64-bit multiplication more efficiently
than a software implementation.
The following equation is used to perform 64-bit multiplication for
devices with "32bit" or "f5series" hardware multiply versions:
64bit_result = (low32_op0 * lop32_op1)
+ ((low32_op0 * high32_op1) << 32)
+ ((high32_op0 * low32_op1) << 32)
libgcc/ChangeLog:
* config/msp430/lib2hw_mul.S (mult64_hw): New.
(if MUL_32): Use mult64_hw for __muldi3.
(if MUL_F5): Use mult64_hw for __muldi3.
* config/msp430/lib2mul.c (__muldi3): New.
* config/msp430/t-msp430 (LIB2FUNCS_EXCLUDE): Define.
---
libgcc/config/msp430/lib2hw_mul.S | 77 +--
libgcc/config/msp430/lib2mul.c| 52 +
libgcc/config/msp430/t-msp430 | 5 ++
3 files changed, 130 insertions(+), 4 deletions(-)
diff --git a/libgcc/config/msp430/lib2hw_mul.S
b/libgcc/config/msp430/lib2hw_mul.S
index 0fbafcd8b95..855dcd8bb55 100644
--- a/libgcc/config/msp430/lib2hw_mul.S
+++ b/libgcc/config/msp430/lib2hw_mul.S
@@ -207,6 +207,73 @@
MOV.W &\RES3, R15 ; Ready high 16-bits for return
.endm
+.macro mult64_hw MPY32_LO MPY32_HI OP2_LO OP2_HI RES0 RES1 RES2 RES3
+;* * 64-bit hardware multiply with a 64-bit result
+;* int64 = int64 * int64
+;*
+;* - Operand 1 is in R8, R9, R10, R11
+;* - Operand 2 is in R12, R13, R14, R15
+;* - Resultis in R12, R13, R14, R15
+;*
+;* 64-bit multiplication is achieved using the 32-bit hardware multiplier with
+;* the following equation:
+;*R12:R15 = (R8:R9 * R12:R13) + ((R8:R9 * R14:R15) << 32) + ((R10:R11 *
R12:R13) << 32)
+;*
+;* The left shift by 32 is handled with minimal cost by saving the two low
+;* words and discarding the two high words.
+;*
+;* To ensure that the multiply is performed atomically, interrupts are
+;* disabled upon routine entry. Interrupt state is restored upon exit.
+;*
+;* Registers used: R6, R7, R8, R9, R10, R11, R12, R13, R14, R15
+;*
+;* Macro arguments are the memory locations of the hardware registers.
+;*
+#if defined(__MSP430X_LARGE__)
+ PUSHM.A #5, R10
+#elif defined(__MSP430X__)
+ PUSHM.W #5, R10
+#else
+ PUSH R10 { PUSH R9 { PUSH R8 { PUSH R7 { PUSH R6
+#endif
+ ; Multiply the low 32-bits of op0 and the high 32-bits of op1.
+ MOV.W R8, &\MPY32_LO
+ MOV.W R9, &\MPY32_HI
+ MOV.W R14, &\OP2_LO
+ MOV.W R15, &\OP2_HI
+ ; Save the low 32-bits of the result.
+ MOV.W &\RES0, R6
+ MOV.W &\RES1, R7
+ ; Multiply the high 32-bits of op0 and the low 32-bits of op1.
+ MOV.W R10, &\MPY32_LO
+ MOV.W R11, &\MPY32_HI
+ MOV.W R12, &\OP2_LO
+ MOV.W R13, &\OP2_HI
+ ; Add the low 32-bits of the result to the previously saved result.
+ ADD.W &\RES0, R6
+ ADDC.W &\RES1, R7
+ ; Multiply the low 32-bits of op0 and op1.
+ MOV.W R8, &\MPY32_LO
+ MOV.W R9, &\MPY32_HI
+ MOV.W R12, &\OP2_LO
+ MOV.W R13, &\OP2_HI
+ ; Write the return values
+ MOV.W &\RES0, R12
+ MOV.W &\RES1, R13
+ MOV.W &\RES2, R14
+ MOV.W &\RES3, R15
+ ; Add the saved low 32-bit results from earlier to the high 32-bits of
+ ; this result, effectively
[PATCH 1/3] Fix "noinit" attribute being ignored for -O0 and -fdata-sections
Variables with the "noinit" attribute are ignored at -O0 because they
are treated like a regular bss variable and placed in the .bss section.
With -fdata-sections they are ignored because they are not handled in
resolve_unique_section.
Successfully regtested for arm-none-eabi.
Ok for trunk?
>From d501b36fc92f1506427836ded69997cc576beda4 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Sun, 15 Nov 2020 21:43:22 +
Subject: [PATCH 1/3] Fix "noinit" attribute being ignored for -O0 and
-fdata-sections
Variables with the "noinit" attribute are ignored at -O0 because they
are treated like a regular bss variable and placed in the .bss section.
With -fdata-sections they are ignored because they are not handled in
resolve_unique_section.
gcc/ChangeLog:
* tree.h (DECL_NOINIT_P): Define.
* varasm.c (DECL_NOINIT_P): Check DECL_NOINIT_P before using
unnamed bss/lcomm sections for bss_initializer variables.
(default_elf_select_section): Use DECL_NOINIT_P instead of
looking up attribute for .noinit section selection.
(default_unique_section): Check DECL_NOINIT_P for .noinit
section selection.
gcc/testsuite/ChangeLog:
* gcc.c-torture/execute/noinit-attribute.c: Don't override
optimization options set by torture test harness.
* lib/target-supports.exp (check_effective_target_noinit): Adjust
comment formatting.
---
gcc/testsuite/gcc.c-torture/execute/noinit-attribute.c | 2 +-
gcc/testsuite/lib/target-supports.exp | 2 +-
gcc/tree.h | 7 +++
gcc/varasm.c | 10 +++---
4 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/gcc/testsuite/gcc.c-torture/execute/noinit-attribute.c
b/gcc/testsuite/gcc.c-torture/execute/noinit-attribute.c
index 20a2a452e79..c8fa22bf38b 100644
--- a/gcc/testsuite/gcc.c-torture/execute/noinit-attribute.c
+++ b/gcc/testsuite/gcc.c-torture/execute/noinit-attribute.c
@@ -1,6 +1,6 @@
/* { dg-do run } */
/* { dg-require-effective-target noinit } */
-/* { dg-options "-O2" } */
+/* { dg-options "-Wattributes" } */
/* { dg-skip-if "data LMA != VMA" { msp430-*-* } { "-mlarge" } } */
/* This test checks that noinit data is handled correctly.
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index 60ebbb39f9d..49c65b50109 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -368,7 +368,7 @@ proc check_weak_override_available { } {
return [check_weak_available]
}
-# The noinit attribute is only supported by some targets.
+# The "noinit" attribute is only supported by some targets.
# This proc returns 1 if it's supported, 0 if it's not.
proc check_effective_target_noinit { } {
diff --git a/gcc/tree.h b/gcc/tree.h
index f8f0a606439..f342731ae59 100644
--- a/gcc/tree.h
+++ b/gcc/tree.h
@@ -2659,6 +2659,13 @@ extern tree vector_element_bits_tree (const_tree);
#define DECL_PRESERVE_P(DECL) \
DECL_COMMON_CHECK (DECL)->decl_common.preserve_flag
+/* Nonzero for a decl that is decorated with the "noinit" attribute.
+ decls with this attribute are placed into the ".noinit" section, so they are
+ not initialized by the target's startup code. */
+#define DECL_NOINIT_P(DECL)\
+ (DECL_P (DECL) \
+ && (lookup_attribute ("noinit", DECL_ATTRIBUTES (DECL)) != NULL_TREE))
+
/* For function local variables of COMPLEX and VECTOR types,
indicates that the variable is not aliased, and that all
modifications to the variable have been adjusted so that
diff --git a/gcc/varasm.c b/gcc/varasm.c
index 435c7b348a5..3c902059069 100644
--- a/gcc/varasm.c
+++ b/gcc/varasm.c
@@ -1208,6 +1208,7 @@ get_variable_section (tree decl, bool prefer_noswitch_p)
if (ADDR_SPACE_GENERIC_P (as)
&& !DECL_THREAD_LOCAL_P (decl)
+ && !DECL_NOINIT_P (decl)
&& !(prefer_noswitch_p && targetm.have_switchable_bss_sections)
&& bss_initializer_p (decl))
{
@@ -7009,13 +7010,11 @@ default_elf_select_section (tree decl, int reloc,
sname = ".tdata";
break;
case SECCAT_BSS:
- if (DECL_P (decl)
- && lookup_attribute ("noinit", DECL_ATTRIBUTES (decl)) != NULL_TREE)
+ if (DECL_P (decl) && DECL_NOINIT_P (decl))
{
sname = ".noinit";
break;
}
-
if (bss_section)
return bss_section;
sname = ".bss";
@@ -7078,6 +7077,11 @@ default_unique_section (tree decl, int reloc)
prefix = one_only ? ".s" : ".sdata";
break;
case SECCAT_BSS:
+ if (DECL_P (decl) && DECL_NOINIT_P (decl))
+ {
+ prefix = one_only ? ".n" : ".noinit";
+ break;
+ }
prefix = one_only ? ".b" : ".bss";
break;
case SECCAT_SBSS:
--
2.29.2
[PATCH V2 0/3] Fix "noinit" attr, implement "persistent" attr
This patch series is version 2 of
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557184.html
The implementation is now simplified so as to not use a symtab flag for
"noinit" variables, instead we just check whether the decl has the
attribute set.
This patch series fixes behavior related to the "noinit" attribute, and
makes the MSP430 "persistent" attribute generic, so it can be used for
ARM.
These attributes are related because they are both used to mark
variables that should not be initialized by the target's runtime
startup code.
The "noinit" attribute is used for variables that are not initialized
to any value by the program loader, or the runtime startup code.
This attribute was made generic for GCC 10, whilst previously it was
only supported for MSP430.
There are a couple of issues when using it for arm-eabi:
- It does not work at -O0.
The test for it is in the torture directory but only runs at -O2,
which is why this bug was undetected.
- It does not work with -fdata-sections.
Patch 1 fixes these issues.
The "persistent" attribute is used for variables that *are* initialized
by the program loader, but are not initialized by the runtime startup
code. "persistent" variables are placed in a non-volatile area of
memory, which allows their value to "persist" between processor resets.
The "persistent" attribute is already implemented for msp430-elf, but
patch 3 makes it generic so it can be leveraged by ARM targets. The
".persistent" section is pervasive in linker scripts distributed for
ARM devices by manufacturers such as ST and TI.
Patch 2 enables validation of the "persistent" attribute for when
compiling C++ programs.
I've attached a Binutils patch that adds the ".persistent" section to
the default ARM linker script. I'll apply it alongside this GCC patch.
Side note: There is handling of a ".persistent.bss" section, however
this is Ada-specific and unrelated to the "noinit" and "persistent"
attributes. The handling of the "noinit" and "persistent" attributes
does not interfere with it.
msp430-elf "persistent" attribute behaviour needs changing if this patch
is approved, I have a patch ready to do that.
Successfully regtested for arm-none-eabi.
Ok for trunk?
Jozef Lawrynowicz (3):
Fix "noinit" attribute being ignored for -O0 and -fdata-sections
cp/decl.c: Set DECL_INITIAL before attribute processing
Implement the "persistent" attribute
gcc/c-family/c-attribs.c | 141 --
gcc/cp/decl.c | 13 ++
gcc/doc/extend.texi | 20 ++-
.../c-c++-common/torture/attr-noinit-1.c | 7 +
.../c-c++-common/torture/attr-noinit-2.c | 8 +
.../c-c++-common/torture/attr-noinit-3.c | 11 ++
.../torture/attr-noinit-invalid.c | 12 ++
.../torture/attr-noinit-main.inc} | 37 ++---
.../c-c++-common/torture/attr-persistent-1.c | 8 +
.../c-c++-common/torture/attr-persistent-2.c | 8 +
.../c-c++-common/torture/attr-persistent-3.c | 10 ++
.../torture/attr-persistent-invalid.c | 11 ++
.../torture/attr-persistent-main.inc | 58 +++
.../g++.target/msp430/data-attributes.C | 52 +++
gcc/testsuite/g++.target/msp430/msp430.exp| 44 ++
.../gcc.target/msp430/data-attributes-2.c | 1 +
gcc/testsuite/lib/target-supports.exp | 15 +-
gcc/tree.h| 14 ++
gcc/varasm.c | 29 +++-
19 files changed, 426 insertions(+), 73 deletions(-)
create mode 100644 gcc/testsuite/c-c++-common/torture/attr-noinit-1.c
create mode 100644 gcc/testsuite/c-c++-common/torture/attr-noinit-2.c
create mode 100644 gcc/testsuite/c-c++-common/torture/attr-noinit-3.c
create mode 100644 gcc/testsuite/c-c++-common/torture/attr-noinit-invalid.c
rename gcc/testsuite/{gcc.c-torture/execute/noinit-attribute.c =>
c-c++-common/torture/attr-noinit-main.inc} (56%)
create mode 100644 gcc/testsuite/c-c++-common/torture/attr-persistent-1.c
create mode 100644 gcc/testsuite/c-c++-common/torture/attr-persistent-2.c
create mode 100644 gcc/testsuite/c-c++-common/torture/attr-persistent-3.c
create mode 100644 gcc/testsuite/c-c++-common/torture/attr-persistent-invalid.c
create mode 100644 gcc/testsuite/c-c++-common/torture/attr-persistent-main.inc
create mode 100644 gcc/testsuite/g++.target/msp430/data-attributes.C
create mode 100644 gcc/testsuite/g++.target/msp430/msp430.exp
--
2.29.2
>From 870479a3d2e7dc07441df07b4b8947d111ffb2f9 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Mon, 26 Oct 2020 17:55:16 +
Subject: [PATCH] support .noinit and .persistent in arm linker script
---
ld/emulparams/armelf.sh
[PATCH 2/3] cp/decl.c: Set DECL_INITIAL before attribute processing
Attribute handlers may want to examine DECL_INITIAL for a decl, to
validate the attribute being applied. For C++, DECL_INITIAL is currently
not set until cp_finish_decl, by which time attribute validation has
already been performed.
For msp430-elf this causes the "persistent" attribute to always be
rejected for C++, since DECL_INITIAL must be non-null for the
attribute to be applied to a decl.
This patch ensures DECL_INITIAL is set for initialized decls early in
start_decl, before attribute handlers run. This allows the
initialization status of the decl to be examined by the handlers.
DECL_INITIAL must be restored to it's initial value after attribute
validation is performed, so as to not interfere with later decl
processing.
Successfully regtested for arm-none-eabi.
Ok for trunk?
>From f87d3c3aa131cadeaa2f32c9a36609b4dd42db96 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Sun, 15 Nov 2020 21:43:00 +
Subject: [PATCH 2/3] cp/decl.c: Set DECL_INITIAL before attribute processing
Attribute handlers may want to examine DECL_INITIAL for a decl, to
validate the attribute being applied. For C++, DECL_INITIAL is currently
not set until cp_finish_decl, by which time attribute validation has
already been performed.
For msp430-elf this causes the "persistent" attribute to always be
rejected for C++, since DECL_INITIAL must be non-null for the
attribute to be applied to a decl.
This patch ensures DECL_INITIAL is set for initialized decls early in
start_decl, before attribute handlers run. This allows the
initialization status of the decl to be examined by the handlers.
DECL_INITIAL must be restored to it's initial value after attribute
validation is performed, so as to not interfere with later decl
processing.
gcc/cp/ChangeLog:
* decl.c (start_decl): Set DECL_INITIAL for initialized decls
before attribute processing.
gcc/testsuite/ChangeLog:
* gcc.target/msp430/data-attributes-2.c: Adjust test.
* g++.target/msp430/data-attributes.C: New test.
* g++.target/msp430/msp430.exp: New test.
---
gcc/cp/decl.c | 13 +
.../g++.target/msp430/data-attributes.C | 52 +++
gcc/testsuite/g++.target/msp430/msp430.exp| 44
.../gcc.target/msp430/data-attributes-2.c | 1 +
4 files changed, 110 insertions(+)
create mode 100644 gcc/testsuite/g++.target/msp430/data-attributes.C
create mode 100644 gcc/testsuite/g++.target/msp430/msp430.exp
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 62648841ac3..9ed716b089d 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -5234,6 +5234,7 @@ start_decl (const cp_declarator *declarator,
bool was_public;
int flags;
bool alias;
+ tree initial;
*pushed_scope_p = NULL_TREE;
@@ -5258,6 +5259,10 @@ start_decl (const cp_declarator *declarator,
return error_mark_node;
}
+ /* Save the DECL_INITIAL value in case it gets clobbered to assist
+ with attribute validation. */
+ initial = DECL_INITIAL (decl);
+
if (initialized)
{
if (! toplevel_bindings_p ()
@@ -5267,6 +5272,10 @@ start_decl (const cp_declarator *declarator,
DECL_EXTERNAL (decl) = 0;
if (toplevel_bindings_p ())
TREE_STATIC (decl) = 1;
+ /* Tell 'cplus_decl_attributes' this is an initialized decl,
+even though we might not yet have the initializer expression. */
+ if (!DECL_INITIAL (decl))
+ DECL_INITIAL (decl) = error_mark_node;
}
alias = lookup_attribute ("alias", DECL_ATTRIBUTES (decl)) != 0;
@@ -5285,6 +5294,10 @@ start_decl (const cp_declarator *declarator,
/* Set attributes here so if duplicate decl, will have proper attributes. */
cplus_decl_attributes (&decl, attributes, flags);
+ /* Restore the original DECL_INITIAL that we may have clobbered earlier to
+ assist with attribute validation. */
+ DECL_INITIAL (decl) = initial;
+
/* Dllimported symbols cannot be defined. Static data members (which
can be initialized in-class and dllimported) go through grokfield,
not here, so we don't need to exclude those decls when checking for
diff --git a/gcc/testsuite/g++.target/msp430/data-attributes.C
b/gcc/testsuite/g++.target/msp430/data-attributes.C
new file mode 100644
index 000..4e2139e93f7
--- /dev/null
+++ b/gcc/testsuite/g++.target/msp430/data-attributes.C
@@ -0,0 +1,52 @@
+/* { dg-do compile } */
+/* { dg-skip-if "" { *-*-* } { "-mcpu=msp430" } } */
+/* { dg-options "-mlarge" } */
+
+/* The msp430-specific variable attributes "lower", "upper", either", "noinit"
+ and "persistent", all conflict with one another.
+ These attributes also conflict with the "section" attribute, since they
+ specify sections to put the variables into. */
+int __attribute__((persistent)) p = 10;
+int __attribute__(
[PATCH 3/3] Implement the "persistent" attribute
The "persistent" attribute is used for variables that are initialized
by the program loader, but are not initialized by the runtime startup
code. "persistent" variables are placed in a non-volatile area of
memory, which allows their value to "persist" between processor resets.
Successfully regtested for arm-none-eabi.
Ok for trunk?
>From c67b1bb6f46a69916c7de74617f4301b95c894d8 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Sun, 15 Nov 2020 21:44:10 +
Subject: [PATCH 3/3] Implement the "persistent" attribute
The "persistent" attribute is used for variables that are initialized
by the program loader, but are not initialized by the runtime startup
code. "persistent" variables are placed in a non-volatile area of
memory, which allows their value to "persist" between processor resets.
gcc/c-family/ChangeLog:
* c-attribs.c (handle_special_var_sec_attribute): New.
(handle_noinit_attribute): Remove.
(attr_noinit_exclusions): Rename to...
(attr_section_exclusions): ...this, and add "persistent" attribute
exclusion.
(c_common_attribute_table): Add "persistent" attribute.
gcc/ChangeLog:
* doc/extend.texi: Document the "persistent" variable attribute.
* tree.h (DECL_PERSISTENT_P): Define.
* varasm.c (bss_initializer_p): Return false for a
DECL_PERSISTENT_P decl initialized to zero.
(default_section_type_flags): Handle the ".persistent" section.
(default_elf_select_section): Likewise.
(default_unique_section): Likewise.
gcc/testsuite/ChangeLog:
* gcc.c-torture/execute/noinit-attribute.c: Moved to...
* c-c++-common/torture/attr-noinit-main.inc: ...here.
* lib/target-supports.exp (check_effective_target_persistent): New.
* c-c++-common/torture/attr-noinit-1.c: New test.
* c-c++-common/torture/attr-noinit-2.c: New test.
* c-c++-common/torture/attr-noinit-3.c: New test.
* c-c++-common/torture/attr-noinit-invalid.c: New test.
* c-c++-common/torture/attr-persistent-1.c: New test.
* c-c++-common/torture/attr-persistent-2.c: New test.
* c-c++-common/torture/attr-persistent-3.c: New test.
* c-c++-common/torture/attr-persistent-invalid.c: New test.
* c-c++-common/torture/attr-persistent-main.inc: New test.
---
gcc/c-family/c-attribs.c | 141 --
gcc/doc/extend.texi | 20 ++-
.../c-c++-common/torture/attr-noinit-1.c | 7 +
.../c-c++-common/torture/attr-noinit-2.c | 8 +
.../c-c++-common/torture/attr-noinit-3.c | 11 ++
.../torture/attr-noinit-invalid.c | 12 ++
.../torture/attr-noinit-main.inc} | 37 ++---
.../c-c++-common/torture/attr-persistent-1.c | 8 +
.../c-c++-common/torture/attr-persistent-2.c | 8 +
.../c-c++-common/torture/attr-persistent-3.c | 10 ++
.../torture/attr-persistent-invalid.c | 11 ++
.../torture/attr-persistent-main.inc | 58 +++
gcc/testsuite/lib/target-supports.exp | 13 ++
gcc/tree.h| 7 +
gcc/varasm.c | 19 ++-
15 files changed, 301 insertions(+), 69 deletions(-)
create mode 100644 gcc/testsuite/c-c++-common/torture/attr-noinit-1.c
create mode 100644 gcc/testsuite/c-c++-common/torture/attr-noinit-2.c
create mode 100644 gcc/testsuite/c-c++-common/torture/attr-noinit-3.c
create mode 100644 gcc/testsuite/c-c++-common/torture/attr-noinit-invalid.c
rename gcc/testsuite/{gcc.c-torture/execute/noinit-attribute.c =>
c-c++-common/torture/attr-noinit-main.inc} (55%)
create mode 100644 gcc/testsuite/c-c++-common/torture/attr-persistent-1.c
create mode 100644 gcc/testsuite/c-c++-common/torture/attr-persistent-2.c
create mode 100644 gcc/testsuite/c-c++-common/torture/attr-persistent-3.c
create mode 100644 gcc/testsuite/c-c++-common/torture/attr-persistent-invalid.c
create mode 100644 gcc/testsuite/c-c++-common/torture/attr-persistent-main.inc
diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
index f1680820ecd..6b26f43c298 100644
--- a/gcc/c-family/c-attribs.c
+++ b/gcc/c-family/c-attribs.c
@@ -94,10 +94,10 @@ static tree handle_constructor_attribute (tree *, tree,
tree, int, bool *);
static tree handle_destructor_attribute (tree *, tree, tree, int, bool *);
static tree handle_mode_attribute (tree *, tree, tree, int, bool *);
static tree handle_section_attribute (tree *, tree, tree, int, bool *);
+static tree handle_special_var_sec_attribute (tree *, tree, tree, int, bool *);
static tree handle_aligned_attribute (tree *, tree, tree, int, bool *);
static tree handle_warn_if_not_aligned_attribute (tree *, tree, tree,
int, bool *);
-static tree handle_noinit_attribute (t
[committed] MSP430: Define function to check 16-bit hwmult support
Rather than inferring 16-bit hwmult support from lack of
32-bit/f5series/none hwmult support, define a function which explicitly
checks for 16-bit hwmult support.
Successfully regtested for msp430-elf.
Committed as obvious.
>From 814949ddceaef59725c84fe8ef7c6c617fb5d049 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Sun, 15 Nov 2020 21:02:58 +
Subject: [PATCH] MSP430: Define function to check 16-bit hwmult support
gcc/ChangeLog:
* config/msp430/msp430.c (msp430_use_16bit_hwmult): New.
(use_32bit_hwmult): Rename to..
(msp430_use_32bit_hwmult): ..this.
(msp430_muldiv_costs): Use msp430_use_16bit_hwmult and
msp430_use_32bit_hwmult.
(msp430_expand_helper): Use msp430_use_16bit_hwmult and
msp430_use_32bit_hwmult.
(msp430_output_labelref): Use msp430_use_32bit_hwmult.
---
gcc/config/msp430/msp430.c | 51 +-
1 file changed, 39 insertions(+), 12 deletions(-)
diff --git a/gcc/config/msp430/msp430.c b/gcc/config/msp430/msp430.c
index e98de8d5dd0..38a9938255e 100644
--- a/gcc/config/msp430/msp430.c
+++ b/gcc/config/msp430/msp430.c
@@ -58,7 +58,8 @@
static void msp430_compute_frame_info (void);
-static bool use_32bit_hwmult (void);
+static bool msp430_use_16bit_hwmult (void);
+static bool msp430_use_32bit_hwmult (void);
static bool use_helper_for_const_shift (machine_mode mode, HOST_WIDE_INT amt);
@@ -1318,9 +1319,7 @@ msp430_muldiv_costs (rtx src, rtx dst, bool speed, rtx
outer_rtx,
{
enum rtx_code outer_code = GET_CODE (outer_rtx);
const struct msp430_multlib_costs *cost_p;
- bool hwmult_16bit = (msp430_has_hwmult () && !(msp430_use_f5_series_hwmult ()
-|| use_32bit_hwmult ()));
- cost_p = (hwmult_16bit
+ cost_p = (msp430_use_16bit_hwmult ()
? &cycle_cost_multlib_32bit
: &cycle_cost_multlib_16bit);
@@ -1346,8 +1345,9 @@ msp430_muldiv_costs (rtx src, rtx dst, bool speed, rtx
outer_rtx,
if (outer_code != MULT)
/* Division is always expensive. */
factor = 7;
- else if (((hwmult_16bit && outer_mode != DImode)
- || use_32bit_hwmult () || msp430_use_f5_series_hwmult ()))
+ else if (((msp430_use_16bit_hwmult () && outer_mode != DImode)
+ || msp430_use_32bit_hwmult ()
+ || msp430_use_f5_series_hwmult ()))
/* When the hardware multiplier is available, only disparage
slightly. */
factor = 2;
@@ -1364,7 +1364,7 @@ msp430_muldiv_costs (rtx src, rtx dst, bool speed, rtx
outer_rtx,
The 16-bit hardware multiply library cannot be used to produce 64-bit
results. */
if (outer_code != MULT || !msp430_has_hwmult ()
- || (outer_mode == DImode && hwmult_16bit))
+ || (outer_mode == DImode && msp430_use_16bit_hwmult ()))
{
factor = (outer_code == MULT ? 50 : 70);
return factor * mode_factor * msp430_costs (src, dst, speed, outer_rtx);
@@ -3379,7 +3379,7 @@ msp430_expand_helper (rtx *operands, const char
*helper_name,
if (msp430_use_f5_series_hwmult ())
fsym = gen_rtx_SYMBOL_REF (VOIDmode, concat (helper_name,
"_f5hw", NULL));
- else if (use_32bit_hwmult ())
+ else if (msp430_use_32bit_hwmult ())
{
/* When the arguments are 16-bits, the 16-bit hardware multiplier is
used. */
@@ -3390,8 +3390,7 @@ msp430_expand_helper (rtx *operands, const char
*helper_name,
fsym = gen_rtx_SYMBOL_REF (VOIDmode, concat (helper_name,
"_hw32", NULL));
}
- /* 16-bit hardware multiply. */
- else if (msp430_has_hwmult ())
+ else if (msp430_use_16bit_hwmult ())
fsym = gen_rtx_SYMBOL_REF (VOIDmode, concat (helper_name,
"_hw", NULL));
else
@@ -3932,7 +3931,7 @@ msp430_use_f5_series_hwmult (void)
32-bit hardware multiplier. */
static bool
-use_32bit_hwmult (void)
+msp430_use_32bit_hwmult (void)
{
static const char * cached_match = NULL;
static bool cached_result;
@@ -3955,6 +3954,34 @@ use_32bit_hwmult (void)
return cached_result = false;
}
+/* Returns true if the current MCU has a first generation
+ 16-bit hardware multiplier. */
+
+static bool
+msp430_use_16bit_hwmult (void)
+{
+ static const char * cached_match = NULL;
+ static boolcached_result;
+
+ if (msp430_hwmult_type == MSP430_HWMULT_SMALL)
+return true;
+
+ if (target_mcu == NULL || msp430_hwmult_type != MSP430_HWMULT_AUTO)
+return false;
+
+ if (target_mcu == cached_match)
+return cached_result;
+
+ cached_match = target_mcu;
+
+ msp430_extract_mcu_data (target_mcu);
+ if (extracted_mcu_data.name != NULL)
+return cached_result = (extracted
[committed] MSP430: Fix inconsistent naming of hwmult libfuncs
The naming scheme used by GCC to reference MSP430 hardware multiply
library functions is inconsistent.
Sometimes the "GCC" names (e.g. mulsi2) are used, other times the
"MSPABI" names (e.g. __mspabi_mpyl) are used. The __mspabi names should
always be used.
Also, sometimes an identifier for the hardware multiply support is
appended to the GCC name, when the functions are defined, but this is
not required.
This patch fixes those issues, so the names used to refer to the
hardware multiply library functions follow a consistent pattern.
Successfully regtested for msp430-elf.
Committed as obvious.
>From c746fc40f4ec8cfc1092efd49d567751858d2099 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Sun, 15 Nov 2020 21:03:06 +
Subject: [PATCH] MSP430: Fix inconsistent naming of hwmult libfuncs
The naming scheme used by GCC to reference MSP430 hardware multiply
library functions is inconsistent.
Sometimes the "GCC" names (e.g. mulsi2) are used, other times the
"MSPABI" names (e.g. __mspabi_mpyl) are used.
Also, sometimes an identifier for the hardware multiply support is
appended to the GCC name, when the functions are defined, but this is
not required.
This patch fixes those issues, so the names used to refer to the
hardware multiply library functions follow a consistent pattern.
gcc/ChangeLog:
* config/msp430/msp430.c (msp430_output_labelref): Don't process mspabi
hwmult library function names into GCC-style names.
libgcc/ChangeLog:
* config/msp430/lib2hw_mul.S: Omit _hw* suffix from GCC names for
hwmult library functions.
gcc/testsuite/ChangeLog:
* gcc.target/msp430/rtx-cost-Os-f5series.c: Adjust test to use new
hwmult library function name.
---
gcc/config/msp430/msp430.c| 22 ---
.../gcc.target/msp430/rtx-cost-Os-f5series.c | 2 +-
libgcc/config/msp430/lib2hw_mul.S | 12 +-
3 files changed, 7 insertions(+), 29 deletions(-)
diff --git a/gcc/config/msp430/msp430.c b/gcc/config/msp430/msp430.c
index 38a9938255e..51f49edffa8 100644
--- a/gcc/config/msp430/msp430.c
+++ b/gcc/config/msp430/msp430.c
@@ -4031,28 +4031,6 @@ msp430_output_labelref (FILE *file, const char *name)
break;
}
- /* If we have been given a specific MCU name then we may be
- able to make use of its hardware multiply capabilities. */
- if (msp430_has_hwmult ())
-{
- if (strcmp ("__mspabi_mpyi", name) == 0)
- {
- if (msp430_use_f5_series_hwmult ())
- name = "__mulhi2_f5";
- else
- name = "__mulhi2";
- }
- else if (strcmp ("__mspabi_mpyl", name) == 0)
- {
- if (msp430_use_f5_series_hwmult ())
- name = "__mulsi2_f5";
- else if (msp430_use_32bit_hwmult ())
- name = "__mulsi2_hw32";
- else
- name = "__mulsi2";
- }
-}
-
if (user_label_prefix[0] != 0)
fputs (user_label_prefix, file);
diff --git a/gcc/testsuite/gcc.target/msp430/rtx-cost-Os-f5series.c
b/gcc/testsuite/gcc.target/msp430/rtx-cost-Os-f5series.c
index bb37f9083d9..67d91983715 100644
--- a/gcc/testsuite/gcc.target/msp430/rtx-cost-Os-f5series.c
+++ b/gcc/testsuite/gcc.target/msp430/rtx-cost-Os-f5series.c
@@ -24,7 +24,7 @@ unsigned long res3;
** MOV.B #100, R14
** MOV.B #0, R15
** ...
-** CALL.* #__mulsi2_f5
+** CALL.* #__mspabi_mpyl_f5hw
** ...
*/
void foo (void)
diff --git a/libgcc/config/msp430/lib2hw_mul.S
b/libgcc/config/msp430/lib2hw_mul.S
index de840d934f6..0fbafcd8b95 100644
--- a/libgcc/config/msp430/lib2hw_mul.S
+++ b/libgcc/config/msp430/lib2hw_mul.S
@@ -353,9 +353,9 @@
mult1632 MPY, OP2, RESLO, RESHI
end_func __umulhisi2
- start_func __mulsi2_hw32 __mspabi_mpyl __mspabi_mpyl_hw32
+ start_func __mulsi2 __mspabi_mpyl __mspabi_mpyl_hw32
mult32_hw MPY32L, MPY32H, OP2L, OP2H, RES0, RES1
- end_func __mulsi2_hw32
+ end_func __mulsi2
start_func __mulsidi2 __mspabi_mpysll __mspabi_mpysll_hw32
mult3264_hw MPYS32L, MPYS32H, OP2L, OP2H, RES0, RES1, RES2, RES3
@@ -373,9 +373,9 @@
as the second generation hardware, but they are accessed from different
memory registers. */
- start_func __mulhi2_f5 __mspabi_mpyi __mspabi_mpyi_f5hw
+ start_func __mulhi2 __mspabi_mpyi __mspabi_mpyi_f5hw
mult16 MPY_F5, OP2_F5, RESLO_F5
- end_func __mulhi2_f5
+ end_func __mulhi2
start_func __mulhisi2 __mspabi_mpysl __mspabi_mpysl_f5hw
mult1632 MPYS_F5, OP2_F5, RESLO_F5, RESHI_F5
@@ -385,9 +385,9 @@
mult1632 MPY_F5, OP2_F5, RESLO_F5, RESHI_F5
end_func __umulhisi2
- start_func __mulsi2_f5 __mspabi_mpyl __mspabi_mpyl_f5hw
+ start_func __mulsi2 __mspabi_mpyl __mspabi_mpyl_f5hw
mult32_
[COMMITTED][MSP430] Fix postinc addressing mode being used for dst operand of CMP insns
MSP430 RTL patterns for conditional branch instructions allow the post increment addressing mode to be used for the "dest" operand of CMP instructions used in these patterns. This is currently causing trunk to FTB for msp430-elf since these instructions are being generated using an autoinc for the dest operand, and the assembler is rejecting them: > ldtoa.s:1104: Error: this addressing mode is not applicable for destination > operand The attached patch fixes this by using the "msp430_general_dst_nonv_operand" predicate instead of the "nonimmediate_operand" predicate for the offending RTL patterns. Successfully regtested for msp430-elf on trunk and committed as obvious. >From 914d2119720344505a6ad2adb51d55fc80ed630c Mon Sep 17 00:00:00 2001 From: jozefl Date: Thu, 5 Dec 2019 10:56:02 + Subject: [PATCH] MSP430: Fix postinc addressing mode being used for dst op of CMP insns 2019-12-05 Jozef Lawrynowicz * config/msp430/msp430.md (cbranch4): Use msp430_general_dst_nonv_operand instead of nonimmediate_operand for dest operand of CMP instruction. (cbranchpsi4_real): Likewise. (cbranchqi4_real): Likewise. (cbranchhi4_real): Likewise. (cbranchpsi4_reversed): Likewise. (cbranchqi4_reversed): Likewise. (cbranchhi4_reversed): Likewise. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@278994 138bc75d-0d04-0410-961f-82ee72b054a4 --- gcc/ChangeLog | 12 gcc/config/msp430/msp430.md | 14 +++--- 2 files changed, 19 insertions(+), 7 deletions(-) diff --git a/gcc/ChangeLog b/gcc/ChangeLog index f17fc102a07..fca25729778 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,15 @@ +2019-12-05 Jozef Lawrynowicz + + * config/msp430/msp430.md (cbranch4): Use + msp430_general_dst_nonv_operand instead of nonimmediate_operand for + dest operand of CMP instruction. + (cbranchpsi4_real): Likewise. + (cbranchqi4_real): Likewise. + (cbranchhi4_real): Likewise. + (cbranchpsi4_reversed): Likewise. + (cbranchqi4_reversed): Likewise. + (cbranchhi4_reversed): Likewise. + 2019-12-05 Richard Biener PR tree-optimization/92803 diff --git a/gcc/config/msp430/msp430.md b/gcc/config/msp430/msp430.md index c3d85071a58..48515b9c26b 100644 --- a/gcc/config/msp430/msp430.md +++ b/gcc/config/msp430/msp430.md @@ -1247,7 +1247,7 @@ (define_expand "cbranch4" [(parallel [(set (pc) (if_then_else (match_operator 0 "" - [(match_operand:QHI 1 "nonimmediate_operand") + [(match_operand:QHI 1 "msp430_general_dst_nonv_operand") (match_operand:QHI 2 "general_operand")]) (label_ref (match_operand 3 "" "")) (pc))) @@ -1260,7 +1260,7 @@ (define_insn "cbranchpsi4_real" [(set (pc) (if_then_else (match_operator 0 "msp430_cmp_operator" - [(match_operand:PSI 1 "nonimmediate_operand" "r,rYs,rm") + [(match_operand:PSI 1 "msp430_general_dst_nonv_operand" "r,rYs,rm") (match_operand:PSI 2 "general_operand" "rLs,rYsi,rmi")]) (label_ref (match_operand 3 "" "")) (pc))) @@ -1276,7 +1276,7 @@ (define_insn "cbranchqi4_real" [(set (pc) (if_then_else (match_operator0 "msp430_cmp_operator" - [(match_operand:QI 1 "nonimmediate_operand" "rYsYx,rm") + [(match_operand:QI 1 "msp430_general_dst_nonv_operand" "rYsYx,rm") (match_operand:QI 2 "general_operand" "rYsYxi,rmi")]) (label_ref (match_operand 3 "" "")) (pc))) @@ -1291,7 +1291,7 @@ (define_insn "cbranchhi4_real" [(set (pc) (if_then_else (match_operator0 "msp430_cmp_operator" - [(match_operand:HI 1 "nonimmediate_operand" "rYsYx,rm") + [(match_operand:HI 1 "msp430_general_dst_nonv_operand" "rYsYx,rm") (match_operand:HI 2 "general_operand" "rYsYxi,rmi")]) (label_ref (match_operand 3 "" "")) (pc))) @@ -1330,7 +1330,7 @@ [(set (pc) (if_then_else (match_operator 0 "msp430_reversible_cmp_operator" [(match_operand:PSI 1 "general_operand" "rLs,rYsi,rmi") - (match_operand:PSI 2 "general_operand" "r,rYs,rm")]) + (match_operand:PSI 2 "msp430_general_dst_nonv_operand" "r,rYs,rm")]) (label_ref (match_operand 3 "" "")) (pc))) (clobber (reg:BI CARRY)) @@ -1346,7 +1346,7 @@ [(set (pc) (if_then_else (match_operator0 "msp430_reversible_cmp
Re: [COMMITTED][MSP430] Fix postinc addressing mode being used for dst operand of CMP insns
On Thu, 5 Dec 2019 08:41:48 -0700 Jeff Law wrote: > On 12/5/19 4:32 AM, Jozef Lawrynowicz wrote: > > MSP430 RTL patterns for conditional branch instructions allow the post > > increment addressing mode to be used for the "dest" operand of CMP > > instructions > > used in these patterns. > > > > This is currently causing trunk to FTB for msp430-elf since these > > instructions > > are being generated using an autoinc for the dest operand, and the > > assembler is > > rejecting them: > > > >> ldtoa.s:1104: Error: this addressing mode is not applicable for > >> destination operand > > > > The attached patch fixes this by using the "msp430_general_dst_nonv_operand" > > predicate instead of the "nonimmediate_operand" predicate for the offending > > RTL > > patterns. > > > > Successfully regtested for msp430-elf on trunk and committed as obvious. > > > Thanks. I suspect that'll bring the msp430 back to "green" state in my > tester. I'd been meaning to bisect that, but I'm fighting multiple > other higher priority issues right now. It looks like it was one of the below commits that exposed the bug, since my tester showed it occurred between r278653 and r278883 (although I didn't actually bisect to it). commit f8c3d03646f08238fe261286470391bb88918660 Author: bernds Date: Wed Nov 27 03:31:24 2019 + Allow autoinc in jumps, but only when using reload. * auto-inc-dec.c (merge_in_block): Allow autoinc in jumps unless LRA is enabled. * combine.c (can_combine_p): Disallow autoinc in jumps unless LRA is disabled. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@278756 138bc75d-0d04-0410-961f-82ee72b054a4 commit 713a306a87bce2c8ed3ab3d4d8b0ecbeaf17f91a Author: bernds Date: Sun Nov 24 13:20:55 2019 + Allow combiner to create autoinc in jump insns. * combine.c (can_combine_p): Allow autoinc in jumps. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@278656 138bc75d-0d04-0410-961f-82ee72b054a4 > > jeff >
Re: [PATCH 2/3] libgcc: Dont define __do_global_dtors_aux if it will be empty
On Mon, 9 Dec 2019 13:19:22 +0100
Tobias Burnus wrote:
> Hi, I see now the following error:
>
> …/libgcc/crtstuff.c:372:52: error: operator '||' has no right operand
>372 | || USE_TM_CLONE_REGISTRY || USE_EH_FRAME_REGISTRY
>|^
> /net/build5-trusty-cs/scratch/tburnus/mainline-nv/src/gcc-mainline/libgcc/crtstuff.c:254:17:
> warning: '__DTOR_LIST__' defined but not used [-Wunused-variable]
>254 | STATIC func_ptr __DTOR_LIST__[1]
>| ^
> Makefile:1038: recipe for target 'crtbeginT.o' failed
>
> Cheers,
>
> Tobias
Sorry, I need to change that to defined(USE_EH_FRAME_REGISTRY). Committing
shortly.
Thanks,
Jozef
>
> On 11/6/19 5:17 PM, Jozef Lawrynowicz wrote:
> > __do_global_dtors_aux in crtstuff.c will not do anything meaningful if:
> > * crtstuff.c is not being compiled for use in a shared library
> > * the target uses .{init,fini}_array sections
> > * TM clone registry is disabled
> > * EH frame registry is disabled
> >
> > The attached patch prevents it from being defined at all if all the above
> > conditions are true. This saves code size in the final linked executable.
> >
> > 0002-libgcc-Dont-define-__do_global_dtors_aux-if-it-will-.patch
> >
> > From 967262117f0c838fe8a9226484bf6e014c86f0ba Mon Sep 17 00:00:00 2001
> > From: Jozef Lawrynowicz
> > Date: Tue, 29 Oct 2019 13:02:08 +
> > Subject: [PATCH 2/3] libgcc: Dont define __do_global_dtors_aux if it will be
> > empty
> >
> > libgcc/ChangeLog:
> >
> > 2019-11-06 Jozef Lawrynowicz
> >
> > * crtstuff.c (__do_global_dtors_aux): Wrap in #if so it's only defined
> > if it will have contents.
> >
> > ---
> > libgcc/crtstuff.c | 9 -
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/libgcc/crtstuff.c b/libgcc/crtstuff.c
> > index 9a3247b7848..0b0a0b865fe 100644
> > --- a/libgcc/crtstuff.c
> > +++ b/libgcc/crtstuff.c
> > @@ -368,8 +368,12 @@ extern void __cxa_finalize (void *)
> > TARGET_ATTRIBUTE_WEAK;
> > On some systems, this routine is run more than once from the .fini,
> > when exit is called recursively, so we arrange to remember where in
> > the list we left off processing, and we resume at that point,
> > - should we be re-invoked. */
> > + should we be re-invoked.
> >
> > + This routine does not need to be run if none of the following clauses
> > are
> > + true, as it will not do anything, so can be removed. */
> > +#if defined(CRTSTUFFS_O) || !defined(FINI_ARRAY_SECTION_ASM_OP) \
> > + || USE_TM_CLONE_REGISTRY || USE_EH_FRAME_REGISTRY
> > static void __attribute__((used))
> > __do_global_dtors_aux (void)
> > {
> > @@ -455,6 +459,9 @@ __do_global_dtors_aux_1 (void)
> > CRT_CALL_STATIC_FUNCTION (__LIBGCC_INIT_SECTION_ASM_OP__,
> > __do_global_dtors_aux_1)
> > #endif
> > +#endif /* defined(CRTSTUFFS_O) || !defined(FINI_ARRAY_SECTION_ASM_OP)
> > + || defined(USE_TM_CLONE_REGISTRY) || defined(USE_EH_FRAME_REGISTRY) */
> > +
> >
> > #if USE_EH_FRAME_REGISTRY || USE_TM_CLONE_REGISTRY
> > /* Stick a call to __register_frame_info into the .init section. For some
> > -- 2.17.1
Re: [PATCH 3/3] libgcc: Implement TARGET_LIBGCC_REMOVE_DSO_HANDLE
On Sat, 07 Dec 2019 11:27:54 -0700
Jeff Law wrote:
> On Wed, 2019-11-06 at 16:19 +0000, Jozef Lawrynowicz wrote:
> > From 7bc0971d2936ebe71e7b7d3d805cf1bbf9f9f5af Mon Sep 17 00:00:00 2001
> > From: Jozef Lawrynowicz
> > Date: Mon, 4 Nov 2019 17:38:13 +
> > Subject: [PATCH 3/3] libgcc: Implement TARGET_LIBGCC_REMOVE_DSO_HANDLE
> >
> > gcc/ChangeLog:
> >
> > 2019-11-06 Jozef Lawrynowicz
> >
> > * doc/tm.texi: Regenerate.
> > * doc/tm.texi.in: Define TARGET_LIBGCC_REMOVE_DSO_HANDLE.
> >
> > libgcc/ChangeLog:
> >
> > 2019-11-06 Jozef Lawrynowicz
> >
> > * crtstuff.c: Don't declare __dso_handle if
> > TARGET_LIBGCC_REMOVE_DSO_HANDLE is defined.
> Presumably you'll switch this on for your bare elf target
> configuration?
Yep that's the plan. I originally didn't include the target changes in
this patch since other target changes (disabling __cxa_atexit) were required for
the removal of __dso_handle to be OK.
>
> Are there other things, particularly related to shared library support,
> that we wouldn't need to use as well? The reason I ask is I'm trying
> to figure out if REMOVE_DSO_HANDLE is the right name or if we should
> generalize it to a name that indicates shared libraries in general
> aren't supported on the target.
CRTSTUFFS_O is defined when compiling shared versions of crt{begin,end} and
handles an extra case in crtstuff.c where there's some shared library related
functionality we don't need on MSP430.
But when CRTSTUFFS_O is undefined __dso_handle is still declared - to 0. The
comment gives some additional insight:
/* Declare the __dso_handle variable. It should have a unique value
in every shared-object; in a main program its value is zero. The
object should in any case be protected. This means the instance
in one DSO or the main program is not used in another object. The
dynamic linker takes care of this. */
I haven't noticed any further shared library-related bloat coming from libgcc.
I think a better way of solving this problem is just to check
DEFAULT_USE_CXA_ATEXIT rather than adding this new macro. If __cxa_atexit is
not enabled then as far as I understand __dso_handle serves no purpose.
DEFAULT_USE_CXA_ATEXIT is defined at configure time for any targets that want
__cxa_atexit support.
A quick bootstrap and test of dg.exp on x86_64-pc-linux-gnu shows no issues
with the following:
> diff --git a/libgcc/crtstuff.c b/libgcc/crtstuff.c
> index ae6328d317d..349f8191e61 100644
> --- a/libgcc/crtstuff.c
> +++ b/libgcc/crtstuff.c
> @@ -340,8 +340,10 @@ extern void *__dso_handle __attribute__ ((__visibility__
> ("hidden")));
> #ifdef CRTSTUFFS_O
> void *__dso_handle = &__dso_handle;
> #else
> +#if DEFAULT_USE_CXA_ATEXIT
> void *__dso_handle = 0;
> #endif
> +#endif
>
> /* The __cxa_finalize function may not be available so we use only a
> weak declaration. */
I'll put that patch through some more rigorous testing.
Thanks,
Jozef
>
> Jeff
Re: [PATCH v2][MSP430] Add msp430-elfbare target
On Sat, 07 Dec 2019 11:40:33 -0700 Jeff Law wrote: > On Fri, 2019-11-29 at 21:00 +0000, Jozef Lawrynowicz wrote: > > The attached patch consolidates some configuration tweaks I > > previously submitted > > as modifications to the msp430-elf target into a new target called > > "msp430-elfbare" i.e. "bare-metal". > > > > MSP430: Disable TM clone registry by default > > https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00550.html > > MSP430: Disable __cxa_atexit > > https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00552.html > > > > The patches tweak the CRT code to achieve the smallest possible code > > size, > > and rely on some additional generic tweaks to crtstuff.c. > > > > I did submit these tweaks a while ago, but I didn't get any feedback, > > however even if they are acceptable I suspect it is too late for GCC- > > 10 anyway: > > libgcc: Dont define __do_global_dtors_aux if it will be empty > > https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00417.html > > libgcc: Implement TARGET_LIBGCC_REMOVE_DSO_HANDLE > > https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00418.html > > > > (The second one is a bit hacky, but without some way of removing the > > __dso_handle declaration, we end up with 150 bytes of unnecessary > > code in some > > programs.) > > > > So for this patch crtstuff.c was copied to the msp430 subdirectory > > and the > > changes were made to that target specific version. > > > > Tiny program size can now be achieved by configuring gcc for msp430- > > elfbare. > > > > For example in an "empty main" program which loops forever: > > msp430-elfbare @ -Os: > > textdata bss dec hex filename > >14 0 0 14 e a.out > > msp430-elf @ -Os: > > textdata bss dec hex filename > > 270 6 2 278 116 a.out > > > > Successfully regtested msp430-elfbare vs msp430-elf. > > > > Ok to apply? > > > > P.S. This patch relies on the -fno-exceptions multilib patch > > submitted here: > > https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02523.html > > > > P.P.S. This requires some minor configury tweaks to Newlib and GDB of > > the form: > > - msp430*-*-elf) > > + msp430-*-elf*) > > > I'll apply these changes if the patch is accepted. > > From cff4611855d838315e793d45256de5fc8eeefafe Mon Sep 17 00:00:00 > > 2001 > > From: Jozef Lawrynowicz > > Date: Mon, 25 Nov 2019 19:41:05 + > > Subject: [PATCH] MSP430: Add new msp430-elfbare target > > > > contrib/ChangeLog: > > > > 2019-11-29 Jozef Lawrynowicz > > > > * config-list.mk: Add msp430-elfbare. > > > > gcc/ChangeLog: > > > > 2019-11-29 Jozef Lawrynowicz > > > > * config.gcc: s/msp430*-*-*/msp430-*-*. > > Handle msp430-*-elfbare. > > * config/msp430/msp430-devices.c (TARGET_SUBDIR): Define. > > (_MSPMKSTR): Define. > > (__MSPMKSTR): Define. > > (rest_of_devices_path): Use TARGET_SUBDIR value in string. > > * config/msp430/msp430.c (msp430_option_override): Error if > > -fuse-cxa-atexit is used when it has been disabled at configure > > time. > > * config/msp430/t-msp430: Define TARGET_SUBDIR when building > > msp430-devices.o. > > * doc/install.texi: Document msp430-*-elf and msp430-*-elfbare. > > * doc/invoke.texi: Update documentation about which path > > devices.csv is > > searched for. > > > > gcc/testsuite/ChangeLog: > > > > 2019-11-29 Jozef Lawrynowicz > > > > * g++.dg/init/dso_handle1.C: Require cxa_atexit support. > > * g++.dg/init/dso_handle2.C: Likewise. > > * g++.dg/other/cxa-atexit1.C: Likewise. > > * gcc.target/msp430/msp430.exp: Update csv-using-installed.c > > test to > > handle msp430-elfbare configuration. > > > > libgcc/ChangeLog: > > > > 2019-11-29 Jozef Lawrynowicz > > > > * config.host: Use t-msp430-elfbare-crtstuff Makefile fragment > > when GCC > > is configured for the msp430-elfbare target. > > * config/msp430/msp430-elfbare-crtstuff.c: New file. > > * config/msp430/t-msp430: Remove Makefile rules for object > > files > > built from crtstuff.c > > * config/msp430/t-msp430-crtstuff: New file. > > * config/msp430/t-msp430-elfbare-crtstuff: New file. > > * configure: Regenerate. > > * configure.ac: Disable TM clone registry by default for > > msp430-elfbare. > OK. I probably would have tried to avoid msp430-elfbare-crtstuff, but > it's not a huge wart IMHO. If we get the __dso_handle removal into the generic libgcc/crtstuff.c those changes won't be necessary. Did you get a chance to look at "Add -fno-exceptions multilib" - https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02523.html It is the cumulative effect of these patches that gives the good code size results, unfortunately without them all there isn't a significant code size improvement. Thanks, Jozef > > Jeff > > >
Re: [PATCH 3/3] libgcc: Implement TARGET_LIBGCC_REMOVE_DSO_HANDLE
On Mon, 9 Dec 2019 13:05:22 +
Jozef Lawrynowicz wrote:
> On Sat, 07 Dec 2019 11:27:54 -0700
> Jeff Law wrote:
>
> > On Wed, 2019-11-06 at 16:19 +, Jozef Lawrynowicz wrote:
> > > From 7bc0971d2936ebe71e7b7d3d805cf1bbf9f9f5af Mon Sep 17 00:00:00 2001
> > > From: Jozef Lawrynowicz
> > > Date: Mon, 4 Nov 2019 17:38:13 +
> > > Subject: [PATCH 3/3] libgcc: Implement TARGET_LIBGCC_REMOVE_DSO_HANDLE
> > >
> > > gcc/ChangeLog:
> > >
> > > 2019-11-06 Jozef Lawrynowicz
> > >
> > > * doc/tm.texi: Regenerate.
> > > * doc/tm.texi.in: Define TARGET_LIBGCC_REMOVE_DSO_HANDLE.
> > >
> > > libgcc/ChangeLog:
> > >
> > > 2019-11-06 Jozef Lawrynowicz
> > >
> > > * crtstuff.c: Don't declare __dso_handle if
> > > TARGET_LIBGCC_REMOVE_DSO_HANDLE is defined.
> > Presumably you'll switch this on for your bare elf target
> > configuration?
>
> Yep that's the plan. I originally didn't include the target changes in
> this patch since other target changes (disabling __cxa_atexit) were required
> for
> the removal of __dso_handle to be OK.
>
> >
> > Are there other things, particularly related to shared library support,
> > that we wouldn't need to use as well? The reason I ask is I'm trying
> > to figure out if REMOVE_DSO_HANDLE is the right name or if we should
> > generalize it to a name that indicates shared libraries in general
> > aren't supported on the target.
>
> CRTSTUFFS_O is defined when compiling shared versions of crt{begin,end} and
> handles an extra case in crtstuff.c where there's some shared library related
> functionality we don't need on MSP430.
>
> But when CRTSTUFFS_O is undefined __dso_handle is still declared - to 0. The
> comment gives some additional insight:
>
> /* Declare the __dso_handle variable. It should have a unique value
>in every shared-object; in a main program its value is zero. The
>object should in any case be protected. This means the instance
>in one DSO or the main program is not used in another object. The
>dynamic linker takes care of this. */
>
> I haven't noticed any further shared library-related bloat coming from libgcc.
>
> I think a better way of solving this problem is just to check
> DEFAULT_USE_CXA_ATEXIT rather than adding this new macro. If __cxa_atexit is
> not enabled then as far as I understand __dso_handle serves no purpose.
> DEFAULT_USE_CXA_ATEXIT is defined at configure time for any targets that want
> __cxa_atexit support.
>
> A quick bootstrap and test of dg.exp on x86_64-pc-linux-gnu shows no issues
> with the following:
>
> > diff --git a/libgcc/crtstuff.c b/libgcc/crtstuff.c
> > index ae6328d317d..349f8191e61 100644
> > --- a/libgcc/crtstuff.c
> > +++ b/libgcc/crtstuff.c
> > @@ -340,8 +340,10 @@ extern void *__dso_handle __attribute__
> > ((__visibility__ ("hidden")));
> > #ifdef CRTSTUFFS_O
> > void *__dso_handle = &__dso_handle;
> > #else
> > +#if DEFAULT_USE_CXA_ATEXIT
> > void *__dso_handle = 0;
> > #endif
> > +#endif
> >
> > /* The __cxa_finalize function may not be available so we use only a
> > weak declaration. */
>
> I'll put that patch through some more rigorous testing.
Successfully bootstrapped and regtested the attached patch for
x86_64-pc-linux-gnu (where DEFAULT_USE_CXA_ATEXIT is set to 1) and the proposed
msp430-elfbare target (where DEFAULT_USE_CXA_ATEXIT is set to 0).
Ok to apply?
>
> Thanks,
> Jozef
> >
> > Jeff
>From fc2564803c33229184926a5ac6db62ae36ea8d77 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Mon, 9 Dec 2019 15:20:23 +
Subject: [PATCH] libgcc: Only define __dso_handle if DEFAULT_USE_CXA_ATEXIT is
true
libgcc/ChangeLog:
2019-12-11 Jozef Lawrynowicz
* crtstuff.c: Declare __dso_handle only if DEFAULT_USE_CXA_ATEXIT is
true.
---
libgcc/crtstuff.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/libgcc/crtstuff.c b/libgcc/crtstuff.c
index 9346cc5ca54..e282cb1aabb 100644
--- a/libgcc/crtstuff.c
+++ b/libgcc/crtstuff.c
@@ -325,11 +325,14 @@ register_tm_clones (void)
#ifdef OBJECT_FORMAT_ELF
+#if DEFAULT_USE_CXA_ATEXIT
/* Declare the __dso_handle variable. It should have a unique value
in every shared-object; in a main program its value is zero. The
object should in any case be protected. This means the instance
in one DSO or the main program is not used in another object. The
- dynamic linker takes care of this. */
+ dynamic linker takes care of this.
+ If __cxa_atexit is not being used, __dso_handle will not be used and
+ doesn't need to be defined. */
#ifdef TARGET_LIBGCC_SDATA_SECTION
extern void *__dso_handle __attribute__ ((__section__ (TARGET_LIBGCC_SDATA_SECTION)));
@@ -342,6 +345,7 @@ void *__dso_handle = &__dso_handle;
#else
void *__dso_handle = 0;
#endif
+#endif /* DEFAULT_USE_CXA_ATEXIT */
/* The __cxa_finalize function may not be available so we use only a
weak declaration. */
--
2.17.1
Re: [PATCH v2][MSP430] Add msp430-elfbare target
On Mon, 9 Dec 2019 15:28:25 + Jozef Lawrynowicz wrote: > On Sat, 07 Dec 2019 11:40:33 -0700 > Jeff Law wrote: > > > On Fri, 2019-11-29 at 21:00 +, Jozef Lawrynowicz wrote: > > > The attached patch consolidates some configuration tweaks I > > > previously submitted > > > as modifications to the msp430-elf target into a new target called > > > "msp430-elfbare" i.e. "bare-metal". > > > > > > MSP430: Disable TM clone registry by default > > > https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00550.html > > > MSP430: Disable __cxa_atexit > > > https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00552.html > > > > > > The patches tweak the CRT code to achieve the smallest possible code > > > size, > > > and rely on some additional generic tweaks to crtstuff.c. > > > > > > I did submit these tweaks a while ago, but I didn't get any feedback, > > > however even if they are acceptable I suspect it is too late for GCC- > > > 10 anyway: > > > libgcc: Dont define __do_global_dtors_aux if it will be empty > > > https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00417.html > > > libgcc: Implement TARGET_LIBGCC_REMOVE_DSO_HANDLE > > > https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00418.html > > > > > > (The second one is a bit hacky, but without some way of removing the > > > __dso_handle declaration, we end up with 150 bytes of unnecessary > > > code in some > > > programs.) > > > > > > So for this patch crtstuff.c was copied to the msp430 subdirectory > > > and the > > > changes were made to that target specific version. > > > > > > Tiny program size can now be achieved by configuring gcc for msp430- > > > elfbare. > > > > > > For example in an "empty main" program which loops forever: > > > msp430-elfbare @ -Os: > > > textdata bss dec hex filename > > >14 0 0 14 e a.out > > > msp430-elf @ -Os: > > > textdata bss dec hex filename > > > 270 6 2 278 116 a.out > > > > > > Successfully regtested msp430-elfbare vs msp430-elf. > > > > > > Ok to apply? > > > > > > P.S. This patch relies on the -fno-exceptions multilib patch > > > submitted here: > > > https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02523.html > > > > > > P.P.S. This requires some minor configury tweaks to Newlib and GDB of > > > the form: > > > - msp430*-*-elf) > > > + msp430-*-elf*) > > > > > I'll apply these changes if the patch is accepted. > > > From cff4611855d838315e793d45256de5fc8eeefafe Mon Sep 17 00:00:00 > > > 2001 > > > From: Jozef Lawrynowicz > > > Date: Mon, 25 Nov 2019 19:41:05 + > > > Subject: [PATCH] MSP430: Add new msp430-elfbare target > > > > > > contrib/ChangeLog: > > > > > > 2019-11-29 Jozef Lawrynowicz > > > > > > * config-list.mk: Add msp430-elfbare. > > > > > > gcc/ChangeLog: > > > > > > 2019-11-29 Jozef Lawrynowicz > > > > > > * config.gcc: s/msp430*-*-*/msp430-*-*. > > > Handle msp430-*-elfbare. > > > * config/msp430/msp430-devices.c (TARGET_SUBDIR): Define. > > > (_MSPMKSTR): Define. > > > (__MSPMKSTR): Define. > > > (rest_of_devices_path): Use TARGET_SUBDIR value in string. > > > * config/msp430/msp430.c (msp430_option_override): Error if > > > -fuse-cxa-atexit is used when it has been disabled at configure > > > time. > > > * config/msp430/t-msp430: Define TARGET_SUBDIR when building > > > msp430-devices.o. > > > * doc/install.texi: Document msp430-*-elf and msp430-*-elfbare. > > > * doc/invoke.texi: Update documentation about which path > > > devices.csv is > > > searched for. > > > > > > gcc/testsuite/ChangeLog: > > > > > > 2019-11-29 Jozef Lawrynowicz > > > > > > * g++.dg/init/dso_handle1.C: Require cxa_atexit support. > > > * g++.dg/init/dso_handle2.C: Likewise. > > > * g++.dg/other/cxa-atexit1.C: Likewise. > > > * gcc.target/msp430/msp430.exp: Update csv-using-installed.c > > > test to > > > handle msp430-elfbare configuration. > > > > > > libgcc/ChangeLog: > > > > > > 2019-11-29 Joz
Re: [PATCH v2][MSP430] Add msp430-elfbare target
On Wed, 11 Dec 2019 12:19:41 + Jozef Lawrynowicz wrote: > On Mon, 9 Dec 2019 15:28:25 + > Jozef Lawrynowicz wrote: > > > On Sat, 07 Dec 2019 11:40:33 -0700 > > Jeff Law wrote: > > > > > On Fri, 2019-11-29 at 21:00 +, Jozef Lawrynowicz wrote: > > > > The attached patch consolidates some configuration tweaks I > > > > previously submitted > > > > as modifications to the msp430-elf target into a new target called > > > > "msp430-elfbare" i.e. "bare-metal". > > > > > > > > MSP430: Disable TM clone registry by default > > > > https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00550.html > > > > MSP430: Disable __cxa_atexit > > > > https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00552.html > > > > > > > > The patches tweak the CRT code to achieve the smallest possible code > > > > size, > > > > and rely on some additional generic tweaks to crtstuff.c. > > > > > > > > I did submit these tweaks a while ago, but I didn't get any feedback, > > > > however even if they are acceptable I suspect it is too late for GCC- > > > > 10 anyway: > > > > libgcc: Dont define __do_global_dtors_aux if it will be empty > > > > https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00417.html > > > > libgcc: Implement TARGET_LIBGCC_REMOVE_DSO_HANDLE > > > > https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00418.html > > > > > > > > (The second one is a bit hacky, but without some way of removing the > > > > __dso_handle declaration, we end up with 150 bytes of unnecessary > > > > code in some > > > > programs.) > > > > > > > > So for this patch crtstuff.c was copied to the msp430 subdirectory > > > > and the > > > > changes were made to that target specific version. > > > > > > > > Tiny program size can now be achieved by configuring gcc for msp430- > > > > elfbare. > > > > > > > > For example in an "empty main" program which loops forever: > > > > msp430-elfbare @ -Os: > > > > textdata bss dec hex filename > > > >14 0 0 14 e a.out > > > > msp430-elf @ -Os: > > > > textdata bss dec hex filename > > > > 270 6 2 278 116 a.out > > > > > > > > Successfully regtested msp430-elfbare vs msp430-elf. > > > > > > > > Ok to apply? > > > > > > > > P.S. This patch relies on the -fno-exceptions multilib patch > > > > submitted here: > > > > https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02523.html > > > > > > > > P.P.S. This requires some minor configury tweaks to Newlib and GDB of > > > > the form: > > > > - msp430*-*-elf) > > > > + msp430-*-elf*) > > > > > > > I'll apply these changes if the patch is accepted. > > > > From cff4611855d838315e793d45256de5fc8eeefafe Mon Sep 17 00:00:00 > > > > 2001 > > > > From: Jozef Lawrynowicz > > > > Date: Mon, 25 Nov 2019 19:41:05 + > > > > Subject: [PATCH] MSP430: Add new msp430-elfbare target > > > > > > > > contrib/ChangeLog: > > > > > > > > 2019-11-29 Jozef Lawrynowicz > > > > > > > > * config-list.mk: Add msp430-elfbare. > > > > > > > > gcc/ChangeLog: > > > > > > > > 2019-11-29 Jozef Lawrynowicz > > > > > > > > * config.gcc: s/msp430*-*-*/msp430-*-*. > > > > Handle msp430-*-elfbare. > > > > * config/msp430/msp430-devices.c (TARGET_SUBDIR): Define. > > > > (_MSPMKSTR): Define. > > > > (__MSPMKSTR): Define. > > > > (rest_of_devices_path): Use TARGET_SUBDIR value in string. > > > > * config/msp430/msp430.c (msp430_option_override): Error if > > > > -fuse-cxa-atexit is used when it has been disabled at configure > > > > time. > > > > * config/msp430/t-msp430: Define TARGET_SUBDIR when building > > > > msp430-devices.o. > > > > * doc/install.texi: Document msp430-*-elf and msp430-*-elfbare. > > > > * doc/invoke.texi: Update documentation about which path >
Re: [PATCH] Implement P0966 std::string::reserve should not shrink
Hi, On Thu, Aug 06, 2020 at 06:48:36PM +, Jonathan Wakely via Gcc-patches wrote: > > I've now pushed that combined patch to master. In libstdc++-v3/include/bits/basic_string.tcc around line 1190, there's a missing "#if __cpp_exceptions" test for the try/catch block that was added by this patch. That prevents libstdc++ building with -fno-exceptions. Thanks, Jozef
[PATCH] doc: Update documentation on MODE_PARTIAL_INT subregs
In d8487c949ad5 (~GCC 4.9.0), MODE_PARTIAL_INT modes were changed from
having an unknown number of undefined bits, to having a known number of
undefined bits, however the documentation on using SUBREG expressions
with MODE_PARTIAL_INT modes was not updated to reflect this.
The attached patch updates that portion of the GCC internals
documentation.
Ok for trunk?
>From e195dce328b272cd413ca7c659b800170eb60f2c Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Mon, 31 Aug 2020 17:26:31 +0100
Subject: [PATCH] doc: Update documentation on MODE_PARTIAL_INT subregs
In d8487c949ad5, MODE_PARTIAL_INT modes were changed from having an
unknown number of undefined bits, to having a known number of undefined
bits, however the documentation on using SUBREG expressions with
MODE_PARTIAL_INT modes was not updated to reflect this.
gcc/ChangeLog:
* doc/rtl.texi (subreg): Fix documentation to state there is a known
number of undefined bits in regs and subregs of MODE_PARTIAL_INT modes.
---
gcc/doc/rtl.texi | 30 ++
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/gcc/doc/rtl.texi b/gcc/doc/rtl.texi
index f8e1f950823..4760bb97d52 100644
--- a/gcc/doc/rtl.texi
+++ b/gcc/doc/rtl.texi
@@ -2209,17 +2209,22 @@ whether the subreg is a lowpart of a block.
@end table
A @code{MODE_PARTIAL_INT} mode behaves as if it were as wide as the
-corresponding @code{MODE_INT} mode, except that it has an unknown
-number of undefined bits. For example:
+corresponding @code{MODE_INT} mode, except that it has a number of
+undefined bits, which are determined by the precision of the
+mode.
+
+For example, on a little-endian target which defines @code{PSImode}
+to have a precision of 20 bits:
@smallexample
(subreg:PSI (reg:SI 0) 0)
@end smallexample
+accesses the low 20 bits of @samp{(reg:SI 0)}.
+
@findex REGMODE_NATURAL_SIZE
-accesses the whole of @samp{(reg:SI 0)}, but the exact relationship
-between the @code{PSImode} value and the @code{SImode} value is not
-defined. If we assume @samp{REGMODE_NATURAL_SIZE (DImode) <= 4},
+Continuing with a @code{PSImode} precision of 20 bits, if we assume
+@samp{REGMODE_NATURAL_SIZE (DImode) <= 4},
then the following two @code{subreg}s:
@smallexample
@@ -2227,9 +2232,8 @@ then the following two @code{subreg}s:
(subreg:PSI (reg:DI 0) 4)
@end smallexample
-represent independent 4-byte accesses to the two halves of
-@samp{(reg:DI 0)}. Both @code{subreg}s have an unknown number
-of undefined bits.
+represent accesses to the low 20 bits of the two halves of
+@samp{(reg:DI 0)}.
If @samp{REGMODE_NATURAL_SIZE (PSImode) <= 2} then these two @code{subreg}s:
@@ -2240,15 +2244,17 @@ If @samp{REGMODE_NATURAL_SIZE (PSImode) <= 2} then
these two @code{subreg}s:
represent independent 2-byte accesses that together span the whole
of @samp{(reg:PSI 0)}. Storing to the first @code{subreg} does not
-affect the value of the second, and vice versa. @samp{(reg:PSI 0)}
-has an unknown number of undefined bits, so the assignment:
+affect the value of the second, and vice versa, so the assignment:
@smallexample
(set (subreg:HI (reg:PSI 0) 0) (reg:HI 4))
@end smallexample
-does not guarantee that @samp{(subreg:HI (reg:PSI 0) 0)} has the
-value @samp{(reg:HI 4)}.
+sets the low 16 bits of @samp{(reg:PSI 0)} to @samp{(reg:HI 4)}, and
+the high 4 defined bits of @samp{(reg:PSI 0)} retain their
+original value. The behavior here is therefore the same as
+normal @code{subreg}s, when there are no
+@code{MODE_PARTIAL_INT} modes involved.
@cindex @code{TARGET_CAN_CHANGE_MODE_CLASS} and subreg semantics
The rules above apply to both pseudo @var{reg}s and hard @var{reg}s.
--
2.28.0
[committed] MSP430: Skip gcc.dg/pr55940.c in the small memory model
In the MSP430 small memory model, there is a 16-bit address space and
pointer arithmetic wraps around the address space, so any calculated
address is always within this range.
In this test, pointer arithmetic wraps when 0x1000 is added to the
address of a variable, causing the resulting address to be unexpectedly
less than 0x2000, which breaks the test.
Committed as obvious.
>From d45a6c7099a346153e970476688be5bd6a016cef Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Wed, 2 Sep 2020 13:42:39 +0100
Subject: [PATCH] MSP430: Skip gcc.dg/pr55940.c in the small memory model
In the MSP430 small memory model, there is a 16-bit address space and
pointer arithmetic wraps around the address space, so any calculated
address is always within this range.
In this test, pointer arithmetic wraps when 0x1000 is added to the
address of a variable, causing the resulting address to be unexpectedly
less than 0x2000, which breaks the test.
gcc/testsuite/ChangeLog:
* gcc.dg/pr55940.c: Skip for msp430 unless -mlarge is specified.
---
gcc/testsuite/gcc.dg/pr55940.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/testsuite/gcc.dg/pr55940.c b/gcc/testsuite/gcc.dg/pr55940.c
index d046d0b6912..85761f6c31f 100644
--- a/gcc/testsuite/gcc.dg/pr55940.c
+++ b/gcc/testsuite/gcc.dg/pr55940.c
@@ -1,5 +1,6 @@
/* PR target/55940 */
/* { dg-do run } */
+/* { dg-skip-if "pointer arithmetic can wrap" { msp430-*-* } { "*" } {
"-mlarge" } } */
/* { dg-options "-Os" } */
/* { dg-additional-options "-mpreferred-stack-boundary=2" { target { {
i?86-*-* x86_64-*-* } && ia32 } } } */
--
2.28.0
[committed] MSP430: Fix -mlarge documentation to indicate size_t is a 20-bit type
Minor documentation fix, committed as obvious.
>From 0edc2c1a2445dffc7b839d833263c78f7cab01dc Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Wed, 2 Sep 2020 16:34:43 +0100
Subject: [PATCH] MSP430: Fix -mlarge documentation to indicate size_t is a
20-bit type
gcc/ChangeLog:
* doc/invoke.texi (MSP430 options): Fix -mlarge description to
indicate size_t is a 20-bit type.
---
gcc/doc/invoke.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 5d29a7fa23c..bca8c856dc8 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -24777,7 +24777,7 @@ any scripts that would be selected by the
@option{-mmcu=} option.
@item -mlarge
@opindex mlarge
-Use large-model addressing (20-bit pointers, 32-bit @code{size_t}).
+Use large-model addressing (20-bit pointers, 20-bit @code{size_t}).
@item -msmall
@opindex msmall
--
2.28.0
[committed] MSP430: Don't override default ISA when MCU name is unrecognized
430X is the default ISA under normal operation, so even when the MCU name
passed to -mmcu= is unrecognized, it should not be overriden.
Committed as obvious.
>From 7f87e446691f1debfe2671a40f8738bd5e128832 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Mon, 7 Sep 2020 17:35:04 +0100
Subject: [PATCH] MSP430: Don't override default ISA when MCU name is
unrecognized
430X is the default ISA under normal operation, so even when the MCU name
passed to -mmcu= is unrecognized, it should not be overriden.
gcc/ChangeLog:
* config/msp430/msp430.c (msp430_option_override): Don't set the
ISA to 430 when the MCU is unrecognized.
gcc/testsuite/ChangeLog:
* gcc.target/msp430/430x-default-isa.c: New test.
---
gcc/config/msp430/msp430.c | 11 ++-
gcc/testsuite/gcc.target/msp430/430x-default-isa.c | 10 ++
2 files changed, 12 insertions(+), 9 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/msp430/430x-default-isa.c
diff --git a/gcc/config/msp430/msp430.c b/gcc/config/msp430/msp430.c
index c2b24974364..129b916715e 100644
--- a/gcc/config/msp430/msp430.c
+++ b/gcc/config/msp430/msp430.c
@@ -223,7 +223,7 @@ msp430_option_override (void)
if (target_cpu == NULL)
warning (0,
"Unrecognized MCU name %qs, assuming that it is "
-"just a MSP430 with no hardware multiply.\n"
+"just a MSP430X with no hardware multiply.\n"
"Use the %<-mcpu%> and %<-mhwmult%> options to "
"set these explicitly.",
target_mcu);
@@ -242,22 +242,15 @@ msp430_option_override (void)
if (msp430_warn_mcu)
warning (0,
"Unrecognized MCU name %qs, assuming that it just "
-"supports the MSP430 ISA.\nUse the %<-mcpu%> option "
+"supports the MSP430X ISA.\nUse the %<-mcpu%> option "
"to set the ISA explicitly.",
target_mcu);
-
- msp430x = false;
}
else if (msp430_warn_mcu)
warning (0, "Unrecognized MCU name %qs.", target_mcu);
}
}
- /* The F5 series are all able to support the 430X ISA. */
- if (target_cpu == NULL && target_mcu == NULL
- && msp430_hwmult_type == MSP430_HWMULT_F5SERIES)
-msp430x = true;
-
if (TARGET_LARGE && !msp430x)
error ("%<-mlarge%> requires a 430X-compatible %<-mmcu=%>");
diff --git a/gcc/testsuite/gcc.target/msp430/430x-default-isa.c
b/gcc/testsuite/gcc.target/msp430/430x-default-isa.c
new file mode 100644
index 000..4e8077786b0
--- /dev/null
+++ b/gcc/testsuite/gcc.target/msp430/430x-default-isa.c
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-skip-if "" { *-*-* } { "-mcpu=*" "-mmcu=*" } } */
+/* { dg-options "-mmcu=msp430foobar -mno-warn-mcu -mno-warn-devices-csv" } */
+
+/* Verify that the default ISA is set to 430X when the MCU passed to -mmcu= is
+ unrecognized. */
+
+#ifndef __MSP430X__
+#error
+#endif
--
2.28.0
Re: [PATCH] doc: Update documentation on MODE_PARTIAL_INT subregs
On Mon, Sep 07, 2020 at 01:55:59PM +0100, Richard Sandiford wrote:
> Jozef Lawrynowicz writes:
> > In d8487c949ad5 (~GCC 4.9.0), MODE_PARTIAL_INT modes were changed from
> > having an unknown number of undefined bits, to having a known number of
> > undefined bits, however the documentation on using SUBREG expressions
> > with MODE_PARTIAL_INT modes was not updated to reflect this.
> >
> > The attached patch updates that portion of the GCC internals
> > documentation.
> >
> > Ok for trunk?
>
> Thanks for doing this. OK for trunk with one very minor nit:
>
> > -does not guarantee that @samp{(subreg:HI (reg:PSI 0) 0)} has the
> > -value @samp{(reg:HI 4)}.
> > +sets the low 16 bits of @samp{(reg:PSI 0)} to @samp{(reg:HI 4)}, and
> > +the high 4 defined bits of @samp{(reg:PSI 0)} retain their
> > +original value. The behavior here is therefore the same as
>
> IMO reads more naturally as “the same as for”.
>
> Richard
>
> > +normal @code{subreg}s, when there are no
> > +@code{MODE_PARTIAL_INT} modes involved.
> >
Thanks, fixed and applied.
Jozef
[committed] MSP430: Use enums to handle -mcpu= values
The -mcpu= option accepts only a handful of string values.
Using enums instead of strings to handle the accepted values removes the
need to have specific processing of the strings in the backend, and
simplifies any comparisons that need to be performed on the value.
It also allows the default value to have semantic equivalence to a user
set value, whilst retaining the ability to differentiate between them.
Practically, this allows a user set -mcpu= value to override the the ISA set by
-mmcu, whilst the default -mcpu= value can still have an explicit meaning.
Successfully regtested on trunk.
Committed as obvious.
>From cd2d3822ca0f2f743601cc9d048d51f6d326f6a2 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Tue, 8 Sep 2020 10:10:17 +0100
Subject: [PATCH] MSP430: Use enums to handle -mcpu= values
The -mcpu= option accepts only a handful of string values.
Using enums instead of strings to handle the accepted values removes the
need to have specific processing of the strings in the backend, and
simplifies any comparisons which need to be performed on the value.
It also allows the default value to have semantic equivalence to a user
set value, whilst retaining the ability to differentiate between them.
Practically, this allows a user set -mcpu= value to override the the ISA set by
-mmcu, whilst the default -mcpu= value can still have an explicit meaning.
gcc/ChangeLog:
* common/config/msp430/msp430-common.c (msp430_handle_option): Remove
OPT_mcpu_ handling.
Set target_cpu value to new enum values when parsing certain -mmcu=
values.
* config/msp430/msp430-opts.h (enum msp430_cpu_types): New.
* config/msp430/msp430.c (msp430_option_override): Handle new
target_cpu enum values.
Set target_cpu using extracted value for given MCU when -mcpu=
option is not passed by the user.
* config/msp430/msp430.opt: Handle -mcpu= values using enums.
gcc/testsuite/ChangeLog:
* gcc.target/msp430/mcpu-is-430.c: New test.
* gcc.target/msp430/mcpu-is-430x.c: New test.
* gcc.target/msp430/mcpu-is-430xv2.c: New test.
---
gcc/common/config/msp430/msp430-common.c | 26 +++
gcc/config/msp430/msp430-opts.h | 12 +
gcc/config/msp430/msp430.c| 21 ++-
gcc/config/msp430/msp430.opt | 23 +++-
gcc/testsuite/gcc.target/msp430/mcpu-is-430.c | 10 +++
.../gcc.target/msp430/mcpu-is-430x.c | 12 +
.../gcc.target/msp430/mcpu-is-430xv2.c| 13 ++
7 files changed, 80 insertions(+), 37 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/msp430/mcpu-is-430.c
create mode 100644 gcc/testsuite/gcc.target/msp430/mcpu-is-430x.c
create mode 100644 gcc/testsuite/gcc.target/msp430/mcpu-is-430xv2.c
diff --git a/gcc/common/config/msp430/msp430-common.c
b/gcc/common/config/msp430/msp430-common.c
index 0e261c40015..65be3194683 100644
--- a/gcc/common/config/msp430/msp430-common.c
+++ b/gcc/common/config/msp430/msp430-common.c
@@ -27,7 +27,7 @@
#include "opts.h"
#include "flags.h"
-/* Check for generic -mcpu= and -mmcu= names here. If found then we
+/* Check for generic -mmcu= names here. If found then we
convert to a baseline cpu name. Otherwise we allow the option to
be passed on to the backend where it can be checked more fully. */
@@ -39,26 +39,6 @@ msp430_handle_option (struct gcc_options *opts
ATTRIBUTE_UNUSED,
{
switch (decoded->opt_index)
{
-case OPT_mcpu_:
- if (strcasecmp (decoded->arg, "msp430x") == 0
- || strcasecmp (decoded->arg, "msp430xv2") == 0
- || strcasecmp (decoded->arg, "430x") == 0
- || strcasecmp (decoded->arg, "430xv2") == 0)
- {
- target_cpu = "msp430x";
- }
- else if (strcasecmp (decoded->arg, "msp430") == 0
- || strcasecmp (decoded->arg, "430") == 0)
- {
- target_cpu = "msp430";
- }
- else
- {
- error ("unrecognized argument of %<-mcpu%>: %s", decoded->arg);
- return false;
- }
- break;
-
case OPT_mmcu_:
/* For backwards compatibility we recognise two generic MCU
430X names. However we want to be able to generate special C
@@ -66,13 +46,13 @@ msp430_handle_option (struct gcc_options *opts
ATTRIBUTE_UNUSED,
to NULL. */
if (strcasecmp (decoded->arg, "msp430") == 0)
{
- target_cpu = "msp430";
+ target_cpu = MSP430_CPU_MSP430;
target_mcu = NULL;
}
else if (strcasecmp (decoded->arg, "msp430x") == 0
|| strcasecmp (decoded->arg, "msp430xv2") == 0)
{
- target_cpu = "msp430x";
+ target_cpu = MSP430_CPU_
[committed] MSP430: Fix detection of assembler support for .mspabi_attribute
The assembly code ".mspabi_attribute 4,1" uses the object attribute
mechanism to indicate that the 430 ISA is in use. However, the default
ISA is 430X, so GAS fails to assemble this since the ISA wasn't also set
to 430 on the command line.
Successfully regtested msp430.exp. This fixes the object attribute tests
when GAS hasn't been built using a unified source tree alongside GCC.
Committed as obvious.
>From b75863a88ececd4fcce9e3b35df8d91b82cf4fc5 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Tue, 8 Sep 2020 11:31:02 +0100
Subject: [PATCH] MSP430: Fix detection of assembler support for
.mspabi_attribute
The assembly code ".mspabi_attribute 4,1" uses the object attribute
mechanism to indicate that the 430 ISA is in use. However, the default
ISA is 430X, so GAS fails to assemble this since the ISA wasn't also set
to 430 on the command line.
gcc/ChangeLog:
* config/msp430/msp430.c (msp430_file_end): Fix jumbled
HAVE_AS_MSPABI_ATTRIBUTE and HAVE_AS_GNU_ATTRIBUTE checks.
* configure: Regenerate.
* configure.ac: Use ".mspabi_attribute 4,2" to check for assembler
support for this object attribute directive.
---
gcc/config/msp430/msp430.c | 4 ++--
gcc/configure | 2 +-
gcc/configure.ac | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/gcc/config/msp430/msp430.c b/gcc/config/msp430/msp430.c
index d0557fe9058..a299ed7f9d1 100644
--- a/gcc/config/msp430/msp430.c
+++ b/gcc/config/msp430/msp430.c
@@ -2091,7 +2091,7 @@ msp430_output_aligned_decl_common (FILE *
stream,
static void
msp430_file_end (void)
{
-#ifdef HAVE_AS_GNU_ATTRIBUTE
+#ifdef HAVE_AS_MSPABI_ATTRIBUTE
/* Enum for tag names. */
enum
{
@@ -2130,7 +2130,7 @@ msp430_file_end (void)
OFBA_MSPABI_Tag_Data_Model,
TARGET_LARGE ? OFBA_MSPABI_Val_Model_Large
: OFBA_MSPABI_Val_Model_Small);
-#ifdef HAVE_AS_MSPABI_ATTRIBUTE
+#ifdef HAVE_AS_GNU_ATTRIBUTE
/* Emit .gnu_attribute directive for Tag_GNU_MSP430_Data_Region. */
fprintf (asm_out_file, "\t%s %d, %d\n", gnu_attr, Tag_GNU_MSP430_Data_Region,
msp430_data_region == MSP430_REGION_LOWER
diff --git a/gcc/configure b/gcc/configure
index 0f7a8dbe0f9..0a09777dd42 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -27981,7 +27981,7 @@ else
then gcc_cv_as_msp430_mspabi_attribute=yes
fi
elif test x$gcc_cv_as != x; then
-$as_echo '.mspabi_attribute 4,1' > conftest.s
+$as_echo '.mspabi_attribute 4,2' > conftest.s
if { ac_try='$gcc_cv_as $gcc_cv_as_flags -o conftest.o conftest.s >&5'
{ { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
(eval $ac_try) 2>&5
diff --git a/gcc/configure.ac b/gcc/configure.ac
index 0f11238c19f..6a233a3c706 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -5041,7 +5041,7 @@ pointers into PC-relative form.])
[Define if your assembler supports .gnu_attribute.])])
gcc_GAS_CHECK_FEATURE([.mspabi_attribute support],
gcc_cv_as_msp430_mspabi_attribute, [2,33,50],,
- [.mspabi_attribute 4,1],,
+ [.mspabi_attribute 4,2],,
[AC_DEFINE(HAVE_AS_MSPABI_ATTRIBUTE, 1,
[Define if your assembler supports .mspabi_attribute.])])
if test x$enable_newlib_nano_formatted_io = xyes; then
--
2.28.0
[PATCH] MSP430: Fix CFA generation during function epilogues
There is no CFA information generated for instructions which manipulate the
stack during function epilogues. This means a debugger cannot determine the
position of variables on the stack whilst the epilogue is in progress.
This can cause the debugger to give erroneous information when printing a
backtrace whilst stepping through the epilogue, or cause software watchpoints
set on stack variables to become invalidated after a function epilogue
is executed.
The patch fixes this by marking stack manipulation insns as
frame_related, and adding reg_note RTXs to stack pop instructions in the
epilogue.
Successfully regtested on trunk for msp430-elf in the default, -mlarge,
-mcpu=msp430 and -mlarge/-mcode-region=either/-mdata-region=either
configurations.
This fixes some tests from watchpoint.exp in the GDB testsuite.
Ok for trunk?
Thanks,
Jozef
>From 272b38a374eddf7327a61ff9b1730f0a2dd40233 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Mon, 7 Sep 2020 20:34:40 +0100
Subject: [PATCH] MSP430: Fix CFA generation during function epilogues
There is no CFA information generated for instructions which manipulate the
stack during function epilogues. This means a debugger cannot determine the
position of variables on the stack whilst the epilogue is in progress.
This can cause the debugger to give erroneous information when printing a
backtrace whilst stepping through the epilogue, or cause software watchpoints
set on stack variables to become invalidated after a function epilogue
is executed.
The patch fixes this by marking stack manipulation insns as
frame_related, and adding reg_note RTXs to stack pop instructions in the
epilogue.
gcc/ChangeLog:
* config/msp430/msp430.c (increment_stack): Mark insns which increment
the stack as frame_related.
(msp430_expand_prologue): Add comments.
(msp430_expand_epilogue): Mark insns which decrement
the stack as frame_related.
Add reg_note to stack pop insns describing position of register
variables on the stack.
---
gcc/config/msp430/msp430.c | 72 +++---
1 file changed, 59 insertions(+), 13 deletions(-)
diff --git a/gcc/config/msp430/msp430.c b/gcc/config/msp430/msp430.c
index 129b916715e..1cb1b8f8626 100644
--- a/gcc/config/msp430/msp430.c
+++ b/gcc/config/msp430/msp430.c
@@ -1700,9 +1700,9 @@ increment_stack (HOST_WIDE_INT amount)
{
inc = GEN_INT (amount);
if (TARGET_LARGE)
- emit_insn (gen_addpsi3 (sp, sp, inc));
+ F (emit_insn (gen_addpsi3 (sp, sp, inc)));
else
- emit_insn (gen_addhi3 (sp, sp, inc));
+ F (emit_insn (gen_addhi3 (sp, sp, inc)));
}
}
@@ -2413,6 +2413,8 @@ msp430_expand_prologue (void)
for (i = 15; i >= 4; i--)
if (cfun->machine->need_to_save[i])
{
+ /* We need to save COUNT sequential registers starting from regnum
+ I. */
int seq, count;
rtx note;
@@ -2427,6 +2429,7 @@ msp430_expand_prologue (void)
p = F (emit_insn (gen_pushm (gen_rtx_REG (Pmode, i),
GEN_INT (count;
+ /* Document the stack decrement as a result of PUSHM. */
note = gen_rtx_SEQUENCE (VOIDmode, rtvec_alloc (count + 1));
XVECEXP (note, 0, 0)
@@ -2475,8 +2478,10 @@ msp430_expand_prologue (void)
void
msp430_expand_epilogue (int is_eh)
{
- int i;
+ int i, j;
int fs;
+ rtx sp = stack_pointer_rtx;
+ rtx p;
int helper_n = 0;
if (is_naked_func ())
@@ -2545,19 +2550,27 @@ msp430_expand_epilogue (int is_eh)
for (i = 4; i <= 15; i++)
if (cfun->machine->need_to_save[i])
{
- int seq, count;
+ /* We need to restore COUNT sequential registers starting from regnum
+ I. */
+ int seq;
+ int count = 1;
+ int helper_used = 0;
+ rtx note, addr;
- for (seq = i + 1; seq <= 15 && cfun->machine->need_to_save[seq]; seq ++)
- ;
- count = seq - i;
+ if (msp430x)
+ {
+ for (seq = i + 1; seq <= 15 && cfun->machine->need_to_save[seq];
+seq++)
+ ;
+ count = seq - i;
+ }
if (msp430x)
{
/* Note: With TARGET_LARGE we still use
POPM as POPX.A is two bytes bigger. */
- emit_insn (gen_popm (stack_pointer_rtx, GEN_INT (seq - 1),
-GEN_INT (count)));
- i += count - 1;
+ p = F (emit_insn (gen_popm (stack_pointer_rtx, GEN_INT (seq - 1),
+ GEN_INT (count;
}
else if (i == 11 - helper_n
&& ! msp430_is_interrupt_func ()
@@ -2569,11 +2582,44 @@ msp430_expand_epilogue (int is_eh)
&& helper_n > 1
&& !is_eh)
{
- emit_jump_insn (gen_epilogue_h
[PATCH] MSP430: Add 'd', 'e', 'f' and 'g' asm operand modifiers
The new operand modifiers can be used to select odd-numbered bytes of a memory
reference or constant value.
Successfully regtested on trunk for msp430-elf in the default, -mlarge,
-mcpu=msp430 and -mlarge/-mcode-region=either/-mdata-region=either
configurations.
Ok for trunk?
Thanks,
Jozef
>From c48ad2ae243a101afe8d021e847c56a482a60f20 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Wed, 9 Sep 2020 13:06:46 +0100
Subject: [PATCH] MSP430: Add 'd', 'e', 'f' and 'g' asm operand modifiers
The new operand modifiers can be used to select odd-numbered bytes of a memory
reference or constant value.
gcc/ChangeLog:
* config/msp430/msp430.c (msp430_print_operand): Update comment.
Cast to long when printing values formatted as long.
Support 'd', 'e', 'f' and 'g' modifiers.
Extract operand value with a single operation for all modifiers.
* doc/extend.texi (msp430Operandmodifiers): New.
gcc/testsuite/ChangeLog:
* gcc.target/msp430/operand-modifiers.c: Extend test to handle new
modifiers.
* gcc.target/msp430/operand-modifiers-bad.c: New test.
---
gcc/config/msp430/msp430.c| 152
gcc/doc/extend.texi | 36
.../gcc.target/msp430/operand-modifiers-bad.c | 15 ++
.../gcc.target/msp430/operand-modifiers.c | 167 +++---
4 files changed, 277 insertions(+), 93 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/msp430/operand-modifiers-bad.c
diff --git a/gcc/config/msp430/msp430.c b/gcc/config/msp430/msp430.c
index a299ed7f9d1..e46a8d23bc7 100644
--- a/gcc/config/msp430/msp430.c
+++ b/gcc/config/msp430/msp430.c
@@ -3475,30 +3475,43 @@ msp430_op_not_in_high_mem (rtx op)
#undef TARGET_PRINT_OPERAND
#define TARGET_PRINT_OPERAND msp430_print_operand
-/* A low 16-bits of int/lower of register pair
- B high 16-bits of int/higher of register pair
- C bits 32-47 of a 64-bit value/reg 3 of a DImode value
- D bits 48-63 of a 64-bit value/reg 4 of a DImode value
- H like %B (for backwards compatibility)
- I inverse of value
- J an integer without a # prefix
- L like %A (for backwards compatibility)
- O offset of the top of the stack
- Q like X but generates an A postfix
- R inverse of condition code, unsigned.
- W value - 16
- X X instruction postfix in large mode
- Y value - 4
- Z value - 1
- b .B or .W or .A, depending upon the mode
- p bit position
- r inverse of condition code
- x like X but only for pointers. */
+/* A Select low 16-bits of the constant/register/memory operand.
+ B Select high 16-bits of the constant/register/memory
+ operand.
+ C Select bits 32-47 of the constant/register/memory operand.
+ D Select bits 48-63 of the constant/register/memory operand.
+ H Equivalent to @code{B} (for backwards compatibility).
+ I Print the inverse (logical @code{NOT}) of the constant
+ value.
+ J Print an integer without a @code{#} prefix.
+ L Equivalent to @code{A} (for backwards compatibility).
+ O Offset of the current frame from the top of the stack.
+ Q Use the @code{A} instruction postfix.
+ R Inverse of condition code, for unsigned comparisons.
+ W Subtract 16 from the constant value.
+ X Use the @code{X} instruction postfix.
+ Y Subtract 4 from the constant value.
+ Z Subtract 1 from the constant value.
+ b Append @code{.B}, @code{.W} or @code{.A} to the
+ instruction, depending on the mode.
+ d Offset 1 byte of a memory reference or constant value.
+ e Offset 3 bytes of a memory reference or constant value.
+ f Offset 5 bytes of a memory reference or constant value.
+ g Offset 7 bytes of a memory reference or constant value.
+ p Print the value of 2, raised to the power of the given
+ constant. Used to select the specified bit position.
+ r Inverse of condition code, for signed comparisons.
+ x Equivialent to @code{X}, but only for pointers. */
static void
msp430_print_operand (FILE * file, rtx op, int letter)
{
rtx addr;
+ /* These are used by the 'A', 'B', 'C', 'D', 'd', 'e', 'f' and 'g' modifiers
+ to describe how to process the operand to get the requested value. */
+ int mem_off = 0;
+ int reg_off = 0;
+ int const_shift = 0;
/* We can't use c, n, a, or l. */
switch (letter)
@@ -3506,17 +3519,17 @@ msp430_print_operand (FILE * file, rtx op, int letter)
case 'Z':
gcc_assert (CONST_INT_P (op));
/* Print the constant value, less one. */
- fprintf (file, "#%ld", INTVAL (op) - 1);
+ fprintf (file, "#%ld", (long) (INTVAL (op) - 1));
return;
case 'Y':
gcc_assert (CONST_INT_P (o
[committed] MSP430: Define NO_FUNCTION_CSE
Calling a constant function address costs the same number of clock cycles as calling an address stored in a register. However, in terms of instruction length, calling a constant address is more expensive. Set NO_FUNCTION_CSE to true, only when optimizing for speed. Committed the attached patch as obvious. Successfully regtested on trunk for msp430-elf. >From 111afded7fdf46ce14972aa8a72c26c9a180ab70 Mon Sep 17 00:00:00 2001 From: Jozef Lawrynowicz Date: Tue, 21 Jul 2020 17:24:03 +0100 Subject: [PATCH] MSP430: Define NO_FUNCTION_CSE Calling a constant function address costs the same number of clock cycles as calling an address stored in a register. However, in terms of instruction length, calling a constant address is more expensive. Set NO_FUNCTION_CSE to true, only when optimizing for speed. gcc/ChangeLog: * config/msp430/msp430.h (NO_FUNCTION_CSE): Set to true at -O2 and above. --- gcc/config/msp430/msp430.h | 5 + 1 file changed, 5 insertions(+) diff --git a/gcc/config/msp430/msp430.h b/gcc/config/msp430/msp430.h index f198981ad9e..e97e833a10c 100644 --- a/gcc/config/msp430/msp430.h +++ b/gcc/config/msp430/msp430.h @@ -257,6 +257,11 @@ extern const char *msp430_get_linker_devices_include_path (int, const char **); msp430_return_addr_rtx (COUNT) #define SLOW_BYTE_ACCESS 0 + +/* Calling a constant function address costs the same number of clock + cycles as calling an address stored in a register. However, in terms of + instruction length, calling a constant address is more expensive. */ +#define NO_FUNCTION_CSE (optimize >= 2 && !optimize_size) /* Register Usage */ -- 2.27.0
[committed] MSP430: Define extendqipsi2
The SXT instruction extends the sign of the low byte of the operand through the entire PSImode register. SXTX.A can be used to sign extend the low byte of a memory operand through to the 19th bit. Bits 31:20 are cleared. Successfully regtested on trunk for msp430-elf. Committed as obvious. >From aa360dd1c882b943066ba088861c0bfac9df930d Mon Sep 17 00:00:00 2001 From: Jozef Lawrynowicz Date: Tue, 21 Jul 2020 17:24:03 +0100 Subject: [PATCH] MSP430: Define extendqipsi2 The SXT instruction extends the sign of the low byte of the operand through the entire PSImode register. SXTX.A can be used to sign extend the low byte of a memory operand through to the 19th bit. Bits 31:20 are cleared. gcc/ChangeLog: * config/msp430/msp430.md: New "extendqipsi2" define_insn. --- gcc/config/msp430/msp430.md | 9 + 1 file changed, 9 insertions(+) diff --git a/gcc/config/msp430/msp430.md b/gcc/config/msp430/msp430.md index b6602fbca66..99299bd70ef 100644 --- a/gcc/config/msp430/msp430.md +++ b/gcc/config/msp430/msp430.md @@ -553,6 +553,15 @@ (define_insn "extendqihi2" SXT%X0\t%0" ) +(define_insn "extendqipsi2" + [(set (match_operand:PSI0 "msp430_general_dst_operand" "=r,m") + (sign_extend:PSI (match_operand:QI 1 "msp430_general_operand" "0,0")))] + "" + "@ + SXT\t%0 + SXTX.A\t%0" +) + ;; ;; ZERO EXTEND INSTRUCTIONS ;; Byte-writes to registers clear bits 19:8 -- 2.27.0
[committed] MSP430: Remove do_no_relax_short_jumps
do_not_relax_short_jumps is an old cludge from from when the Binutils
linker could not relax BR to JMP and vice-versa when shuffling "either"
sections between upper and lower memory.
This has been fixed since at least Binutils 2.30.
Successfully regtested on trunk for msp430-elf.
Committed as obvious.
>From b4ca70a3faa5ebc1f9fb4600583d0986f1bc7133 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Tue, 21 Jul 2020 17:24:04 +0100
Subject: [PATCH] MSP430: Remove do_no_relax_short_jumps
This is an old cludge from from when the Binutils linker could not relax
BR to JMP and vice-versa when shuffling "either" sections between upper
and lower memory. This has been fixed since at least Binutils 2.30.
gcc/ChangeLog:
* config/msp430/msp430-protos.h (msp430_do_not_relax_short_jumps):
Remove.
* config/msp430/msp430.c (msp430_do_not_relax_short_jumps): Likewise.
* config/msp430/msp430.md (cbranchhi4_real): Remove special case for
msp430_do_not_relax_short_jumps.
---
gcc/config/msp430/msp430-protos.h | 1 -
gcc/config/msp430/msp430.c| 13 -
gcc/config/msp430/msp430.md | 31 ---
3 files changed, 4 insertions(+), 41 deletions(-)
diff --git a/gcc/config/msp430/msp430-protos.h
b/gcc/config/msp430/msp430-protos.h
index 29ce9babc4a..a13a94cb92c 100644
--- a/gcc/config/msp430/msp430-protos.h
+++ b/gcc/config/msp430/msp430-protos.h
@@ -21,7 +21,6 @@
#ifndef GCC_MSP430_PROTOS_H
#define GCC_MSP430_PROTOS_H
-bool msp430_do_not_relax_short_jumps (void);
rtxmsp430_eh_return_stackadj_rtx (void);
void msp430_expand_eh_return (rtx);
void msp430_expand_epilogue (int);
diff --git a/gcc/config/msp430/msp430.c b/gcc/config/msp430/msp430.c
index 6bb1714f465..455b4af3dad 100644
--- a/gcc/config/msp430/msp430.c
+++ b/gcc/config/msp430/msp430.c
@@ -2161,19 +2161,6 @@ msp430_file_end (void)
#endif
}
-bool
-msp430_do_not_relax_short_jumps (void)
-{
- /* When placing code into "either" low or high memory we do not want the
- linker to grow the size of sections, which it can do if it is encounters a
- branch to a label that is too far away. So we tell the cbranch patterns
to
- avoid using short jumps when there is a chance that the instructions will
- end up in a low section. */
- return
-msp430_code_region == MSP430_REGION_EITHER
-|| has_attr (ATTR_EITHER, current_function_decl);
-}
-
enum msp430_builtin
{
MSP430_BUILTIN_BIC_SR,
diff --git a/gcc/config/msp430/msp430.md b/gcc/config/msp430/msp430.md
index 99299bd70ef..ed21eb02868 100644
--- a/gcc/config/msp430/msp430.md
+++ b/gcc/config/msp430/msp430.md
@@ -1309,33 +1309,10 @@ (define_insn "cbranchhi4_real"
(clobber (reg:BI CARRY))
]
""
- "*
-/* This is nasty. If we are splitting code between low and high memory
- then we do not want the linker to increase the size of sections by
- relaxing out of range jump instructions. (Since relaxation occurs
- after section placement). So we have to generate pessimal branches
- here. But we only want to do this when really necessary.
-
- FIXME: Do we need code in the other cbranch patterns ? */
-if (msp430_do_not_relax_short_jumps () && get_attr_length (insn) > 6)
- {
-return which_alternative == 0 ?
-\"CMP.W\t%2, %1 { J%r0 1f { BRA #%l3 { 1:\" :
- \"CMPX.W\t%2, %1 { J%r0 1f { BRA #%l3 { 1:\";
- }
-
-return which_alternative == 0 ?
- \"CMP.W\t%2, %1 { J%0\t%l3\" :
-\"CMPX.W\t%2, %1 { J%0\t%l3\";
- "
- [(set (attr "length")
- (if_then_else
- (and (ge (minus (match_dup 3) (pc)) (const_int -510))
- (le (minus (match_dup 3) (pc)) (const_int 510)))
- (const_int 6)
- (const_int 10))
- )]
- )
+ "@
+ CMP.W\t%2, %1 { J%0\t%l3
+ CMPX.W\t%2, %1 { J%0\t%l3"
+)
(define_insn "cbranchpsi4_reversed"
[(set (pc) (if_then_else
--
2.27.0
[PATCH 0/3] MSP430: Improve code-generation for shift instructions
The attached series of patches improve code-generation for MSP430 shift instructions. The first two patches are changes to generic areas of GCC, required for the 3rd patch to have the desired effect. Successfully regtested on trunk for x86_64-pc-linux-gnu (for the generic changes) and msp430-elf. Ok to apply? Jozef Lawrynowicz (3): expr: Allow scalar_int_mode target mode when converting a constant expmed: Fix possible use of NULL_RTX return value from emit_store_flag MSP430: Simplify and extend shift instruction patterns gcc/config/msp430/constraints.md | 10 +- gcc/config/msp430/msp430-protos.h | 6 +- gcc/config/msp430/msp430.c| 272 + gcc/config/msp430/msp430.md | 381 +- gcc/config/msp430/msp430.opt | 6 + gcc/config/msp430/predicates.md | 13 +- gcc/doc/invoke.texi | 15 +- gcc/expmed.c | 34 +- gcc/expr.c| 2 +- .../gcc.target/msp430/emulate-srli.c | 2 +- .../msp430/max-inline-shift-430-no-opt.c | 52 +++ .../gcc.target/msp430/max-inline-shift-430.c | 50 +++ .../gcc.target/msp430/max-inline-shift-430x.c | 48 +++ libgcc/config/msp430/slli.S | 15 + libgcc/config/msp430/srai.S | 15 + libgcc/config/msp430/srli.S | 16 + 16 files changed, 548 insertions(+), 389 deletions(-) create mode 100644 gcc/testsuite/gcc.target/msp430/max-inline-shift-430-no-opt.c create mode 100644 gcc/testsuite/gcc.target/msp430/max-inline-shift-430.c create mode 100644 gcc/testsuite/gcc.target/msp430/max-inline-shift-430x.c -- 2.27.0
[PATCH 1/3] expr: Allow scalar_int_mode target mode when converting a constant
is_int_mode does not allow MODE_PARTIAL_INT modes, so convert_modes was
not allowing a constant value to be converted to a MODE_PARTIAL_INT for
use as operand 2 in patterns such as ashlpsi3. The constant had
to be copied into a register before it could be used, but now can be
used directly as an operand without any copying.
Successfully regtested on trunk for x86_64-pc-linux-gnu and msp430-elf.
Ok to apply?
>From 485feafad6ef0966ff0e1d2ae383cd2b6dbc5c96 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Wed, 15 Jul 2020 11:19:16 +0100
Subject: [PATCH 1/3] expr: Allow scalar_int_mode target mode when converting a
constant
is_int_mode does not allow MODE_PARTIAL_INT modes, so convert_modes was
not allowing a constant value to be converted to a MODE_PARTIAL_INT for
use as operand 2 in patterns such as ashlpsi3. The constant had
to be copied into a register before it could be used, but now can be
used directly as an operand without any copying.
gcc/ChangeLog:
* expr.c (convert_modes): Allow a constant integer to be converted to
any scalar int mode.
---
gcc/expr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/expr.c b/gcc/expr.c
index c7c3e9fd655..5a252f0935f 100644
--- a/gcc/expr.c
+++ b/gcc/expr.c
@@ -696,7 +696,7 @@ convert_modes (machine_mode mode, machine_mode oldmode, rtx
x, int unsignedp)
return x;
if (CONST_SCALAR_INT_P (x)
- && is_int_mode (mode, &int_mode))
+ && is_a (mode, &int_mode))
{
/* If the caller did not tell us the old mode, then there is not
much to do with respect to canonicalization. We have to
--
2.27.0
[PATCH 2/3] expmed: Fix possible use of NULL_RTX return value from emit_store_flag
MSP430 does not support have any store-flag instructions, so
emit_store_flag can return NULL_RTX. Catch the NULL_RTX in
expmed.c:expand_sdiv_pow2.
Successfully regtested on trunk for x86_64-pc-linux-gnu and msp430-elf.
Ok to apply?
>From cb0f8219ac90229c0336281d73f511c107c877d3 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Wed, 15 Jul 2020 11:19:31 +0100
Subject: [PATCH 2/3] expmed: Fix possible use of NULL_RTX return value from
emit_store_flag
MSP430 does not support have any store-flag instructions, so
emit_store_flag can return NULL_RTX. Catch the NULL_RTX in
expmed.c:expand_sdiv_pow2.
gcc/ChangeLog:
* expmed.c (expand_sdiv_pow2): Check return value from emit_store_flag
is not NULL_RTX before use.
---
gcc/expmed.c | 34 --
1 file changed, 20 insertions(+), 14 deletions(-)
diff --git a/gcc/expmed.c b/gcc/expmed.c
index e7c03fbf92c..d3a1735d39e 100644
--- a/gcc/expmed.c
+++ b/gcc/expmed.c
@@ -4086,9 +4086,12 @@ expand_sdiv_pow2 (scalar_int_mode mode, rtx op0,
HOST_WIDE_INT d)
{
temp = gen_reg_rtx (mode);
temp = emit_store_flag (temp, LT, op0, const0_rtx, mode, 0, 1);
- temp = expand_binop (mode, add_optab, temp, op0, NULL_RTX,
- 0, OPTAB_LIB_WIDEN);
- return expand_shift (RSHIFT_EXPR, mode, temp, logd, NULL_RTX, 0);
+ if (temp != NULL_RTX)
+ {
+ temp = expand_binop (mode, add_optab, temp, op0, NULL_RTX,
+ 0, OPTAB_LIB_WIDEN);
+ return expand_shift (RSHIFT_EXPR, mode, temp, logd, NULL_RTX, 0);
+ }
}
if (HAVE_conditional_move
@@ -4122,17 +4125,20 @@ expand_sdiv_pow2 (scalar_int_mode mode, rtx op0,
HOST_WIDE_INT d)
temp = gen_reg_rtx (mode);
temp = emit_store_flag (temp, LT, op0, const0_rtx, mode, 0, -1);
- if (GET_MODE_BITSIZE (mode) >= BITS_PER_WORD
- || shift_cost (optimize_insn_for_speed_p (), mode, ushift)
-> COSTS_N_INSNS (1))
- temp = expand_binop (mode, and_optab, temp, gen_int_mode (d - 1, mode),
-NULL_RTX, 0, OPTAB_LIB_WIDEN);
- else
- temp = expand_shift (RSHIFT_EXPR, mode, temp,
-ushift, NULL_RTX, 1);
- temp = expand_binop (mode, add_optab, temp, op0, NULL_RTX,
- 0, OPTAB_LIB_WIDEN);
- return expand_shift (RSHIFT_EXPR, mode, temp, logd, NULL_RTX, 0);
+ if (temp != NULL_RTX)
+ {
+ if (GET_MODE_BITSIZE (mode) >= BITS_PER_WORD
+ || shift_cost (optimize_insn_for_speed_p (), mode, ushift)
+ > COSTS_N_INSNS (1))
+ temp = expand_binop (mode, and_optab, temp, gen_int_mode (d - 1,
mode),
+NULL_RTX, 0, OPTAB_LIB_WIDEN);
+ else
+ temp = expand_shift (RSHIFT_EXPR, mode, temp,
+ushift, NULL_RTX, 1);
+ temp = expand_binop (mode, add_optab, temp, op0, NULL_RTX,
+ 0, OPTAB_LIB_WIDEN);
+ return expand_shift (RSHIFT_EXPR, mode, temp, logd, NULL_RTX, 0);
+ }
}
label = gen_label_rtx ();
--
2.27.0
[PATCH 3/3] MSP430: Simplify and extend shift instruction patterns
The implementation of define_expand and define_insn patterns to handle shifts in the MSP430 backend is inconsistent, resulting in missed opportunities to make best use of the architecture's features. There's now a single define_expand used as the entry point for all valid shifts, and the decision to either use a helper function to perform the shift (often required for the 430 ISA), or fall through to the define_insn patterns can be made from that expander function. Shifts by a constant amount have been grouped into one define_insn for each type of shift, instead of having different define_insn patterns for shifts by different amounts. A new target option "-mmax-inline-shift=" has been added to allow tuning of the number of shift instructions to emit inline, instead of using a library helper function. Successfully regtested on trunk for msp430-elf, ok to apply? >From a3c62c448c7f359bad85c86c35f712ca1fccf219 Mon Sep 17 00:00:00 2001 From: Jozef Lawrynowicz Date: Wed, 15 Jul 2020 11:43:36 +0100 Subject: [PATCH 3/3] MSP430: Simplify and extend shift instruction patterns The implementation of define_expand and define_insn patterns to handle shifts in the MSP430 backend is inconsistent, resulting in missed opportunities to make best use of the architecture's features. There's now a single define_expand used as the entry point for all valid shifts, and the decision to either use a helper function to perform the shift (often required for the 430 ISA), or fall through to the define_insn patterns can be made from that expander function. Shifts by a constant amount have been grouped into one define_insn for each type of shift, instead of having different define_insn patterns for shifts by different amounts. A new target option "-mmax-inline-shift=" has been added to allow tuning of the number of shift instructions to emit inline, instead of using a library helper function. gcc/ChangeLog: * config/msp430/constraints.md (K): Change unused constraint to constraint to a const_int between 1 and 19. (P): New constraint. * config/msp430/msp430-protos.h (msp430x_logical_shift_right): Remove. (msp430_expand_shift): New. (msp430_output_asm_shift_insns): New. * config/msp430/msp430.c (msp430_rtx_costs): Remove shift costs. (CSH): Remove. (msp430_expand_helper): Remove hard-coded generation of some inline shift insns. (use_helper_for_const_shift): New. (msp430_expand_shift): New. (msp430_output_asm_shift_insns): New. (msp430_print_operand): Add new 'W' operand selector. (msp430x_logical_shift_right): Remove. * config/msp430/msp430.md (HPSI): New define_mode_iterator. (HDI): Likewise. (any_shift): New define_code_iterator. (shift_insn): New define_code_attr. Adjust unnamed insn patterns searched for by combine. (ashlhi3): Remove. (slli_1): Remove. (430x_shift_left): Remove. (slll_1): Remove. (slll_2): Remove. (ashlsi3): Remove. (ashldi3): Remove. (ashrhi3): Remove. (srai_1): Remove. (430x_arithmetic_shift_right): Remove. (srap_1): Remove. (srap_2): Remove. (sral_1): Remove. (sral_2): Remove. (ashrsi3): Remove. (ashrdi3): Remove. (lshrhi3): Remove. (srli_1): Remove. (430x_logical_shift_right): Remove. (srlp_1): Remove. (srll_1): Remove. (srll_2x): Remove. (lshrsi3): Remove. (lshrdi3): Remove. (3): New define_expand. (hi3_430): New define_insn. (si3_const): Likewise. (ashl3_430x): Likewise. (ashr3_430x): Likewise. (lshr3_430x): Likewise. (*bitbranch4_z): Replace renamed predicate msp430_bitpos with const_0_to_15_operand. * config/msp430/msp430.opt: New option -mmax-inline-shift=. * config/msp430/predicates.md (const_1_to_8_operand): New predicate. (const_0_to_15_operand): Rename msp430_bitpos predicate. (const_1_to_19_operand): New predicate. * doc/invoke.texi: Document -mmax-inline-shift=. libgcc/ChangeLog: * config/msp430/slli.S (__gnu_mspabi_sllp): New. * config/msp430/srai.S (__gnu_mspabi_srap): New. * config/msp430/srli.S (__gnu_mspabi_srlp): New. gcc/testsuite/ChangeLog: * gcc.target/msp430/emulate-srli.c: Fix expected assembler text. * gcc.target/msp430/max-inline-shift-430-no-opt.c: New test. * gcc.target/msp430/max-inline-shift-430.c: New test. * gcc.target/msp430/max-inline-shift-430x.c: New test. --- gcc/config/msp430/constraints.md | 10 +- gcc/config/msp430/msp430-protos.h | 6 +- gcc/config/msp430/msp430.c| 272 + gcc/config/msp430/msp430.md | 381 +-
Re: [PATCH 1/3] expr: Allow scalar_int_mode target mode when converting a constant
On Wed, Jul 22, 2020 at 09:33:47AM +0100, Richard Sandiford wrote:
> Jozef Lawrynowicz writes:
> > is_int_mode does not allow MODE_PARTIAL_INT modes, so convert_modes was
> > not allowing a constant value to be converted to a MODE_PARTIAL_INT for
> > use as operand 2 in patterns such as ashlpsi3. The constant had
> > to be copied into a register before it could be used, but now can be
> > used directly as an operand without any copying.
>
> Yeah. I guess this dates back to when MODE_PARTIAL_INTs didn't have
> a known precision.
Is that what the section on MODE_PARTIAL_INT in the description for the
"subreg" RTX refers to? From "14.8 Registers and Memory" of gccint:
A MODE_PARTIAL_INT mode behaves as if it were as wide as the corresponding
MODE_INT mode, except that it has an unknown number of undefined bits.
If so, that whole section seems out of date. I can work on getting it
fixed up.
>
> > diff --git a/gcc/expr.c b/gcc/expr.c
> > index c7c3e9fd655..5a252f0935f 100644
> > --- a/gcc/expr.c
> > +++ b/gcc/expr.c
> > @@ -696,7 +696,7 @@ convert_modes (machine_mode mode, machine_mode oldmode,
> > rtx x, int unsignedp)
> > return x;
> >
> >if (CONST_SCALAR_INT_P (x)
> > - && is_int_mode (mode, &int_mode))
> > + && is_a (mode, &int_mode))
> > {
> >/* If the caller did not tell us the old mode, then there is not
> > much to do with respect to canonicalization. We have to
>
> I think we also need to change the condition in:
>
> /* If the caller did not tell us the old mode, then there is not
>much to do with respect to canonicalization. We have to
>assume that all the bits are significant. */
> if (GET_MODE_CLASS (oldmode) != MODE_INT)
>
> to is_a (old_mode)
>
> OK with that, thanks.
Thanks, I'll regtest that change and apply if all looks good.
Jozef
>
> Richard
[PATCH 0/5] MSP430: Implement macros to describe relative costs of operations
The following series of patches for MSP430 implement some of the target macros used to determine the relative costs of operations. To give an indication of the overall effect of these changes on codesize, below are some size statistics collected from all the executable files from execute.exp that are built at -Os. There are around 1470 such tests (depending on the configuration). The percentage change (((new - old)/old) * 100) in text size is calculated for each test and the given metric is applied to that overall set of data. Configuration | Mean (%) | Median (%) | Delta < 0 (count) | Delta > 0 (count) - -mcpu=msp430 | -2.4| -2.7 | 1454 | 17 -mcpu=msp430x | -2.3| -2.4 | 1460 | 10 -mlarge | -1.7| -1.9 | 1412 | 37 Successfully regtested on trunk for msp430-elf, ok to apply? Jozef Lawrynowicz (5): MSP430: Implement TARGET_MEMORY_MOVE_COST MSP430: Implement TARGET_RTX_COSTS MSP430: Add defaulting to the insn length attribute MSP430: Implement TARGET_INSN_COST MSP430: Skip index-1.c test gcc/config/msp430/msp430-protos.h | 5 +- gcc/config/msp430/msp430.c| 867 -- gcc/config/msp430/msp430.h| 13 + gcc/config/msp430/msp430.md | 439 +++-- gcc/config/msp430/msp430.opt | 4 + gcc/config/msp430/predicates.md | 13 + gcc/testsuite/gcc.c-torture/execute/index-1.c | 2 + 7 files changed, 1206 insertions(+), 137 deletions(-) -- 2.27.0
[PATCH 1/5] MSP430: Implement TARGET_MEMORY_MOVE_COST
The cycle and size cost of a MOV instruction in different addressing
modes can be used to calculate the TARGET_MEMORY_MOVE_COST relative to
TARGET_REGISTER_MOVE_COST.
>From c801a2851d47601218578c411854de9540486335 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Thu, 16 Jul 2020 11:28:11 +0100
Subject: [PATCH 1/5] MSP430: Implement TARGET_MEMORY_MOVE_COST
The cycle and size cost of a MOV instruction in different addressing
modes can be used to calculate the TARGET_MEMORY_MOVE_COST relative to
TARGET_REGISTER_MOVE_COST.
gcc/ChangeLog:
* config/msp430/msp430.c (struct single_op_cost): New struct.
(struct double_op_cost): Likewise.
(TARGET_REGISTER_MOVE_COST): Don't define but add comment.
(TARGET_MEMORY_MOVE_COST): Define to...
(msp430_memory_move_cost): New function.
(BRANCH_COST): Don't define but add comment.
---
gcc/config/msp430/msp430.c | 131 +
1 file changed, 131 insertions(+)
diff --git a/gcc/config/msp430/msp430.c b/gcc/config/msp430/msp430.c
index c2b24974364..9e739233fa0 100644
--- a/gcc/config/msp430/msp430.c
+++ b/gcc/config/msp430/msp430.c
@@ -1043,6 +1043,137 @@ msp430_legitimate_constant (machine_mode mode, rtx x)
}
+/* Describing Relative Costs of Operations
+ To model the cost of an instruction, use the number of cycles when
+ optimizing for speed, and the number of words when optimizing for size.
+ The cheapest instruction will execute in one cycle and cost one word.
+ The cycle and size costs correspond to 430 ISA instructions, not 430X
+ instructions or 430X "address" instructions. The relative costs of 430X
+ instructions is accurately modeled with the 430 costs. The relative costs
+ of some "address" instructions can differ, but these are not yet handled.
+ Adding support for this could improve performance/code size. */
+
+const int debug_rtx_costs = 0;
+
+struct single_op_cost
+{
+ const int reg;
+ /* Indirect register (@Rn) or indirect autoincrement (@Rn+). */
+ const int ind;
+ const int mem;
+};
+
+static const struct single_op_cost cycle_cost_single_op =
+{
+ 1, 3, 4
+};
+
+static const struct single_op_cost size_cost_single_op =
+{
+ 1, 1, 2
+};
+
+/* When the destination of an insn is memory, the cost is always the same
+ regardless of whether that memory is accessed using indirect register,
+ indexed or absolute addressing.
+ When the source operand is memory, indirect register and post-increment have
+ the same cost, which is lower than indexed and absolute, which also have
+ the same cost. */
+struct double_op_cost
+{
+ /* Source operand is a register. */
+ const int r2r;
+ const int r2pc;
+ const int r2m;
+
+ /* Source operand is memory, using indirect register (@Rn) or indirect
+ autoincrement (@Rn+) addressing modes. */
+ const int ind2r;
+ const int ind2pc;
+ const int ind2m;
+
+ /* Source operand is an immediate. */
+ const int imm2r;
+ const int imm2pc;
+ const int imm2m;
+
+ /* Source operand is memory, using indexed (x(Rn)) or absolute (&ADDR)
+ addressing modes. */
+ const int mem2r;
+ const int mem2pc;
+ const int mem2m;
+};
+
+/* These structures describe the cost of MOV, BIT and CMP instructions, in
terms
+ of clock cycles or words. */
+static const struct double_op_cost cycle_cost_double_op_mov =
+{
+ 1, 3, 3,
+ 2, 4, 4,
+ 2, 3, 4,
+ 3, 5, 5
+};
+
+/* Cycle count when memory is the destination operand is one larger than above
+ for instructions that aren't MOV, BIT or CMP. */
+static const struct double_op_cost cycle_cost_double_op =
+{
+ 1, 3, 4,
+ 2, 4, 5,
+ 2, 3, 5,
+ 3, 5, 6
+};
+
+static const struct double_op_cost size_cost_double_op =
+{
+ 1, 1, 2,
+ 1, 1, 2,
+ 2, 2, 3,
+ 2, 2, 3
+};
+
+/* TARGET_REGISTER_MOVE_COST
+ There is only one class of general-purpose, non-fixed registers, and the
+ relative cost of moving data between them is always the same.
+ Therefore, the default of 2 is optimal. */
+
+#undef TARGET_MEMORY_MOVE_COST
+#define TARGET_MEMORY_MOVE_COST msp430_memory_move_cost
+
+/* Return the cost of moving data between registers and memory.
+ The returned cost must be relative to the default TARGET_REGISTER_MOVE_COST
+ of 2.
+ IN is false if the value is to be written to memory. */
+static int
+msp430_memory_move_cost (machine_mode mode ATTRIBUTE_UNUSED,
+reg_class_t rclass ATTRIBUTE_UNUSED,
+bool in)
+{
+ int cost;
+ const struct double_op_cost *cost_p;
+ /* Optimize with a code size focus by default, unless -O2 or above is
+ specified. */
+ bool speed = (!optimize_size && optimize >= 2);
+
+ cost_p = (speed ? &cycle_cost_double_op_mov : &size_cost_double_op);
+
+ if (in)
+/* Reading from memory using indirect addressing is assumed to be the more
+ common case. */
+cost = cost_p->ind2r;
+ else
+cost = cost_
[PATCH 2/5] MSP430: Implement TARGET_RTX_COSTS
Costs of MSP430 instructions are mostly just a function of the type and number
of operands. In these cases, TARGET_RTX_COSTS just needs to examine the
operands to calculate the cost of the expression.
For more complicated operations where library helper functions are required,
if the cost cannot be accurately calculated, it is estimated and
disparaged relative to the cost of a single instruction.
>From f5cbd8967d9c64a4ea6eb9fb8846b4361e16e396 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Thu, 16 Jul 2020 11:28:59 +0100
Subject: [PATCH 2/5] MSP430: Implement TARGET_RTX_COSTS
Costs of MSP430 instructions are mostly just a function of the type and number
of operands. In these cases, TARGET_RTX_COSTS just needs to examine the
operands to calculate the cost of the expression.
For more complicated operations where library helper functions are required,
if the cost cannot be accurately calculated, it is estimated and
disparaged relative to the cost of a single instruction.
gcc/ChangeLog:
* config/msp430/msp430.c (use_helper_for_const_shift): Add forward
declaration.
Remove unused argument.
(struct msp430_multlib_costs): New struct.
(msp430_is_mem_indirect): New function.
(msp430_costs): Likewise.
(msp430_shift_costs): Likewise.
(msp430_muldiv_costs): Likewise.
(msp430_get_inner_dest_code): Likewise.
(msp430_single_op_cost): Likewise.
(msp430_rtx_costs): Rewrite from scratch.
(msp430_expand_shift): Adjust use_helper_for_const_shift call.
---
gcc/config/msp430/msp430.c | 545 -
1 file changed, 530 insertions(+), 15 deletions(-)
diff --git a/gcc/config/msp430/msp430.c b/gcc/config/msp430/msp430.c
index 9e739233fa0..81ee5075a57 100644
--- a/gcc/config/msp430/msp430.c
+++ b/gcc/config/msp430/msp430.c
@@ -49,6 +49,9 @@
#include "msp430-devices.h"
#include "incpath.h"
#include "prefix.h"
+#include "insn-config.h"
+#include "insn-attr.h"
+#include "recog.h"
/* This file should be included last. */
#include "target-def.h"
@@ -56,6 +59,7 @@
static void msp430_compute_frame_info (void);
static bool use_32bit_hwmult (void);
+static bool use_helper_for_const_shift (machine_mode mode, HOST_WIDE_INT amt);
@@ -1132,6 +1136,28 @@ static const struct double_op_cost size_cost_double_op =
2, 2, 3
};
+struct msp430_multlib_costs
+{
+ const int mulhi;
+ const int mulsi;
+ const int muldi;
+};
+
+/* There is no precise size cost when using libcalls, instead it is disparaged
+ relative to other instructions.
+ The cycle costs are from the CALL to the RET, inclusive.
+ FIXME muldi cost is not accurate. */
+static const struct msp430_multlib_costs cycle_cost_multlib_32bit =
+{
+ 27, 33, 66
+};
+
+/* 32bit multiply takes a few more instructions on 16bit hwmult. */
+static const struct msp430_multlib_costs cycle_cost_multlib_16bit =
+{
+ 27, 42, 66
+};
+
/* TARGET_REGISTER_MOVE_COST
There is only one class of general-purpose, non-fixed registers, and the
relative cost of moving data between them is always the same.
@@ -1174,29 +1200,516 @@ msp430_memory_move_cost (machine_mode mode
ATTRIBUTE_UNUSED,
because there are no conditional move insns - when a condition is involved,
the only option is to use a cbranch. */
+/* For X, which must be a MEM RTX, return TRUE if it is an indirect memory
+ reference, @Rn or @Rn+. */
+static bool
+msp430_is_mem_indirect (rtx x)
+{
+ gcc_assert (GET_CODE (x) == MEM);
+ rtx op0 = XEXP (x, 0);
+ return (GET_CODE (op0) == REG || GET_CODE (op0) == POST_INC);
+}
+
+/* Costs of MSP430 instructions are generally based on the addressing mode
+ combination of the source and destination operands.
+ Given source operand SRC (which may be NULL to indicate a single-operand
+ instruction) and destination operand DST return the cost of this
+ expression. */
+static int
+msp430_costs (rtx src, rtx dst, bool speed, rtx outer_rtx)
+{
+ enum rtx_code src_code = GET_CODE (src);
+ enum rtx_code dst_code = GET_CODE (dst);
+ enum rtx_code outer_code = GET_CODE (outer_rtx);
+ machine_mode outer_mode = GET_MODE (outer_rtx);
+ const struct double_op_cost *cost_p;
+ cost_p = (speed ? &cycle_cost_double_op : &size_cost_double_op);
+
+ if (outer_code == TRUNCATE
+ && (outer_mode == QImode
+ || outer_mode == HImode
+ || outer_mode == PSImode))
+/* Truncation to these modes is normally free as a side effect of the
+ instructions themselves. */
+return 0;
+
+ if (dst_code == SYMBOL_REF
+ || dst_code == LABEL_REF
+ || dst_code == CONST_INT)
+/* Catch RTX like (minus (const_int 0) (reg)) but don't add any cost. */
+return 0;
+
+ if (debug_rtx_costs && dst_code != REG && dst_code != MEM && dst_code != PC)
+{
+ fprintf (stderr,
[PATCH 3/5] MSP430: Add defaulting to the insn length attribute
The length of MSP430 instructions is mostly just a function of the type and
number of operands. Setting the "type" attribute on all insns describes
the number of operands, and the position of the source and destination
operands.
In most cases, defaulting in the "length" and "extension" attribute definitions
can then be used to calculate the total length of the instruction by using
the value of the "type" attribute to examine the operands.
>From 0e39cc3f13c604df1225d3c1eef6b05e629c184b Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Thu, 16 Jul 2020 11:32:01 +0100
Subject: [PATCH 3/5] MSP430: Add defaulting to the insn length attribute
The length of MSP430 instructions is mostly just a function of the type and
number of operands. Setting the "type" attribute on all insns describes
the number of operands, and the position of the source and destination
operands.
In most cases, defaulting in the "length" and "extension" attribute definitions
can then be used to calculate the total length of the instruction by using
the value of the "type" attribute to examine the operands.
gcc/ChangeLog:
* config/msp430/msp430-protos.h (msp430x_extendhisi): Return int
instead of char *.
(msp430_output_asm_shift_insns): Likewise.
Add new return_length argument.
(msp430x_insn_required): Add prototype.
* config/msp430/msp430.c (msp430_output_asm_shift_insns): Return the
total length, in bytes, of the emitted instructions.
(msp430x_insn_required): New function.
(msp430x_extendhisi): Return the total length, in bytes, of the
emitted instructions.
* config/msp430/msp430.h (ADJUST_INSN_LENGTH): Define.
* config/msp430/msp430.md: New define_attr "type".
New define_attr "extension".
New define_attr "length_multiplier".
New define_attr "extra_length".
Rewrite define_attr "length".
Set type, extension, length, length_multiplier or extra_length insn
attributes on all insns, as appropriate.
(andneghi3): Rewrite using constraints instead of C code to decide
output insns.
* config/msp430/predicates.md (msp430_cheap_operand): New predicate.
(msp430_high_memory_operand): New predicate.
---
gcc/config/msp430/msp430-protos.h | 5 +-
gcc/config/msp430/msp430.c| 162 ---
gcc/config/msp430/msp430.h| 10 +
gcc/config/msp430/msp430.md | 439 --
gcc/config/msp430/predicates.md | 13 +
5 files changed, 507 insertions(+), 122 deletions(-)
diff --git a/gcc/config/msp430/msp430-protos.h
b/gcc/config/msp430/msp430-protos.h
index 0b4d9a42b41..33ad1adc61f 100644
--- a/gcc/config/msp430/msp430-protos.h
+++ b/gcc/config/msp430/msp430-protos.h
@@ -26,7 +26,7 @@ void msp430_expand_eh_return (rtx);
void msp430_expand_epilogue (int);
void msp430_expand_helper (rtx *operands, const char *, bool);
void msp430_expand_prologue (void);
-const char * msp430x_extendhisi (rtx *);
+int msp430x_extendhisi (rtx *, bool);
void msp430_fixup_compare_operands (machine_mode, rtx *);
intmsp430_hard_regno_nregs_has_padding (int, machine_mode);
intmsp430_hard_regno_nregs_with_padding (int, machine_mode);
@@ -49,10 +49,11 @@ rtx msp430_subreg (machine_mode, rtx, machine_mode, int);
boolmsp430_use_f5_series_hwmult (void);
bool msp430_has_hwmult (void);
bool msp430_op_not_in_high_mem (rtx op);
+bool msp430x_insn_required (rtx op);
#ifdef RTX_CODE
int msp430_expand_shift (enum rtx_code code, machine_mode mode, rtx *operands);
-const char * msp430_output_asm_shift_insns (enum rtx_code code, machine_mode
mode, rtx *operands);
+int msp430_output_asm_shift_insns (enum rtx_code code, machine_mode mode, rtx
*operands, bool);
#endif
#endif /* GCC_MSP430_PROTOS_H */
diff --git a/gcc/config/msp430/msp430.c b/gcc/config/msp430/msp430.c
index 81ee5075a57..b7daafcc11a 100644
--- a/gcc/config/msp430/msp430.c
+++ b/gcc/config/msp430/msp430.c
@@ -3535,18 +3535,22 @@ msp430_expand_shift (enum rtx_code code, machine_mode
mode, rtx *operands)
For 430X it is inneficient to do so for any modes except SI and DI, since we
can make use of R*M insns or RPT with 430X insns, so this function is only
used for SImode in that case. */
-const char *
+int
msp430_output_asm_shift_insns (enum rtx_code code, machine_mode mode,
- rtx *operands)
+ rtx *operands, bool return_length)
{
int i;
int amt;
int max_shift = GET_MODE_BITSIZE (mode) - 1;
+ int length = 0;
+
gcc_assert (CONST_INT_P (operands[2]));
amt = INTVAL (operands[2]);
if (amt == 0 || amt > max_shift)
{
+ if (return_length)
+ return 0;
switch (code)
{
case ASHIFT:
@@ -3564,17 +3568,28 @@ msp43
[PATCH 4/5] MSP430: Implement TARGET_INSN_COST
The length of an insn can be used to calculate its cost, when optimizing for
size. When optimizing for speed, this is a good estimate, since the cycle cost
of an MSP430 instruction increases with its length.
>From e4c5f9c3f567489f89b41a0d96e321acb5d18152 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Thu, 16 Jul 2020 11:34:50 +0100
Subject: [PATCH 4/5] MSP430: Implement TARGET_INSN_COST
The length of an insn can be used to calculate its cost, when optimizing for
size. When optimizing for speed, this is a good estimate, since the cycle cost
of an MSP430 instruction increases with its length.
gcc/ChangeLog:
* config/msp430/msp430.c (TARGET_INSN_COST): Define.
(msp430_insn_cost): New function.
* config/msp430/msp430.opt: Add -mdebug-insn-costs option.
gcc/testsuite/ChangeLog:
* gcc.target/msp430/rtx-cost-O3-default.c: New test.
* gcc.target/msp430/rtx-cost-O3-f5series.c: New test.
* gcc.target/msp430/rtx-cost-Os-default.c: New test.
* gcc.target/msp430/rtx-cost-Os-f5series.c: New test.
---
gcc/config/msp430/msp430.c| 29 +
gcc/config/msp430/msp430.opt | 4 ++
.../gcc.target/msp430/rtx-cost-O3-default.c | 42 ++
.../gcc.target/msp430/rtx-cost-O3-f5series.c | 38
.../gcc.target/msp430/rtx-cost-Os-default.c | 43 +++
.../gcc.target/msp430/rtx-cost-Os-f5series.c | 38
6 files changed, 194 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/msp430/rtx-cost-O3-default.c
create mode 100644 gcc/testsuite/gcc.target/msp430/rtx-cost-O3-f5series.c
create mode 100644 gcc/testsuite/gcc.target/msp430/rtx-cost-Os-default.c
create mode 100644 gcc/testsuite/gcc.target/msp430/rtx-cost-Os-f5series.c
diff --git a/gcc/config/msp430/msp430.c b/gcc/config/msp430/msp430.c
index b7daafcc11a..7ef651fb324 100644
--- a/gcc/config/msp430/msp430.c
+++ b/gcc/config/msp430/msp430.c
@@ -1711,6 +1711,35 @@ msp430_rtx_costs (rtx x,
return false;
}
}
+
+#undef TARGET_INSN_COST
+#define TARGET_INSN_COST msp430_insn_cost
+
+static int
+msp430_insn_cost (rtx_insn *insn, bool speed ATTRIBUTE_UNUSED)
+{
+ int cost;
+
+ if (recog_memoized (insn) < 0)
+return 0;
+
+ cost = get_attr_length (insn);
+ if (TARGET_DEBUG_INSN_COSTS)
+{
+ fprintf (stderr, "cost %d for insn:\n", cost);
+ debug_rtx (insn);
+}
+
+ /* The returned cost must be relative to COSTS_N_INSNS (1). An insn with a
+ length of 2 bytes is the smallest possible size and so must be equivalent
+ to COSTS_N_INSNS (1). */
+ return COSTS_N_INSNS (cost) / (2 * COSTS_N_INSNS (1));
+
+ /* FIXME Add more detailed costs when optimizing for speed.
+ For now the length of the instruction is a good approximiation and roughly
+ correlates with cycle cost. */
+}
+
/* Function Entry and Exit */
diff --git a/gcc/config/msp430/msp430.opt b/gcc/config/msp430/msp430.opt
index 8134ca7ac95..448c41aa81c 100644
--- a/gcc/config/msp430/msp430.opt
+++ b/gcc/config/msp430/msp430.opt
@@ -115,3 +115,7 @@ Target RejectNegative Joined UInteger IntegerRange(0,65)
Var(msp430_max_inline_s
For shift operations by a constant amount, which require an individual
instruction to shift by one
position, set the maximum number of inline shift instructions (maximum value
64) to emit instead of using the corresponding __mspabi helper function.
The default value is 4.
+
+mdebug-insn-costs
+Target Report Mask(DEBUG_INSN_COSTS)
+Print insns and their costs as calculated by TARGET_INSN_COSTS.
diff --git a/gcc/testsuite/gcc.target/msp430/rtx-cost-O3-default.c
b/gcc/testsuite/gcc.target/msp430/rtx-cost-O3-default.c
new file mode 100644
index 000..1bd6a142002
--- /dev/null
+++ b/gcc/testsuite/gcc.target/msp430/rtx-cost-O3-default.c
@@ -0,0 +1,42 @@
+/* { dg-do compile } */
+/* { dg-options "-O3" } */
+/* { dg-final { check-function-bodies "**" "" } } */
+
+/* Verify the MSP430 cost model is working as expected for the default ISA
+ (msp430x) and hwmult (none), when compiling at -O3. */
+
+char arr[2];
+char a;
+char *ptr;
+
+/*
+** foo:
+** ...
+** MOV.B \&a, \&arr\+1
+** MOV.* #arr\+2, \&ptr
+** ...
+*/
+
+void
+foo (void)
+{
+ arr[1] = a;
+ ptr = arr + 2;
+}
+
+extern void ext (void);
+
+/*
+** bar:
+** ...
+** CALL.* #ext
+** CALL.* #ext
+** ...
+*/
+
+void
+bar (void)
+{
+ ext ();
+ ext ();
+}
diff --git a/gcc/testsuite/gcc.target/msp430/rtx-cost-O3-f5series.c
b/gcc/testsuite/gcc.target/msp430/rtx-cost-O3-f5series.c
new file mode 100644
index 000..1e48625f2e5
--- /dev/null
+++ b/gcc/testsuite/gcc.target/msp430/rtx-cost-O3-f5series.c
@@ -0,0 +1,38 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -mhwmult=f5series" } */
+/* { dg-final { check-function-bodies "**" "" } } */
+
+/* Verify the MSP430 cost model is working
[PATCH 5/5] MSP430: Skip index-1.c test
To access the "n - 10"th element of "a" in this test, GCC will
generate the following code for msp430-elf with -mcpu=msp430x:
RLAM.W #1, R12
MOV.W a-3392(R12), R12
Since there aren't actually 100,000 elements in a, this means that
"a-3392" offset calculated by the linker can overflow, as the address of
"a" can validly be less than 3392.
The relocations used for -mcpu=msp430 and -mlarge are not as strict and
the calculated value is allowed to wrap around the address space,
avoiding relocation overflows.
>From bfafc633013952c1a5cac2dbb10b774f66be920e Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Thu, 16 Jul 2020 11:35:25 +0100
Subject: [PATCH 5/5] MSP430: Skip index-1.c test
To access the "n - 10"th element of "a" in this test, GCC will
generate the following code for msp430-elf with -mcpu=msp430x:
RLAM.W #1, R12
MOV.W a-3392(R12), R12
Since there aren't actually 100,000 elements in a, this means that
"a-3392" offset calculated by the linker can overflow, as the address of
"a" can validly be less than 3392.
The relocations used for -mcpu=msp430 and -mlarge are not as strict and
the calculated value is allowed to wrap around the address space,
avoiding relocation overflows.
gcc/testsuite/ChangeLog:
* gcc.c-torture/execute/index-1.c: Skip for the default MSP430 430X ISA.
---
gcc/testsuite/gcc.c-torture/execute/index-1.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gcc/testsuite/gcc.c-torture/execute/index-1.c
b/gcc/testsuite/gcc.c-torture/execute/index-1.c
index b00090d834a..d96be4c77b8 100644
--- a/gcc/testsuite/gcc.c-torture/execute/index-1.c
+++ b/gcc/testsuite/gcc.c-torture/execute/index-1.c
@@ -1,3 +1,5 @@
+/* { dg-skip-if "strict reloc overflow checking" { msp430-*-* } { "*" } {
"-mcpu=msp430" "-mlarge"} } */
+
int a[] =
{
0, 1, 2, 3, 4, 5, 6, 7, 8, 9,
--
2.27.0
Re: [PATCH 4/5] MSP430: Implement TARGET_INSN_COST
Hi Segher,
Thanks for having a look at the patch.
On Thu, Jul 23, 2020 at 01:34:22PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Jul 23, 2020 at 04:56:14PM +0100, Jozef Lawrynowicz wrote:
> > +static int
> > +msp430_insn_cost (rtx_insn *insn, bool speed ATTRIBUTE_UNUSED)
> > +{
> > + int cost;
> > +
> > + if (recog_memoized (insn) < 0)
> > +return 0;
> > +
> > + cost = get_attr_length (insn);
> > + if (TARGET_DEBUG_INSN_COSTS)
> > +{
> > + fprintf (stderr, "cost %d for insn:\n", cost);
> > + debug_rtx (insn);
> > +}
> > +
> > + /* The returned cost must be relative to COSTS_N_INSNS (1). An insn with
> > a
> > + length of 2 bytes is the smallest possible size and so must be
> > equivalent
> > + to COSTS_N_INSNS (1). */
> > + return COSTS_N_INSNS (cost) / (2 * COSTS_N_INSNS (1));
>
> This is the same as "cost / 2", so "length / 2" here, which doesn't look
> right. The returned value should have the same "unit" as COSTS_N_INSNS
> does, so maybe you want COSTS_N_INSNS (length / 2) ?
Indeed it looks like I made a thinko in that calculation in TARGET_INSN_COSTS;
trying to make it verbose to show the thought behind the calculation backfired
:)
Fixing it to return "COSTS_N_INSNS (length / 2)" actually made codesize
noticeably worse for most of my benchmarks.
I had to define BRANCH_COST to indicate branches are not cheap.
In the original patch a cheap instruction would have a cost of 1.
When using the default BRANCH_COST of 1 to calculate the cost of a branch
compared to an insn (e.g. in ifcvt.c), BRANCH_COST would be wrapped in
COSTS_N_INSNS, scaling the cost to 4, which suitably disparaged
it vs the cheap insn cost of 1.
With the fixed insn_cost calculation, a cheap instruction would cost 4
with the COSTS_N_INSNS scaling, and a branch would cost the same, which is not
right.
Fixed in the attached patch.
>
> > + /* FIXME Add more detailed costs when optimizing for speed.
> > + For now the length of the instruction is a good approximiation and
> > roughly
> > + correlates with cycle cost. *
>
> COSTS_N_INSNS (1) is 4, so that you can make things cost 5, 6, 7 to be a
> cost intermediate to COSTS_N_INSNS (1) and COSTS_N_INSNS (2). This is
> very useful, scaling down the costs destroys that.
>
> > +mdebug-insn-costs
> > +Target Report Mask(DEBUG_INSN_COSTS)
> > +Print insns and their costs as calculated by TARGET_INSN_COSTS.
>
> It is already printed in the generated asm with -dp? Not sure if you
> want more detail than that.
>
> '-dp'
> Annotate the assembler output with a comment indicating which
> pattern and alternative is used. The length and cost of each
> instruction are also printed.
>
During development I found it useful to see the insns in RTL format and their
costs alongside that. In hindsight, it doesn't really have much use in the
finalized patch, so I've removed it.
Thanks!
Jozef
>
> Segher
>From 8b69c5a38006d30d001561d47f7ecbd9bd3ead78 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Thu, 16 Jul 2020 11:34:50 +0100
Subject: [PATCH 4/5] MSP430: Implement TARGET_INSN_COST
The length of an insn can be used to calculate its cost, when optimizing for
size. When optimizing for speed, this is a good estimate, since the cycle cost
of an MSP430 instruction increases with its length.
gcc/ChangeLog:
* config/msp430/msp430.c (TARGET_INSN_COST): Define.
(msp430_insn_cost): New function.
* config/msp430/msp430.opt: Add -mdebug-insn-costs option.
* config/msp430/msp430.h (BRANCH_COST): Define.
(LOGICAL_OP_NON_SHORT_CIRCUIT): Define.
gcc/testsuite/ChangeLog:
* gcc.target/msp430/rtx-cost-O3-default.c: New test.
* gcc.target/msp430/rtx-cost-O3-f5series.c: New test.
* gcc.target/msp430/rtx-cost-Os-default.c: New test.
* gcc.target/msp430/rtx-cost-Os-f5series.c: New test.
---
gcc/config/msp430/msp430.c| 25 ---
gcc/config/msp430/msp430.h| 8
.../gcc.target/msp430/rtx-cost-O3-default.c | 42 ++
.../gcc.target/msp430/rtx-cost-O3-f5series.c | 38
.../gcc.target/msp430/rtx-cost-Os-default.c | 43 +++
.../gcc.target/msp430/rtx-cost-Os-f5series.c | 38
6 files changed, 189 insertions(+), 5 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/msp430/rtx-cost-O3-default.c
create mode 100644 gcc/testsuite/gcc.target/msp430/rtx-cost-O3-f5series.c
create mode 100644 gcc/testsuite/gcc.target/msp430/rtx-cost-Os-default.c
create mode 100644 gcc/testsuite/gcc.target/msp430/rtx-cost-Os-f5
[committed] MSP430: Don't pass redundant -md option to the assembler
The MSP430 GAS option "-md" is supposed to indicate that the CRT startup
code should copy data from ROM to RAM at startup. However, this option
has no effect; GAS handles the related behaviour automatically.
Lightly regtested on trunk by running dg.exp with and without -mlarge.
Committed as obvious.
>From cc8c0049749736cdd88bc9c90f5df3961b97c67c Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Mon, 3 Aug 2020 15:54:52 +0100
Subject: [PATCH] MSP430: Don't pass redundant -md option to the assembler
The MSP430 GAS option "-md" is supposed to indicate that the CRT startup
code should copy data from ROM to RAM at startup. However, this option
has no effect; GAS handles the related behaviour automatically.
gcc/ChangeLog:
* config/msp430/msp430.h (ASM_SPEC): Don't pass on "-md" option.
---
gcc/config/msp430/msp430.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/gcc/config/msp430/msp430.h b/gcc/config/msp430/msp430.h
index e97e833a10c..25007716d24 100644
--- a/gcc/config/msp430/msp430.h
+++ b/gcc/config/msp430/msp430.h
@@ -65,8 +65,6 @@ extern bool msp430x;
"%{mrelax=-mQ} " /* Pass the relax option on to the assembler. */ \
/* Tell the assembler if we are building for the LARGE pointer model. */ \
"%{mlarge:-ml} " \
- /* Copy data from ROM to RAM if necessary. */ \
- "%{!msim:-md} %{msim:%{mlarge:-md}} " \
"%{msilicon-errata=*:-msilicon-errata=%*} " \
"%{msilicon-errata-warn=*:-msilicon-errata-warn=%*} " \
/* Create DWARF line number sections for -ffunction-sections. */ \
--
2.27.0
ping [PATCH 3/3] MSP430: Simplify and extend shift instruction patterns
Pinging for this patch. Thanks, Jozef On Tue, Jul 21, 2020 at 07:29:53PM +0100, Jozef Lawrynowicz wrote: > The implementation of define_expand and define_insn patterns to handle > shifts in the MSP430 backend is inconsistent, resulting in missed > opportunities to make best use of the architecture's features. > > There's now a single define_expand used as the entry point for all valid > shifts, and the decision to either use a helper function to perform the > shift (often required for the 430 ISA), or fall through to the > define_insn patterns can be made from that expander function. > > Shifts by a constant amount have been grouped into one define_insn for > each type of shift, instead of having different define_insn patterns for > shifts by different amounts. > > A new target option "-mmax-inline-shift=" has been added to allow tuning > of the number of shift instructions to emit inline, instead of using > a library helper function. > > Successfully regtested on trunk for msp430-elf, ok to apply? > From a3c62c448c7f359bad85c86c35f712ca1fccf219 Mon Sep 17 00:00:00 2001 > From: Jozef Lawrynowicz > Date: Wed, 15 Jul 2020 11:43:36 +0100 > Subject: [PATCH 3/3] MSP430: Simplify and extend shift instruction patterns > > The implementation of define_expand and define_insn patterns to handle > shifts in the MSP430 backend is inconsistent, resulting in missed > opportunities to make best use of the architecture's features. > > There's now a single define_expand used as the entry point for all valid > shifts, and the decision to either use a helper function to perform the > shift (often required for the 430 ISA), or fall through to the > define_insn patterns can be made from that expander function. > > Shifts by a constant amount have been grouped into one define_insn for > each type of shift, instead of having different define_insn patterns for > shifts by different amounts. > > A new target option "-mmax-inline-shift=" has been added to allow tuning > of the number of shift instructions to emit inline, instead of using > a library helper function. > > gcc/ChangeLog: > > * config/msp430/constraints.md (K): Change unused constraint to > constraint to a const_int between 1 and 19. > (P): New constraint. > * config/msp430/msp430-protos.h (msp430x_logical_shift_right): Remove. > (msp430_expand_shift): New. > (msp430_output_asm_shift_insns): New. > * config/msp430/msp430.c (msp430_rtx_costs): Remove shift costs. > (CSH): Remove. > (msp430_expand_helper): Remove hard-coded generation of some inline > shift insns. > (use_helper_for_const_shift): New. > (msp430_expand_shift): New. > (msp430_output_asm_shift_insns): New. > (msp430_print_operand): Add new 'W' operand selector. > (msp430x_logical_shift_right): Remove. > * config/msp430/msp430.md (HPSI): New define_mode_iterator. > (HDI): Likewise. > (any_shift): New define_code_iterator. > (shift_insn): New define_code_attr. > Adjust unnamed insn patterns searched for by combine. > (ashlhi3): Remove. > (slli_1): Remove. > (430x_shift_left): Remove. > (slll_1): Remove. > (slll_2): Remove. > (ashlsi3): Remove. > (ashldi3): Remove. > (ashrhi3): Remove. > (srai_1): Remove. > (430x_arithmetic_shift_right): Remove. > (srap_1): Remove. > (srap_2): Remove. > (sral_1): Remove. > (sral_2): Remove. > (ashrsi3): Remove. > (ashrdi3): Remove. > (lshrhi3): Remove. > (srli_1): Remove. > (430x_logical_shift_right): Remove. > (srlp_1): Remove. > (srll_1): Remove. > (srll_2x): Remove. > (lshrsi3): Remove. > (lshrdi3): Remove. > (3): New define_expand. > (hi3_430): New define_insn. > (si3_const): Likewise. > (ashl3_430x): Likewise. > (ashr3_430x): Likewise. > (lshr3_430x): Likewise. > (*bitbranch4_z): Replace renamed predicate msp430_bitpos with > const_0_to_15_operand. > * config/msp430/msp430.opt: New option -mmax-inline-shift=. > * config/msp430/predicates.md (const_1_to_8_operand): New predicate. > (const_0_to_15_operand): Rename msp430_bitpos predicate. > (const_1_to_19_operand): New predicate. > * doc/invoke.texi: Document -mmax-inline-shift=. > > libgcc/ChangeLog: > > * config/msp430/slli.S (__gnu_mspabi_sllp): New. > * config/msp430/srai.S (__gnu_mspabi_srap): New. > * config/msp430/srli.S (__gnu_mspabi_srlp): New. > > gcc/testsuite/ChangeLog: &g
ping [PATCH 0/5] MSP430: Implement macros to describe relative costs of operations
Pinging for this series of patches.
Attached all patches to this mail with the ammended patch 4 thanks to
Segher's review.
I forgot to mention originally that these patches require the previously
submitted "simplify and extend shift instruction patterns" patch to be
first applied.
https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550396.html
Thanks,
Jozef
On Thu, Jul 23, 2020 at 04:43:56PM +0100, Jozef Lawrynowicz wrote:
> The following series of patches for MSP430 implement some of the target
> macros used to determine the relative costs of operations.
>
> To give an indication of the overall effect of these changes on
> codesize, below are some size statistics collected from all the
> executable files from execute.exp that are built at -Os.
> There are around 1470 such tests (depending on the configuration).
>
> The percentage change (((new - old)/old) * 100) in text size is calculated
> for each test and the given metric is applied to that overall set of data.
>
> Configuration | Mean (%) | Median (%) | Delta < 0 (count) | Delta > 0 (count)
> -
> -mcpu=msp430 | -2.4| -2.7 | 1454 | 17
> -mcpu=msp430x | -2.3| -2.4 | 1460 | 10
> -mlarge | -1.7| -1.9 | 1412 | 37
>
> Successfully regtested on trunk for msp430-elf, ok to apply?
>
> Jozef Lawrynowicz (5):
> MSP430: Implement TARGET_MEMORY_MOVE_COST
> MSP430: Implement TARGET_RTX_COSTS
> MSP430: Add defaulting to the insn length attribute
> MSP430: Implement TARGET_INSN_COST
> MSP430: Skip index-1.c test
>
> gcc/config/msp430/msp430-protos.h | 5 +-
> gcc/config/msp430/msp430.c| 867 --
> gcc/config/msp430/msp430.h| 13 +
> gcc/config/msp430/msp430.md | 439 +++--
> gcc/config/msp430/msp430.opt | 4 +
> gcc/config/msp430/predicates.md | 13 +
> gcc/testsuite/gcc.c-torture/execute/index-1.c | 2 +
> 7 files changed, 1206 insertions(+), 137 deletions(-)
>
> --
> 2.27.0
>
>From e260de5a31e661afdfaaf2c8053b574a292d6826 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Thu, 16 Jul 2020 11:28:11 +0100
Subject: [PATCH 1/5] MSP430: Implement TARGET_MEMORY_MOVE_COST
The cycle and size cost of a MOV instruction in different addressing
modes can be used to calculate the TARGET_MEMORY_MOVE_COST relative to
TARGET_REGISTER_MOVE_COST.
gcc/ChangeLog:
* config/msp430/msp430.c (struct single_op_cost): New struct.
(struct double_op_cost): Likewise.
(TARGET_REGISTER_MOVE_COST): Don't define but add comment.
(TARGET_MEMORY_MOVE_COST): Define to...
(msp430_memory_move_cost): New function.
(BRANCH_COST): Don't define but add comment.
---
gcc/config/msp430/msp430.c | 131 +
1 file changed, 131 insertions(+)
diff --git a/gcc/config/msp430/msp430.c b/gcc/config/msp430/msp430.c
index c2b24974364..9e739233fa0 100644
--- a/gcc/config/msp430/msp430.c
+++ b/gcc/config/msp430/msp430.c
@@ -1043,6 +1043,137 @@ msp430_legitimate_constant (machine_mode mode, rtx x)
}
+/* Describing Relative Costs of Operations
+ To model the cost of an instruction, use the number of cycles when
+ optimizing for speed, and the number of words when optimizing for size.
+ The cheapest instruction will execute in one cycle and cost one word.
+ The cycle and size costs correspond to 430 ISA instructions, not 430X
+ instructions or 430X "address" instructions. The relative costs of 430X
+ instructions is accurately modeled with the 430 costs. The relative costs
+ of some "address" instructions can differ, but these are not yet handled.
+ Adding support for this could improve performance/code size. */
+
+const int debug_rtx_costs = 0;
+
+struct single_op_cost
+{
+ const int reg;
+ /* Indirect register (@Rn) or indirect autoincrement (@Rn+). */
+ const int ind;
+ const int mem;
+};
+
+static const struct single_op_cost cycle_cost_single_op =
+{
+ 1, 3, 4
+};
+
+static const struct single_op_cost size_cost_single_op =
+{
+ 1, 1, 2
+};
+
+/* When the destination of an insn is memory, the cost is always the same
+ regardless of whether that memory is accessed using indirect register,
+ indexed or absolute addressing.
+ When the source operand is memory, indirect register and post-increment have
+ the same cost, which is lower than indexed and absolute, which also have
+ the same cost. */
+struct double_op_cost
+{
+ /* Source operand is a register. */
+ const int r2r;
+ const int r2pc;
+ const int r2m;
+
+ /* Source operand is memory, using indirect register (@Rn) or indirect
+ autoincremen
[COMMITTED] MSP430: Indiciate that the epilogue_helper insn does not fallthru
The attached patch fixes an ICE in rtl_verify_fallthru, at cfgrtl.c:2970
gcc.c-torture/execute/20071210-1.c for -mcpu=msp430 at -O2
and above.
The epilogue_helper insn was treated as a regular insn which will
fallthru, so when a barrier is emitted after it, RTL verification failed
as rtl_verify_fallthru.
Successfully regtested for msp430-elf in the default, -mcpu=msp430 and -mlarge
configurations.
Committed as obvious.
>From 07432a807ede1c629f0f52aa5f8bf00012929e88 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Thu, 9 Apr 2020 20:52:20 +0100
Subject: [PATCH] MSP430: Indiciate that the epilogue_helper insn does not
fallthru
This fixes an ICE in rtl_verify_fallthru, at cfgrtl.c:2970
gcc.c-torture/execute/20071210-1.c for -mcpu=msp430 at -O2
and above.
The epilogue_helper insn was treated as a regular insn which will
fallthru, so when a barrier is emitted after it, RTL verification failed
as rtl_verify_fallthru.
gcc/ChangeLog:
2020-04-09 Jozef Lawrynowicz
* config/msp430/msp430.c (msp430_expand_epilogue): Use emit_jump_insn
when to emit the epilogue_helper insn.
* config/msp430/msp430.md (epilogue_helper): Add a return insn to the
RTL pattern.
---
gcc/ChangeLog | 7 +++
gcc/config/msp430/msp430.c | 2 +-
gcc/config/msp430/msp430.md | 4 +++-
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index e5e2290ab1a..bce700e472e 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,10 @@
+2020-04-09 Jozef Lawrynowicz
+
+ * config/msp430/msp430.c (msp430_expand_epilogue): Use emit_jump_insn
+ when to emit the epilogue_helper insn.
+ * config/msp430/msp430.md (epilogue_helper): Add a return insn to the
+ RTL pattern.
+
2020-04-09 Jakub Jelinek
PR debug/94495
diff --git a/gcc/config/msp430/msp430.c b/gcc/config/msp430/msp430.c
index cde14c83812..e0d2d732ade 100644
--- a/gcc/config/msp430/msp430.c
+++ b/gcc/config/msp430/msp430.c
@@ -2587,7 +2587,7 @@ msp430_expand_epilogue (int is_eh)
&& helper_n > 1
&& !is_eh)
{
- emit_insn (gen_epilogue_helper (GEN_INT (helper_n)));
+ emit_jump_insn (gen_epilogue_helper (GEN_INT (helper_n)));
return;
}
else
diff --git a/gcc/config/msp430/msp430.md b/gcc/config/msp430/msp430.md
index 815d122d8a8..b6602fbca66 100644
--- a/gcc/config/msp430/msp430.md
+++ b/gcc/config/msp430/msp430.md
@@ -1130,7 +1130,9 @@ (define_expand "epilogue"
)
(define_insn "epilogue_helper"
- [(unspec_volatile [(match_operand 0 "immediate_operand" "i")] UNS_EPILOGUE_HELPER)]
+ [(set (pc)
+(unspec_volatile [(match_operand 0 "immediate_operand" "i")] UNS_EPILOGUE_HELPER))
+ (return)]
""
"BR%Q0\t#__mspabi_func_epilog_%J0"
)
--
2.17.1
[COMMITTED] MSP430: Fix memory offsets used by %C and %D asm output operand modifiers
The %C and %D operand modifiers are supposed to access the 3rd and 4th
words of a 64-bit value, so for memory references they need to offset
the given address by 4 and 6 bytes respectively. Currently they incorrectly
offset the address by 3 and 4 bytes respectively.
Committed the attached patch as obvious.
From 14f27ee6c97c585018882ac8f1f5f2d64618ba66 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Mon, 13 Apr 2020 10:28:01 +0100
Subject: [PATCH] MSP430: Fix memory offsets used by %C and %D asm output
operand modifiers
The %C and %D operand modifiers are supposed to access the 3rd and 4th
words of a 64-bit value, so for memory references they need to offset
the given address by 4 and 6 bytes respectively.
gcc/ChangeLog:
2020-04-13 Jozef Lawrynowicz
* config/msp430/msp430.c (msp430_print_operand): Offset a %C memory
reference by 4 bytes, and %D memory reference by 6 bytes.
gcc/testsuite/ChangeLog:
2020-04-13 Jozef Lawrynowicz
* gcc.target/msp430/operand-modifiers.c: New test.
---
gcc/ChangeLog | 5
gcc/config/msp430/msp430.c| 4 +--
gcc/testsuite/ChangeLog | 4 +++
.../gcc.target/msp430/operand-modifiers.c | 30 +++
4 files changed, 41 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/msp430/operand-modifiers.c
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index f3a226cc711..c0ac32dccf6 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2020-04-13 Jozef Lawrynowicz
+
+ * config/msp430/msp430.c (msp430_print_operand): Offset a %C memory
+ reference by 4 bytes, and %D memory reference by 6 bytes.
+
2020-04-11 Uroš Bizjak
PR target/94494
diff --git a/gcc/config/msp430/msp430.c b/gcc/config/msp430/msp430.c
index e0d2d732ade..96532740ac1 100644
--- a/gcc/config/msp430/msp430.c
+++ b/gcc/config/msp430/msp430.c
@@ -3492,7 +3492,7 @@ msp430_print_operand (FILE * file, rtx op, int letter)
switch (GET_CODE (op))
{
case MEM:
- op = adjust_address (op, Pmode, 3);
+ op = adjust_address (op, Pmode, 4);
break;
case REG:
op = gen_rtx_REG (Pmode, REGNO (op) + 2);
@@ -3510,7 +3510,7 @@ msp430_print_operand (FILE * file, rtx op, int letter)
switch (GET_CODE (op))
{
case MEM:
- op = adjust_address (op, Pmode, 4);
+ op = adjust_address (op, Pmode, 6);
break;
case REG:
op = gen_rtx_REG (Pmode, REGNO (op) + 3);
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 1343b8bec06..b1f232ec0e6 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,7 @@
+2020-04-13 Jozef Lawrynowicz
+
+ * gcc.target/msp430/operand-modifiers.c: New test.
+
2020-04-12 Thomas Koenig
PR fortran/94091
diff --git a/gcc/testsuite/gcc.target/msp430/operand-modifiers.c b/gcc/testsuite/gcc.target/msp430/operand-modifiers.c
new file mode 100644
index 000..ad0a5310839
--- /dev/null
+++ b/gcc/testsuite/gcc.target/msp430/operand-modifiers.c
@@ -0,0 +1,30 @@
+volatile unsigned long si = 0x89abcdef;
+volatile unsigned long long di = 0xfedcba9876543210;
+
+unsigned int a, b, c, d;
+
+int
+main (void)
+{
+ /* Check that %A and %B extract the low and high words of a 32-bit value,
+ respectively. */
+ __asm__("mov %A1, %0\n" : "=m" (a) : "m" (si));
+ __asm__("mov %B1, %0\n" : "=m" (b) : "m" (si));
+ if (a != ((unsigned)si)
+ || b != ((unsigned)(si >> 16)))
+return 1;
+
+ /* Check that %A, %B, %C and %D extract the 1st, 2nd, 3rd and 4th words of a
+ 64-bit value, respectively. */
+ __asm__("mov %A1, %0\n" : "=m" (a) : "m" (di));
+ __asm__("mov %B1, %0\n" : "=m" (b) : "m" (di));
+ __asm__("mov %C1, %0\n" : "=m" (c) : "m" (di));
+ __asm__("mov %D1, %0\n" : "=m" (d) : "m" (di));
+ if (a != ((unsigned)di)
+ || b != ((unsigned)(di >> 16))
+ || c != ((unsigned)(di >> 32))
+ || d != ((unsigned)(di >> 48)))
+return 1;
+
+ return 0;
+}
--
2.17.1
[COMMITTED] MSP430: Don't add offsets to addresses when emitting asm for post_inc
Some insns, which operate on SImode operands, output assembler template
that comprise of multiple instructions using HImode operands. To access
the high word of an SImode operand, an operand selector '%H' is used to
offset the operand value by a constant amount.
When one of these HImode operands is a memory reference to a post_inc,
the address does not need to be offset, since the preceding instruction
has already offset the address to the correct value.
This fixes an ICE in change_address_1, at emit-rtl.c:2318 for
gcc.c-torture/execute/pr20527-1.c in the "-mlarge -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects" configuration.
This test generated the following insn, and the attempt to output the
high part of the post_inc address caused the ICE.
(set (reg:SI 6 R6)
(minus:SI (reg:SI 6 R6)
(mem:SI (post_inc:PSI (reg:PSI 10 R10)) {subsi3}
Committed the attached patch as obvious.
>From 04637536a6b69c6bf7e22e2ccd5ff3bfc4892394 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Fri, 10 Apr 2020 17:31:33 +0100
Subject: [PATCH] MSP430: Dont add offsets to addresses when emitting asm for
post_inc
Some insns, which operate on SImode operands, output assembler template
that comprise of multiple instructions using HImode operands. To access
the high word of an SImode operand, an operand selector '%H' is used to
offset the operand value by a constant amount.
When one of these HImode operands is a memory reference to a post_inc,
the address does not need to be offset, since the preceding instruction
has already offset the address to the correct value.
This fixes an ICE in change_address_1, at emit-rtl.c:2318 for
gcc.c-torture/execute/pr20527-1.c in the "-mlarge -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects" configuration.
This test generated the following insn, and the attempt to output the
high part of the post_inc address caused the ICE.
(set (reg:SI 6 R6)
(minus:SI (reg:SI 6 R6)
(mem:SI (post_inc:PSI (reg:PSI 10 R10)) {subsi3}
gcc/ChangeLog:
2020-04-13 Jozef Lawrynowicz
* config/msp430/msp430.c (msp430_print_operand): Don't add offsets to
memory references in %B, %C and %D operand selectors when the inner
operand is a post increment address.
---
gcc/ChangeLog | 6 ++
gcc/config/msp430/msp430.c | 10 +++---
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index c0ac32dccf6..8bfc2127989 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,9 @@
+2020-04-13 Jozef Lawrynowicz
+
+ * config/msp430/msp430.c (msp430_print_operand): Don't add offsets to
+ memory references in %B, %C and %D operand selectors when the inner
+ operand is a post increment address.
+
2020-04-13 Jozef Lawrynowicz
* config/msp430/msp430.c (msp430_print_operand): Offset a %C memory
diff --git a/gcc/config/msp430/msp430.c b/gcc/config/msp430/msp430.c
index 96532740ac1..e77ca101599 100644
--- a/gcc/config/msp430/msp430.c
+++ b/gcc/config/msp430/msp430.c
@@ -3474,7 +3474,9 @@ msp430_print_operand (FILE * file, rtx op, int letter)
switch (GET_CODE (op))
{
case MEM:
- op = adjust_address (op, Pmode, 2);
+ /* We don't need to adjust the address for post_inc. */
+ op = adjust_address (op, Pmode,
+ (GET_CODE (XEXP (op, 0)) == POST_INC) ? 0 : 2);
break;
case REG:
op = gen_rtx_REG (Pmode, REGNO (op) + 1);
@@ -3492,7 +3494,8 @@ msp430_print_operand (FILE * file, rtx op, int letter)
switch (GET_CODE (op))
{
case MEM:
- op = adjust_address (op, Pmode, 4);
+ op = adjust_address (op, Pmode,
+ (GET_CODE (XEXP (op, 0)) == POST_INC) ? 0 : 4);
break;
case REG:
op = gen_rtx_REG (Pmode, REGNO (op) + 2);
@@ -3510,7 +3513,8 @@ msp430_print_operand (FILE * file, rtx op, int letter)
switch (GET_CODE (op))
{
case MEM:
- op = adjust_address (op, Pmode, 6);
+ op = adjust_address (op, Pmode,
+ (GET_CODE (XEXP (op, 0)) == POST_INC) ? 0 : 6);
break;
case REG:
op = gen_rtx_REG (Pmode, REGNO (op) + 3);
--
2.17.1
[ping][PATCH][MSP430] Don't generate 430X insns when handling data in the lower memory region
ping
On Wed, 11 Sep 2019 11:25:58 +0100
Jozef Lawrynowicz wrote:
> The MSP430 target has a "430X" extension which increases the directly
> addressable memory range from 64KB (16-bit) to 1MB (20-bit).
> This 1MB memory range is split into a "lower" region (below address 0x1)
> and "upper" region (at or above address 0x1).
> When data in the upper region is addressed, 430 instructions cannot be used,
> as
> their 16-bit capability will be exceeded; 430X instructions must be used
> instead. Most 430X instructions require an additional word of op-code, and
> also
> require more cycles to execute compared to their 430 equivalent.
>
> Currently, when the large memory model is specified (-mlarge), 430X
> instructions
> will always be used when addressing a symbol_ref using the absolute addressing
> mode e.g. MOVX #1, &foo.
> The attached patch modifies code generation so that 430X instructions will
> only
> be used when the symbol being addressed will not be placed in the lower memory
> region. This is determined by checking if -mdata-region=lower (the new
> default)
> is passed, or if the "lower" attribute is set on the variable.
>
> Since code will be generated to assume all variables are in the lower memory
> region with -mdata-region=lower, object files built with this option cannot
> be linked with objects files built with other -mdata-region= values.
> To facilitate the checking of this, a patch for binutils (to be submitted
> after this is accepted) is also attached.
>
> The compiler will now generate assembler directives indicating the ISA, memory
> model and data region the source file was compiled with. The assembler will
> check these directives match the options it has been invoked with, and then
> add the attribute to the object file.
>
> Successfully regtested for msp430-elf in the small and large memory model, and
> with -mdata-region=upper. Testing with -mdata-region=upper should expose any
> cases where a 430X instruction is not used where it is required, since all
> data
> is forced into the upper region so a lack of 430X insn would cause a
> relocation
> overflow. In fact the attached patch fixes some relocation overflows by adding
> missing "%X" operand selectors to some insns. One relocation overflow remains
> (pr65077.c), but that is a separate binutils issue.
>
> Ok for trunk?
>From 91371f9a2721e1459429ff7ebdb258b2ef063b04 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Wed, 14 Aug 2019 13:25:03 +0100
Subject: [PATCH] MSP430: Only generate 430X instructions with -mlarge if data
will be in the upper region
gcc/ChangeLog:
2019-09-11 Jozef Lawrynowicz
* config.in: Regenerate.
* config/msp430/constraints.md: Fix docstring for "Ys" constraint.
Add new "Yx" constraint.
* config/msp430/driver-msp430.c (msp430_propagate_region_opt): New spec
function.
* config/msp430/msp430-protos.h (msp430_op_not_in_high_mem): New
prototype.
* config/msp430/msp430.c (msp430_option_override): Allow the lower
code/data region to be selected in the small memory model.
(msp430_section_attr): Don't warn if the "section" and "lower"
attributes are used together.
(msp430_handle_generic_attribute): Likewise.
(msp430_var_in_low_mem): New function.
(TARGET_ENCODE_SECTION_INFO): Define.
(msp430_encode_section_info): New function.
(gen_prefix): Return early in the small memory model.
Require TARGET_USE_LOWER_REGION_PREFIX to be set before adding the
".lower" prefix if -m{code,data}-region=lower have been passed.
(msp430_output_aligned_decl_common): Emit common symbols when
-mdata-region=lower is passed unless TARGET_USE_LOWER_REGION_PREFIX is
set.
(TARGET_ASM_FILE_END): Define.
(msp430_file_end): New function.
(msp430_do_not_relax_short_jumps): Allow relaxation when
function will be in the lower region.
(msp430_op_not_in_high_mem): New function.
(msp430_print_operand): Check "msp430_op_not_in_high_mem" for
the 'X' operand selector.
Clarify comment for 'x' operand selector.
* config/msp430/msp430.h (LINK_SPEC): Propagate
-m{code,data}-region to the linker via spec function
msp430_propagate_region_opt.
(msp430_propagate_region_opt): New prototype.
(EXTRA_SPEC_FUNCTIONS): Add msp430_propagate_region_opt.
(SYMBOL_FLAG_LOW_MEM): Define.
* config/msp430/msp430.md (addsipsi3): Add missing "%X" operand
selector.
(zero_extendqihi2): Fix operand number used by "%X" selector.
(zero_extendqisi2): Likewise.
(zero_extendhisi2): Likewise.
(movqi): Use "Yx" constraint in place of "%X" operand selector.
(movhi): Likewise.
(addqi3): Likewise.
(addhi3): Likewise.
(addsi3): Likewise.
(addhi3_cy): Likewise.
(addchi4_cy): Likewise.
(subqi3): Likew
[PATCH][MSP430] Add support for post increment addressing
MSP430 supports post increment addressing for the source operand only. The
attached patch enables post increment addressing for MSP430 in GCC.
Regtested on trunk for the small and large memory models.
Ok for trunk?
>From d75e48ba434d7bab141c09d442793b2cb26afa69 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Mon, 16 Sep 2019 16:34:51 +0100
Subject: [PATCH] MSP430: Implement post increment addressing
gcc/ChangeLog:
2019-10-07 Jozef Lawrynowicz
* config/msp430/constraints.md: Allow post_inc operand for "Ya"
constraint.
* config/msp430/msp430.c (msp430_legitimate_address_p): Handle
POST_INC.
(msp430_subreg): Likewise.
(msp430_split_addsi): Likewise.
(msp430_print_operand_addr): Likewise.
* config/msp430/msp430.h (HAVE_POST_INCREMENT): Define.
(USE_STORE_POST_INCREMENT): Define.
* config/msp430/msp430.md: Use the msp430_general_dst_operand or
msp430_general_dst_nonv_operand predicates for the lvalues insns.
* config/msp430/predicates.md (msp430_nonpostinc_operand): New.
(msp430_general_dst_operand): New.
(msp430_general_dst_nonv_operand): New.
(msp430_nonsubreg_operand): Remove.
(msp430_nonsubreg_dst_operand): New.
(msp430_nonsubreg_or_imm_operand): Allow reg or mem operands in place
of defunct msp430_nonsubreg_operand.
(msp430_nonsubregnonpostinc_or_imm_operand): New.
---
gcc/config/msp430/constraints.md | 1 +
gcc/config/msp430/msp430.c | 32 +-
gcc/config/msp430/msp430.h | 12 ++
gcc/config/msp430/msp430.md | 191 ---
gcc/config/msp430/predicates.md | 46 +++-
5 files changed, 183 insertions(+), 99 deletions(-)
diff --git a/gcc/config/msp430/constraints.md b/gcc/config/msp430/constraints.md
index 4422b2b6454..d01bcf9a242 100644
--- a/gcc/config/msp430/constraints.md
+++ b/gcc/config/msp430/constraints.md
@@ -60,6 +60,7 @@
(match_code "reg" "00")
(match_test ("CONST_INT_P (XEXP (XEXP (op, 0), 1))")))
(match_test "CONSTANT_P (XEXP (op, 0))")
+ (match_code "post_inc" "0")
)))
(define_constraint "Yl"
diff --git a/gcc/config/msp430/msp430.c b/gcc/config/msp430/msp430.c
index ae763faada3..31029395c3d 100644
--- a/gcc/config/msp430/msp430.c
+++ b/gcc/config/msp430/msp430.c
@@ -942,12 +942,17 @@ msp430_legitimate_address_p (machine_mode mode ATTRIBUTE_UNUSED,
return false;
case PLUS:
+case POST_INC:
if (REG_P (XEXP (x, 0)))
{
if (GET_MODE (x) != GET_MODE (XEXP (x, 0)))
return false;
if (!reg_ok_for_addr (XEXP (x, 0), strict))
return false;
+ if (GET_CODE (x) == POST_INC)
+ /* At this point, if the original rtx was a post_inc, we don't have
+ anything further to check. */
+ return true;
switch (GET_CODE (XEXP (x, 1)))
{
case CONST:
@@ -2810,6 +2815,7 @@ rtx
msp430_subreg (machine_mode mode, rtx r, machine_mode omode, int byte)
{
rtx rv;
+ gcc_assert (mode == HImode);
if (GET_CODE (r) == SUBREG
&& SUBREG_BYTE (r) == 0)
@@ -2826,7 +2832,15 @@ msp430_subreg (machine_mode mode, rtx r, machine_mode omode, int byte)
rv = simplify_gen_subreg (mode, ireg, imode, byte);
}
else if (GET_CODE (r) == MEM)
-rv = adjust_address (r, mode, byte);
+{
+ /* When byte == 2, we can be certain that we were already called with an
+ identical rtx with byte == 0. So we don't need to do anything to
+ get a 2 byte offset of a (mem (post_inc)) rtx, since the address has
+ already been offset by the post_inc itself. */
+ if (GET_CODE (XEXP (r, 0)) == POST_INC && byte == 2)
+ byte = 0;
+ rv = adjust_address (r, mode, byte);
+}
else if (GET_CODE (r) == SYMBOL_REF
&& (byte == 0 || byte == 2)
&& mode == HImode)
@@ -2861,6 +2875,18 @@ msp430_split_addsi (rtx *operands)
if (GET_CODE (operands[5]) == CONST_INT)
operands[9] = GEN_INT (INTVAL (operands[5]) & 0x);
+ /* Handle post_inc, for example:
+ (set (reg:SI)
+ (plus:SI (reg:SI)
+ (mem:SI (post_inc:PSI (reg:PSI). */
+ else if (MEM_P (operands[5]) && GET_CODE (XEXP (operands[5], 0)) == POST_INC)
+{
+ /* Strip out the post_inc from (mem (post_inc (reg))). */
+ operands[9] = XEXP (XEXP (operands[5], 0), 0);
+ operands[9] = gen_rtx_MEM (HImode, operands[9]);
+ /* Then zero extend as normal. */
+ operands[9] = gen_rtx_ZERO_EXTEND (SImode, operands[9]);
+}
else
operands[9] = gen_rtx_ZERO_EXTEND (SImode, operands[5]);
return 0;
@@ -3205,6 +3231,10 @@ msp430_print_operand_addr (FILE * file, machine_mode /*mode*/, rtx addr)
fprintf (file, "@");
break;
+case POST_INC:
+ fprintf (file, "@%s+", reg_names[REGNO (XEXP (addr, 0))]);
+ return;
+
case CONST:
case CONST_INT:
case SYMBOL_REF:
diff --git a/gcc/config/msp430/msp430.h b/gcc/config/msp430/ms
[COMMITTED][MSP430] Move C code for addsi define_split to its own function
In preparation for upcoming changes to the addsi splitter, the attached patch
puts C code to perform the splitting in its own function.
Regtested on trunk.
Committed as obvious.
From 41e73d742fda612b0978cf84ae8732b430c4ef5a Mon Sep 17 00:00:00 2001
From: jozefl
Date: Mon, 7 Oct 2019 20:05:30 +
Subject: [PATCH] 2019-10-07 Jozef Lawrynowicz
* config/msp430/msp430-protos.h (msp430_split_addsi): New prototype.
* config/msp430/msp430.c (msp430_split_addsi): New.
* config/msp430/msp430.md: Call msp430_split_addsi () instead of using
a block of C code for splitting addsi.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@276670 138bc75d-0d04-0410-961f-82ee72b054a4
---
gcc/ChangeLog | 7 +++
gcc/config/msp430/msp430-protos.h | 1 +
gcc/config/msp430/msp430.c| 23 +++
gcc/config/msp430/msp430.md | 20 +++-
4 files changed, 34 insertions(+), 17 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index bbdce86a0f8..91ebb5a114c 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,10 @@
+2019-10-07 Jozef Lawrynowicz
+
+ * config/msp430/msp430-protos.h (msp430_split_addsi): New prototype.
+ * config/msp430/msp430.c (msp430_split_addsi): New.
+ * config/msp430/msp430.md: Call msp430_split_addsi () instead of using
+ a block of C code for splitting addsi.
+
2019-10-07 Uroš Bizjak
* config/i386/i386-expand.c (ix86_expand_floorceildf_32,
diff --git a/gcc/config/msp430/msp430-protos.h b/gcc/config/msp430/msp430-protos.h
index 1c1757fc7ab..37ca48297ac 100644
--- a/gcc/config/msp430/msp430-protos.h
+++ b/gcc/config/msp430/msp430-protos.h
@@ -44,6 +44,7 @@ void msp430_output_labelref (FILE *, const char *);
void msp430_register_pragmas (void);
rtx msp430_return_addr_rtx (int);
void msp430_split_movsi (rtx *);
+int msp430_split_addsi (rtx *);
voidmsp430_start_function (FILE *, const char *, tree);
rtx msp430_subreg (machine_mode, rtx, machine_mode, int);
boolmsp430_use_f5_series_hwmult (void);
diff --git a/gcc/config/msp430/msp430.c b/gcc/config/msp430/msp430.c
index 354b4ddb419..add19bdb97c 100644
--- a/gcc/config/msp430/msp430.c
+++ b/gcc/config/msp430/msp430.c
@@ -2841,6 +2841,29 @@ msp430_subreg (machine_mode mode, rtx r, machine_mode omode, int byte)
return rv;
}
+int
+msp430_split_addsi (rtx *operands)
+{
+ operands[3] = msp430_subreg (HImode, operands[0], SImode, 0);
+ operands[4] = msp430_subreg (HImode, operands[1], SImode, 0);
+ operands[5] = msp430_subreg (HImode, operands[2], SImode, 0);
+ operands[6] = msp430_subreg (HImode, operands[0], SImode, 2);
+ operands[7] = msp430_subreg (HImode, operands[1], SImode, 2);
+ operands[8] = msp430_subreg (HImode, operands[2], SImode, 2);
+
+ /* BZ 64160: Do not use this splitter when the dest partially overlaps the
+ source. */
+ if (reg_overlap_mentioned_p (operands[3], operands[7])
+ || reg_overlap_mentioned_p (operands[3], operands[8]))
+return 1;
+
+ if (GET_CODE (operands[5]) == CONST_INT)
+operands[9] = GEN_INT (INTVAL (operands[5]) & 0x);
+ else
+operands[9] = gen_rtx_ZERO_EXTEND (SImode, operands[5]);
+ return 0;
+}
+
/* Called by movsi_x to generate the HImode operands. */
void
msp430_split_movsi (rtx *operands)
diff --git a/gcc/config/msp430/msp430.md b/gcc/config/msp430/msp430.md
index c72f7aade30..e1c61f5ea3d 100644
--- a/gcc/config/msp430/msp430.md
+++ b/gcc/config/msp430/msp430.md
@@ -423,23 +423,9 @@
(zero_extend:HI (reg:BI CARRY
]
"
- operands[3] = msp430_subreg (HImode, operands[0], SImode, 0);
- operands[4] = msp430_subreg (HImode, operands[1], SImode, 0);
- operands[5] = msp430_subreg (HImode, operands[2], SImode, 0);
- operands[6] = msp430_subreg (HImode, operands[0], SImode, 2);
- operands[7] = msp430_subreg (HImode, operands[1], SImode, 2);
- operands[8] = msp430_subreg (HImode, operands[2], SImode, 2);
-
- /* BZ 64160: Do not use this splitter when the dest partially overlaps the source. */
- if (reg_overlap_mentioned_p (operands[3], operands[7])
- || reg_overlap_mentioned_p (operands[3], operands[8]))
- FAIL;
-
- if (GET_CODE (operands[5]) == CONST_INT)
- operands[9] = GEN_INT (INTVAL (operands[5]) & 0x);
- else
- operands[9] = gen_rtx_ZERO_EXTEND (SImode, operands[5]);
- "
+ if (msp430_split_addsi (operands))
+FAIL;
+ "
)
--
2.17.1
