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
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 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 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, > > thereby allowing the new functionality to be used without linker script > > modifica
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
[PATCH] configure: Extend SHF_GNU_RETAIN conftest to check for unsupported gold
Since "6fbec038f7a Use SHF_GNU_RETAIN to preserve symbol definitions",
GCC could create sections with the 'R' flag, which GAS would map to
SHF_GNU_RETAIN.
SHF_GNU_RETAIN support was not available in gold until Binutils commit
ff4bc37d77, on 2020-12-14. Until the support was added, invalid binaries
could be created if some special sections, such as .init_array, had
SHF_GNU_RETAIN set.
HAVE_GAS_SHF_GNU_RETAIN is now disabled if a version of gold without
SHF_GNU_RETAIN support is detected.
I tested that HAVE_GAS_SHF_GNU_RETAIN was enabled/disabled as
appropriate in a number of configurations, using both in-tree and
out-of-tree Binutils:
- Before the Binutils gold patch:
* gold disabled == SHF_GNU_RETAIN enabled
* gold enabled == SHF_GNU_RETAIN disabled
- After the Binutils gold patch:
* gold disabled == SHF_GNU_RETAIN enabled
* gold enabled == SHF_GNU_RETAIN enabled
Successfully bootstrapped for x86_64-pc-linux-gnu.
Ok to apply?
>From af3000bbacc6d8ca57581c11790032b73ea944ac Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Wed, 16 Dec 2020 18:33:54 +
Subject: [PATCH] configure: Extend SHF_GNU_RETAIN conftest to check for
unsupported gold
Since "6fbec038f7a Use SHF_GNU_RETAIN to preserve symbol definitions",
GCC could create sections with the 'R' flag, which GAS would map to
SHF_GNU_RETAIN.
SHF_GNU_RETAIN support was not available in gold until Binutils commit
ff4bc37d77, on 2020-12-14. Until the support was added, invalid binaries
could be created if some special sections, such as .init_array, had
SHF_GNU_RETAIN set.
HAVE_GAS_SHF_GNU_RETAIN is now disabled if a version of gold without
SHF_GNU_RETAIN support is detected.
gcc/ChangeLog:
PR target/98210
* configure: Regenerate.
* configure.ac (gcc_cv_as_shf_gnu_retain): Disable
HAVE_GAS_SHF_GNU_RETAIN for gold versions that do not support it.
---
gcc/configure| 60 -
gcc/configure.ac | 64 +---
2 files changed, 120 insertions(+), 4 deletions(-)
diff --git a/gcc/configure b/gcc/configure
index 9a27e459f14..544ec92463e 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -24442,7 +24442,63 @@ case "${target}" in
gcc_cv_as_shf_gnu_retain=no
;;
*)
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking assembler for section
'R' flag" >&5
+# gold did not support SHF_GNU_RETAIN until 2.35.50.20201215.
+# Support for SHF_GNU_RETAIN in GCC was only added on 2020-12-01, so rather
+# than only disabling the GCC functionality if gold is the default, disable
+# it if a gold without the support has been built at all.
+
+ld_gold=`which ${gcc_cv_ld}.gold`
+check_gold_ver=no
+if test x$ld_is_gold = xyes; then
+ # Always check_gold_ver when gold is the default linker.
+ check_gold_ver=yes
+ gold_date=$ld_date
+elif test -f ../gold/ld-new$build_exeext; then
+ # Always check_gold_ver when gold has been built in-tree.
+ check_gold_ver=yes
+ gold_ver=`../gold/ld-new$build_exeext --version 2>/dev/null | sed 1q`
+ gold_date=`echo $gold_ver | sed -n
's,^.*\([2-9][0-9][0-9][0-9]\)\(-*\)\([01][0-9]\)\2\([0-3][0-9]\).*$,\1\3\4,p'`
+elif test -n "$ld_gold"; then
+ gold_ver=`${gcc_cv_ld}.gold --version 2>/dev/null | sed 1q`
+ gold_vers=`echo $gold_ver | sed -n \
+ -e 's,^[^)]*[ ]\([0-9][0-9]*\.[0-9][0-9]*[^)]*\)) .*$,\1,p'`
+ gold_date=`echo $gold_ver | sed -n
's,^.*\([2-9][0-9][0-9][0-9]\)\(-*\)\([01][0-9]\)\2\([0-3][0-9]\).*$,\1\3\4,p'`
+ gold_vers_major=`expr "$gold_vers" : '\([0-9]*\)'`
+ gold_vers_minor=`expr "$gold_vers" : '[0-9]*\.\([0-9]*\)'`
+ gold_vers_patch=`expr "$gold_vers" : '[0-9]*\.[0-9]*\.\([0-9]*\)'`
+
+ # If gold exists but is not the default linker, we assume that it is
+ # still intended to be used if the version matches the default ld.
+ if test 0"$gold_vers_major" -eq 0"$ld_vers_major" \
+ && test 0"$gold_vers_minor" -eq 0"$ld_vers_minor" \
+ && test 0"$gold_vers_patch" -eq 0"$ld_vers_patch" \
+ && test 0"$gold_date" -eq 0"$ld_date"; then
+ check_gold_ver=yes
+ fi
+fi
+
+# To test for the period of time when the SHF_GNU_RETAIN flag is supported
+# in ld, but not in gold, check the date in the version string. If there
+# is no date, then we let gcc_GAS_CHECK_FEATURE make the correct
+# choice.
+if test $check_gold_ver = yes && test -n "$gold_date" \
+ && test 0"$gold_date" -lt 20201215; then
+ gcc_cv_as_shf_gnu_retain=no
+ { $as_echo "$as_me:${as_lineno-$LINENO}: checking gold support for
SHF_GNU_RETAIN" >&5
+$as_echo_n "checking go
Re: [committed][wwwdocs] gcc-11/changes: "used" attribute saves decls from linker garbage collection
On Tue, Dec 15, 2020 at 12:48:47AM +0100, Gerald Pfeifer wrote:
> On Mon, 7 Dec 2020, Jozef Lawrynowicz wrote:
> > Committed as obvious.
>
> Thank you!
>
> +
> +For ELF targets that support the GNU or FreeBSD OSABIs, the
> +used attribute will now save the symbol declaration it is
> +applied to from linker garbage collection.
> +
> +To support this behavior, used symbols that have not
> +been placed in specific sections (e.g. with the section
> +attribute, or the -f{function,data}-sections options) will
> +be placed in new, unique sections.
> +
> +This functionality requires Binutils version 2.36 or later.
> +
>
> Have you considered using ... around the three blocks of
> text instead of in between?
>
> An open question, it's okay to keep as is if you prefer.
I did try with ..., but I thought the additional line spacing
just looked a little out of place amongst all the other lines in this
section, which are list items so have compact line spacing. However,
since they are separate paragraphs there should be some formatting to
show this.
Also, I guess that using to override the house style in this way is
a bit of a no-no, so I will change it to
Committed the attached patch.
Thanks,
Jozef
>From fb048b7d45422cd869772462cba591a46f1b3b2f Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Tue, 15 Dec 2020 11:19:41 +
Subject: [PATCH] gcc-11/changes: Use instead of for "used" attribute
description
---
htdocs/gcc-11/changes.html | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html
index ea9fe93c..1a9e72c1 100644
--- a/htdocs/gcc-11/changes.html
+++ b/htdocs/gcc-11/changes.html
@@ -159,16 +159,20 @@ a work-in-progress.
+
For ELF targets that support the GNU or FreeBSD OSABIs, the
used attribute will now save the symbol declaration it is
applied to from linker garbage collection.
-
+
+
To support this behavior, used symbols that have not
been placed in specific sections (e.g. with the section
attribute, or the -f{function,data}-sections options) will
be placed in new, unique sections.
-
+
+
This functionality requires Binutils version 2.36 or later.
+
--
2.29.2
[committed][wwwdocs] gcc-11/changes: "used" attribute saves decls from linker garbage collection
Since 6fbec038f7a, the "used" attribute will save the symbol declaration
it is applied to from linker garbage collection, if the target supports
the SHF_GNU_RETAIN section flag.
This patch documents this functionality in the GCC 11 changes document.
Some users might need to amend their source code to handle the fact that
GCC can now place "used" decls in a new, unique section.
Committed as obvious.
>From 7c56c86ebe102849ec239f0c57e93988169d90f4 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Mon, 7 Dec 2020 14:41:13 +
Subject: [PATCH] gcc-11/changes: "used" attribute saves decls from linker
garbage collection
---
htdocs/gcc-11/changes.html | 12
1 file changed, 12 insertions(+)
diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html
index ed289744..4d3efed5 100644
--- a/htdocs/gcc-11/changes.html
+++ b/htdocs/gcc-11/changes.html
@@ -158,6 +158,18 @@ a work-in-progress.
+
+For ELF targets that support the GNU or FreeBSD OSABIs, the
+used attribute will now save the symbol declaration it is
+applied to from linker garbage collection.
+
+To support this behavior, used symbols that have not
+been placed in specific sections (e.g. with the section
+attribute, or the -f{function,data}-sections options) will
+be placed in new, unique sections.
+
+This functionality requires Binutils version 2.36 or later.
+
C++
--
2.29.2
[committed] doc: "used" attribute saves decls from linker garbage collection
Since 6fbec038f7a, the "used" attribute will save the symbol declaration
it is applied to from linker garbage collection, if the target supports
the SHF_GNU_RETAIN section flag.
This patch documents this new functionality.
Committed as obvious.
>From 724390745213d5192af04a51bb08cf44da7c396d Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Mon, 7 Dec 2020 14:26:46 +
Subject: [PATCH] doc: "used" attribute saves decls from linker garbage
collection
gcc/ChangeLog:
* doc/extend.texi (used function attribute): Document saving
the declaration from linker garbage collection.
(used variable attribute): Likewise.
---
gcc/doc/extend.texi | 16
1 file changed, 16 insertions(+)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index fd282aa0157..0c969085d1f 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -3859,6 +3859,14 @@ When applied to a member function of a C++ class
template, the
attribute also means that the function is instantiated if the
class itself is instantiated.
+For ELF targets that support the GNU or FreeBSD OSABIs, this attribute
+will also save the function from linker garbage collection. To support
+this behavior, functions that have not been placed in specific sections
+(e.g. by the @code{section} attribute, or the @code{-ffunction-sections}
+option), will be placed in new, unique sections.
+
+This additional functionality requires Binutils version 2.36 or later.
+
@item visibility ("@var{visibility_type}")
@cindex @code{visibility} function attribute
This attribute affects the linkage of the declaration to which it is attached.
@@ -7420,6 +7428,14 @@ When applied to a static data member of a C++ class
template, the
attribute also means that the member is instantiated if the
class itself is instantiated.
+For ELF targets that support the GNU or FreeBSD OSABIs, this attribute
+will also save the variable from linker garbage collection. To support
+this behavior, variables that have not been placed in specific sections
+(e.g. by the @code{section} attribute, or the @code{-fdata-sections} option),
+will be placed in new, unique sections.
+
+This additional functionality requires Binutils version 2.36 or later.
+
@item vector_size (@var{bytes})
@cindex @code{vector_size} variable attribute
This attribute specifies the vector size for the type of the declared
--
2.29.2
Re: [PATCH 0/2] Switch to a new section if the SECTION_RETAIN bit doesn't match
On Fri, Dec 04, 2020 at 05:16:38AM -0800, H.J. Lu via Gcc-patches wrote: > On Fri, Dec 4, 2020 at 4:17 AM Jozef Lawrynowicz > wrote: > > > > On Thu, Dec 03, 2020 at 04:06:50PM -0800, H.J. Lu via Gcc-patches wrote: > > > When SECTION_RETAIN is used, definitions marked with used attribute and > > > unmarked definitions are placed in the same section. Instead of issue > > > an error: > > > > > > [hjl@gnu-cfl-2 gcc]$ /usr/gcc-11.0.0-x32/bin/gcc -S c.c > > > -fdiagnostics-plain-output > > > c.c:2:49: error: ‘foo1’ causes a section type conflict with ‘foo2’ > > > c.c:1:54: note: ‘foo2’ was declared here > > > [hjl@gnu-cfl-2 gcc]$ > > > > > > the first patch switches to a new section if the SECTION_RETAIN bit > > > doesn't match. The second optional patch issues a warning: > > > > > > [hjl@gnu-cfl-2 gcc]$ ./xgcc -B./ -S c.c -fdiagnostics-plain-output > > > c.c:2:49: warning: ‘foo1’ without ‘used’ attribute is placed in a section > > > with ‘foo2’ with ‘used’ attribute [-Wattributes] > > > [hjl@gnu-cfl-2 gcc]$ > > > > I think the warning is useful, since we are modifying the structure of > > the object file where the user may not expect it. It ensures they review > > which declarations have "used" applied so they don't unexpectedly lose > > parts of their program they wanted to keep by putting them in a > > section that was marked "used" elsewhere. > > I agree. > > > > > > > H.J. Lu (2): > > > Switch to a new section if the SECTION_RETAIN bit doesn't match > > > Warn used and not used symbols in the same section > > > > We should probably use a new PR to associate with these patches, rather > > than PR/98121. > > > > Your changes here address the issue exposed by glibc code, whilst 98121 > > was for the broader issue of whether "used" should apply SHF_GNU_RETAIN. > > > > Let me know if you agree, and I'll create a new GCC PR for the specific > > Please do. Filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98146. Thanks, Jozef
Re: [PATCH 0/2] Switch to a new section if the SECTION_RETAIN bit doesn't match
On Thu, Dec 03, 2020 at 04:06:50PM -0800, H.J. Lu via Gcc-patches wrote: > When SECTION_RETAIN is used, definitions marked with used attribute and > unmarked definitions are placed in the same section. Instead of issue > an error: > > [hjl@gnu-cfl-2 gcc]$ /usr/gcc-11.0.0-x32/bin/gcc -S c.c > -fdiagnostics-plain-output > c.c:2:49: error: ‘foo1’ causes a section type conflict with ‘foo2’ > c.c:1:54: note: ‘foo2’ was declared here > [hjl@gnu-cfl-2 gcc]$ > > the first patch switches to a new section if the SECTION_RETAIN bit > doesn't match. The second optional patch issues a warning: > > [hjl@gnu-cfl-2 gcc]$ ./xgcc -B./ -S c.c -fdiagnostics-plain-output > c.c:2:49: warning: ‘foo1’ without ‘used’ attribute is placed in a section > with ‘foo2’ with ‘used’ attribute [-Wattributes] > [hjl@gnu-cfl-2 gcc]$ I think the warning is useful, since we are modifying the structure of the object file where the user may not expect it. It ensures they review which declarations have "used" applied so they don't unexpectedly lose parts of their program they wanted to keep by putting them in a section that was marked "used" elsewhere. > > H.J. Lu (2): > Switch to a new section if the SECTION_RETAIN bit doesn't match > Warn used and not used symbols in the same section We should probably use a new PR to associate with these patches, rather than PR/98121. Your changes here address the issue exposed by glibc code, whilst 98121 was for the broader issue of whether "used" should apply SHF_GNU_RETAIN. Let me know if you agree, and I'll create a new GCC PR for the specific issue that was exposed by glibc. We should then mark 98121 as resolved/rejected, since we are not changing whether "used" applies SHF_GNU_RETAIN. Thanks, Jozef > > gcc/output.h | 2 +- > gcc/testsuite/c-c++-common/attr-used-5.c | 27 +++ > gcc/testsuite/c-c++-common/attr-used-6.c | 27 +++ > gcc/testsuite/c-c++-common/attr-used-7.c | 9 + > gcc/testsuite/c-c++-common/attr-used-8.c | 9 + > gcc/varasm.c | 43 +--- > 6 files changed, 112 insertions(+), 5 deletions(-) > create mode 100644 gcc/testsuite/c-c++-common/attr-used-5.c > create mode 100644 gcc/testsuite/c-c++-common/attr-used-6.c > create mode 100644 gcc/testsuite/c-c++-common/attr-used-7.c > create mode 100644 gcc/testsuite/c-c++-common/attr-used-8.c > > -- > 2.28.0 >
Re: [PATCH 1/2] Switch to a new section if the SECTION_RETAIN bit doesn't match
Hi H.J.,
On Thu, Dec 03, 2020 at 04:06:51PM -0800, H.J. Lu via Gcc-patches wrote:
> When definitions marked with used attribute and unmarked definitions are
> placed in the same section, switch to a new section if the SECTION_RETAIN
> bit doesn't match.
GAS doesn't create separate sections for
.section .data.foo,"aw"
.section .data.foo,"awR"
A single .data.foo section, with SHF_GNU_RETAIN set, is output to the
object file.
This is because the addition of SHF_GNU_RETAIN support to the "used"
attribute was not supposed to be modifying the layout of sections in the
object file.
Now we are placing "used" decls in a new, unique section (when they
don't already have a unique section), I suppose it is fine to have two
separate sections for retained/non-retained .data.foo in the object
file.
It does feel like a bit of a kludge that we end up with
[ 4] .data.foo PROGBITS 40 06 00 WA 0 0 1
[ 5] .data.foo PROGBITS 46 06 00 WAR 0 0 1
but it is beneficial to the user, since linker garbage collection
will remove more unused parts of their program.
Your commit "2be7ea19b3 Add SEC_ASSEMBLER_SHF_MASK" on x86-binutils
implements this, it just needs some fix ups to apply cleanly.
Note that when .section is used without any section attributes
specified, then the non-SHF_GNU_RETAIN section is switched to.
I would expect it to switch to the most recently switched to section.
After applying your above SEC_ASSEMBLER_SHF_MASK commit, the following
assembly code:
.section .data.foo,"aw"
.word 0
.section .data.foo
.word 0
.section .data.foo,"awR"
.word 0
.section .data.foo
.word 0
results in the following section layout
sh_size
[ 4] .data.foo PROGBITS 40 06 00 WA 0 0 1
[ 5] .data.foo PROGBITS 46 02 00 WAR 0 0 1
As you can see, the final ".section .data.foo" instance has been
associated with the non-SHF_GNU_RETAIN section.
To align with this GCC patch, the final ".section .data.foo" directive
should in fact switch to the most recently switched to section, which
would be the SHF_GNU_RETAIN instance of .data.foo.
I've included some other comments inline with the patch
Thanks,
Jozef
>
> gcc/
>
> PR other/98121
> * output.h (switch_to_section): Add a tree argument, default to
> nullptr.
> * varasm.c (get_section): If the SECTION_RETAIN bit doesn't match,
> return and switch to a new section later.
> (assemble_start_function): Pass decl to switch_to_section.
> (assemble_variable): Likewise.
> (switch_to_section): If the SECTION_RETAIN bit doesn't match,
> switch to a new section.
>
> gcc/testsuite/
>
> PR other/98121
> * c-c++-common/attr-used-5.c: New test.
> * c-c++-common/attr-used-6.c: Likewise.
> * c-c++-common/attr-used-7.c: Likewise.
> * c-c++-common/attr-used-8.c: Likewise.
> ---
> gcc/output.h | 2 +-
> gcc/testsuite/c-c++-common/attr-used-5.c | 26 ++
> gcc/testsuite/c-c++-common/attr-used-6.c | 26 ++
> gcc/testsuite/c-c++-common/attr-used-7.c | 8 +++
> gcc/testsuite/c-c++-common/attr-used-8.c | 8 +++
> gcc/varasm.c | 28
> 6 files changed, 93 insertions(+), 5 deletions(-)
> create mode 100644 gcc/testsuite/c-c++-common/attr-used-5.c
> create mode 100644 gcc/testsuite/c-c++-common/attr-used-6.c
> create mode 100644 gcc/testsuite/c-c++-common/attr-used-7.c
> create mode 100644 gcc/testsuite/c-c++-common/attr-used-8.c
>
> diff --git a/gcc/output.h b/gcc/output.h
> index fa8ace1f394..1f9af46da1d 100644
> --- a/gcc/output.h
> +++ b/gcc/output.h
> @@ -548,7 +548,7 @@ extern void switch_to_other_text_partition (void);
> extern section *get_cdtor_priority_section (int, bool);
>
> extern bool unlikely_text_section_p (section *);
> -extern void switch_to_section (section *);
> +extern void switch_to_section (section *, tree = nullptr);
> extern void output_section_asm_op (const void *);
>
> extern void record_tm_clone_pair (tree, tree);
> diff --git a/gcc/testsuite/c-c++-common/attr-used-5.c
> b/gcc/testsuite/c-c++-common/attr-used-5.c
> new file mode 100644
> index 000..9fc0d3834e9
> --- /dev/null
> +++ b/gcc/testsuite/c-c++-common/attr-used-5.c
> @@ -0,0 +1,26 @@
> +/* { dg-do compile } */
> +/* { dg-options "-Wall -O2" } */
> +
> +struct dtv_slotinfo_list
> +{
> + struct dtv_slotinfo_list *next;
> +};
> +
> +extern struct dtv_slotinfo_list *list;
> +
> +static int __attribute__ ((section ("__libc_freeres_fn")))
> +free_slotinfo (struct dtv_slotinfo_list **elemp)
> +{
> + if (!free_slotinfo (&(*elemp)->next))
> +return 0;
> + return 1;
> +}
> +
> +__attribute__ ((used, section ("__libc_freeres_fn")))
> +static void free_mem (void)
> +{
> + free_slotinfo ();
> +}
> +
> +/* {
[committed] MSP430: Remove target-specific handling of the "persistent" attribute
The "persistent" attribute is now handled generically, and does not
need specific support in the MSP430 back end.
Successfully built and regtested C/C++ testsuites for msp430-elf.
Committed as obvious.
>From 77ee207e17d02e4aec502c6aedd9b0ba36a08de3 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Mon, 23 Nov 2020 14:24:43 +
Subject: [PATCH] MSP430: Remove target-specific handling of the "persistent"
attribute
The "persistent" attribute is now handled generically, and does not
need specific support in the MSP430 back end.
gcc/ChangeLog:
* config/msp430/msp430.c (msp430_section_attr): Don't warn for "lower"
attribute used with "noinit" or "persistent" attributes.
(msp430_persist_attr): Remove.
(attr_lower_exclusions): Remove ATTR_PERSIST exclusion.
(attr_upper_exclusions): Likewise.
(attr_either_exclusions): Likewise.
(attr_persist_exclusions): Remove.
(msp430_attribute_table): Remove ATTR_PERSIST handling.
(msp430_handle_generic_attribute): Remove ATTR_PERSIST section conflict
handling.
(TARGET_ASM_INIT_SECTIONS): Remove.
(msp430_init_sections): Remove.
(msp430_select_section): Use default_elf_select_section for decls with
the "persistent" attribute.
(msp430_section_type_flags): Remove ".persistent" section handling.
* doc/extend.texi (MSP430 Variable Attributes): Remove "noinit" and
"persistent" documentation.
gcc/testsuite/ChangeLog:
* g++.target/msp430/data-attributes.C: Remove expected warnings for
"lower" attribute conflicts.
Adjust expected wording for "persistent" attribute misuse.
* gcc.target/msp430/data-attributes-2.c: Likewise.
* gcc.target/msp430/pr78818-auto-warn.c: Likewise.
---
gcc/config/msp430/msp430.c| 114 +++---
gcc/doc/extend.texi | 17 ---
.../g++.target/msp430/data-attributes.C | 19 +--
.../gcc.target/msp430/data-attributes-2.c | 14 +--
.../gcc.target/msp430/pr78818-auto-warn.c | 4 +-
5 files changed, 36 insertions(+), 132 deletions(-)
diff --git a/gcc/config/msp430/msp430.c b/gcc/config/msp430/msp430.c
index 51f49edffa8..db3a9ff5330 100644
--- a/gcc/config/msp430/msp430.c
+++ b/gcc/config/msp430/msp430.c
@@ -1968,15 +1968,18 @@ msp430_section_attr (tree * node,
const char * message = NULL;
- /* The "noinit" and "section" attributes are handled generically, so we
- cannot set up additional target-specific attribute exclusions using the
- existing mechanism. */
- if (has_attr (ATTR_NOINIT, *node))
+ /* The "noinit", "persistent", and "section" attributes are handled
+ generically, so we cannot set up additional target-specific attribute
+ exclusions using the existing mechanism. */
+ if (has_attr (ATTR_NOINIT, *node) && !TREE_NAME_EQ (name, "lower"))
message = G_("ignoring attribute %qE because it conflicts with "
"attribute %");
else if (has_attr ("section", *node) && !TREE_NAME_EQ (name, "lower"))
message = G_("ignoring attribute %qE because it conflicts with "
"attribute %");
+ else if (has_attr (ATTR_PERSIST, *node) && !TREE_NAME_EQ (name, "lower"))
+message = G_("ignoring attribute %qE because it conflicts with "
+"attribute %");
/* It does not make sense to use upper/lower/either attributes without
-mlarge.
Without -mlarge, "lower" is the default and only region, so is redundant.
@@ -1997,56 +2000,6 @@ msp430_section_attr (tree * node,
return NULL_TREE;
}
-static tree
-msp430_persist_attr (tree *node,
- tree name,
- tree args,
- intflags ATTRIBUTE_UNUSED,
- bool * no_add_attrs ATTRIBUTE_UNUSED)
-{
- const char * message = NULL;
-
- gcc_assert (DECL_P (* node));
- gcc_assert (args == NULL);
- gcc_assert (TREE_NAME_EQ (name, ATTR_PERSIST));
-
- /* Check for the section attribute separately from DECL_SECTION_NAME so
- we can provide a clearer warning. */
- if (has_attr ("section", *node))
-message = G_("ignoring attribute %qE because it conflicts with "
-"attribute %");
- /* Check that it's possible for the variable to have a section. */
- else if ((TREE_STATIC (*node) || DECL_EXTERNAL (*node) || in_lto_p)
- && (DECL_SECTION_NAME (*node)))
-message = G_("%qE attribute cannot be applied to variables with specific "
-"sections");
- else if (has_attr (ATTR_NOINIT, *node))
-message = G_("ignoring a
Re: [PATCH 0/2] Improve MSP430 hardware multiply support
On Mon, Nov 16, 2020 at 06:36:17PM -0700, Jeff Law via Gcc-patches wrote:
>
>
> On 11/15/20 2:14 PM, Jozef Lawrynowicz wrote:
> > 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(-)
> Both are fine.
Thanks.
>
> BTW, what would be a reasonable set of multlibs for automated testing?
> My tester has the ability to define them on a per-target basis, but I
> haven't tried to do that except for targets that I happen to know
> well. So right now it's just using the default via
> -target_board=msp430-sim. Figure we've probably got a time budget to
> add 3 multilibs without causing headaches. What 3 might you suggest?
In addition to the default config, I would suggest:
msp430-sim/-mcpu=msp430
Test the 430 ISA
msp430-sim/-mlarge/-mcode-region=either
Test the large memory model with data assumed to be in the lower
memory region (default, reduces code size penalty of using -mlarge),
whilst shuffling code between the upper and lower memory regions to
make the program fit.
msp430-sim/-mlarge/-mdata-region=either/-mcode-region=either
Test the large memory model, shuffling code and data between upper
and lower memory regions.
I should really use -mlarge/-mcode-region=either, instead of just
-mlarge, as well. -mcode-region=either doesn't change code gen, just
allows the linker shuffling of text sections so more tests build and so
we get better test coverage.
With limited testing capacity, testing hwmult configs is not very useful
unless hwmult behavior is specifically changed. There are msp430
specific tests to verify the options basically work.
Thanks,
Jozef
[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_hw MP
[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 ()
? _cost_multlib_32bit
: _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_mcu_data.hwmpy == 1
+
[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
[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 (, 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__((persistent,lower)) pl = 20; /* { dg-warn
[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 | 16 ++
[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 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/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;
+}
+ }
+)
+
+(define
[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
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"
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
> > create mode 100
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) > > > > > > >>>>>>>> }
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 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 on symbol table:
> > &g
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: 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 > >
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 performance/co
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
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 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
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 section.
With -fdat
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\"&q
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 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.
[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_retain_r=yes
+el
Re: [RFC] Add support for the "retain" attribute utilizing SHF_GNU_RETAIN
On Mon, Oct 26, 2020 at 07:08:06PM +, Pedro Alves via Gcc-patches wrote:
> On 10/6/20 12:10 PM, Jozef Lawrynowicz wrote:
>
> > Should "used" apply SHF_GNU_RETAIN?
> > ===
> > Another talking point is whether the existing "used" attribute should
> > apply the SHF_GNU_RETAIN flag to the containing section.
> >
> > It seems unlikely that a user applies the "used" attribute to a
> > declaration, and means for it to be saved from only compiler
> > optimization, but *not* linker optimization. So perhaps it would be
> > beneficial for "used" to apply SHF_GNU_RETAIN in some way.
> >
> > If "used" did apply SHF_GNU_RETAIN, we would also have to
> > consider the above options for how to apply SHF_GNU_RETAIN to the
> > section. Since the "used" attribute has been around for a while
> > it might not be appropriate for its behavior to be changed to place the
> > associated declaration in its own, unique section, as in option (2).
> >
>
> To me, if I use attribute((used)), and the linker still garbage
> collects the symbol, then the toolchain has a bug. Is there any
> use case that would suggest otherwise?
I revised the implementation so the "used" attribute will save the
symbol from garbage collection.
By implementing the TARGET_MARK_DECL_PRESERVED macro, a
".retain " directive will be emitted for decls that had the
"used" attribute applied.
GAS will set the SHF_GNU_RETAIN flag on sections containing symbols
referenced in ".retain" directives.
GAS still supports setting the "R" flag in .section directives, but GCC
won't emit these.
LD will save SHF_GNU_RETAIN sections from garbage collection.
For reference, I've attached the Binutils and GCC patches that implement
this. The results from a bootstrap and regtest for x86_64-pc-linux-gnu
and light testing for arm-eabi are looking good, but I need to add more
tests and clean the patches up before final submission.
Thanks!
Jozef
>
> Thanks,
> Pedro Alves
>
diff --git a/bfd/elf-bfd.h b/bfd/elf-bfd.h
index 140a98594d..ffb75f7919 100644
--- a/bfd/elf-bfd.h
+++ b/bfd/elf-bfd.h
@@ -1897,14 +1897,15 @@ struct output_elf_obj_tdata
bfd_boolean flags_init;
};
-/* Indicate if the bfd contains SHF_GNU_MBIND sections or symbols that
- have the STT_GNU_IFUNC symbol type or STB_GNU_UNIQUE binding. Used
- to set the osabi field in the ELF header structure. */
+/* Indicate if the bfd contains SHF_GNU_MBIND/SHF_GNU_RETAIN sections or
+ symbols that have the STT_GNU_IFUNC symbol type or STB_GNU_UNIQUE
+ binding. Used to set the osabi field in the ELF header structure. */
enum elf_gnu_osabi
{
elf_gnu_osabi_mbind = 1 << 0,
elf_gnu_osabi_ifunc = 1 << 1,
elf_gnu_osabi_unique = 1 << 2,
+ elf_gnu_osabi_retain = 1 << 3,
};
typedef struct elf_section_list
@@ -2034,7 +2035,7 @@ struct elf_obj_tdata
ENUM_BITFIELD (dynamic_lib_link_class) dyn_lib_class : 4;
/* Whether the bfd uses OS specific bits that require ELFOSABI_GNU. */
- ENUM_BITFIELD (elf_gnu_osabi) has_gnu_osabi : 3;
+ ENUM_BITFIELD (elf_gnu_osabi) has_gnu_osabi : 4;
/* Whether if the bfd contains the GNU_PROPERTY_NO_COPY_ON_PROTECTED
property. */
diff --git a/bfd/elf.c b/bfd/elf.c
index 9d7cbd52e0..8ec21d7705 100644
--- a/bfd/elf.c
+++ b/bfd/elf.c
@@ -1066,9 +1066,12 @@ _bfd_elf_make_section_from_shdr (bfd *abfd,
/* FIXME: We should not recognize SHF_GNU_MBIND for ELFOSABI_NONE,
but binutils as of 2019-07-23 did not set the EI_OSABI header
byte. */
-case ELFOSABI_NONE:
case ELFOSABI_GNU:
case ELFOSABI_FREEBSD:
+ if ((hdr->sh_flags & SHF_GNU_RETAIN) != 0)
+ elf_tdata (abfd)->has_gnu_osabi |= elf_gnu_osabi_retain;
+ /* Fall through */
+case ELFOSABI_NONE:
if ((hdr->sh_flags & SHF_GNU_MBIND) != 0)
elf_tdata (abfd)->has_gnu_osabi |= elf_gnu_osabi_mbind;
break;
@@ -12454,8 +12457,8 @@ _bfd_elf_final_write_processing (bfd *abfd)
i_ehdrp->e_ident[EI_OSABI] = get_elf_backend_data (abfd)->elf_osabi;
/* Set the osabi field to ELFOSABI_GNU if the binary contains
- SHF_GNU_MBIND sections or symbols of STT_GNU_IFUNC type or
- STB_GNU_UNIQUE binding. */
+ SHF_GNU_MBIND or SHF_GNU_RETAIN sections or symbols of STT_GNU_IFUNC type
+ or STB_GNU_UNIQUE binding. */
if (elf_tdata (abfd)->has_gnu_osabi != 0)
{
if (i_ehdrp->e_ident[EI_OSABI] == ELFOSABI_NONE)
@@ -12464,11 +12467,17 @@ _bfd_elf_final_write_processing (bfd *abfd)
&& i_ehdrp->e_ident[EI_OSABI] != ELFOSABI_FREEBSD)
{
if (elf_tdata (abfd)->has_gnu_osabi & elf_gnu_osabi_mbind)
- _bfd_error_handler (_("GNU_M
[PATCH 2/2] 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 bootstrapped/regtested x86_64-pc-linux-gnu and regtested
for arm-none-eabi.
Ok for trunk?
>From ccd84e8c8b1ce5e2b496d5a550b24dbdae617327 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Mon, 26 Oct 2020 17:00:31 +
Subject: [PATCH 2/2] 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:
* cgraph.h (symtab_node): Adjust comment for noinit flag.
* doc/extend.texi: Document the "persistent" variable attribute.
* tree.h (DECL_NOINIT_P): Adjust comment.
* varasm.c (bss_initializer_p): Return false for a DECL_NOINIT_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 | 150 --
gcc/cgraph.h | 4 +-
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| 5 +-
gcc/varasm.c | 19 ++-
16 files changed, 304 insertions(+), 77 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 6f8288326ee..d96bd3d87c9 100644
--- a/gcc/c-family/c-attribs.c
+++ b/gcc/c-family/c-attribs.c
@@ -92,10 +92,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 h
[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 section.
With -fdata-sections they are ignored because they are not handled in
resolve_unique_section.
Successfully bootstrapped/regtested x86_64-pc-linux-gnu and regtested
for arm-none-eabi.
Ok for trunk?
>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 section.
With -fdata-sections they are ignored because they are not handled in
resolve_unique_section.
gcc/c-family/ChangeLog:
* c-attribs.c (handle_noinit_attribute): Set DECL_NOINIT_P.
gcc/ChangeLog:
* cgraph.h (symtab_node): Add noinit flag.
* cgraphunit.c (process_function_and_variable_attributes): Set
noinit flag of varpool node for DECL_NOINIT_P decls.
* lto-cgraph.c (lto_output_varpool_node): Pack noinit flag
value.
(input_varpool_node): Unpack noinit flag value.
* tree-core.h (struct tree_decl_common): Add noinit_flag.
* tree.h (DECL_NOINIT_P): Define DECL_NOINIT_P.
* varasm.c (get_variable_section): Set DECL_NOINIT_P from
varpool node noinit flag.
(default_elf_select_section): Check 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/c-family/c-attribs.c | 4
gcc/cgraph.h | 6 +-
gcc/cgraphunit.c | 2 ++
gcc/lto-cgraph.c | 2 ++
.../gcc.c-torture/execute/noinit-attribute.c | 2 +-
gcc/testsuite/lib/target-supports.exp | 2 +-
gcc/tree-core.h | 1 +
gcc/tree.h| 6 ++
gcc/varasm.c | 11 ---
9 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
index 8283e959c89..6f8288326ee 100644
--- a/gcc/c-family/c-attribs.c
+++ b/gcc/c-family/c-attribs.c
@@ -2394,6 +2394,10 @@ handle_noinit_attribute (tree * node,
valid. */
if (DECL_COMMON (*node))
DECL_COMMON (*node) = 0;
+
+ /* Set DECL_NOINIT_P to indicate the decaration should not be
+initialized by the startup code. */
+ DECL_NOINIT_P (*node) = 1;
}
}
diff --git a/gcc/cgraph.h b/gcc/cgraph.h
index 96d6cf609fe..4176f761482 100644
--- a/gcc/cgraph.h
+++ b/gcc/cgraph.h
@@ -120,7 +120,7 @@ public:
used_from_other_partition (false), in_other_partition (false),
address_taken (false), in_init_priority_hash (false),
need_lto_streaming (false), offloadable (false), ifunc_resolver (false),
- order (false), next_sharing_asm_name (NULL),
+ noinit (false), order (false), next_sharing_asm_name (NULL),
previous_sharing_asm_name (NULL), same_comdat_group (NULL), ref_list (),
alias_target (NULL), lto_file_data (NULL), aux (NULL),
x_comdat_group (NULL_TREE), x_section (NULL)
@@ -577,6 +577,10 @@ public:
/* Set when symbol is an IFUNC resolver. */
unsigned ifunc_resolver : 1;
+ /* Set when the symbol is decorated with the "noinit" attribute,
+ which indicates it should not be initialized by the runtime
+ startup code. */
+ unsigned noinit : 1;
/* Ordering of all symtab entries. */
int order;
diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c
index 19ae8763373..9437e7b719e 100644
--- a/gcc/cgraphunit.c
+++ b/gcc/cgraphunit.c
@@ -915,6 +915,8 @@ process_function_and_variable_attributes (cgraph_node
*first,
if (DECL_EXTERNAL (decl)
&& DECL_INITIAL (decl))
varpool_node::finalize_decl (decl);
+ if (DECL_NOINIT_P (decl))
+ vnode->noinit = true;
if (DECL_PRESERVE_P (decl))
vnode->force_output = true;
else if (lookup_attribute ("externally_visible", DECL_ATTRIBUTES (decl)))
diff --git a/gcc/lto-cgraph.c b/gcc/lto-cgraph.c
index 93a99f3465b..8d6ba74dcad 100644
--- a/gcc/lto-cgraph.c
+++ b/gcc/lto-cgraph.c
@@ -631,6 +631,7 @@ lto_output_varpool_node (struct lto_simple_output_block
*ob, varpool_node *node,
bp_pack_value (, node->tls_model, 3);
bp_pac
[PATCH 0/2] arm: "noinit" and "persistent" attributes
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 section.
With -fdata-sections they are ignored because they are not handled in
resolve_unique_section.
gcc/c-family/ChangeLog:
* c-attribs.c (handle_noinit_attribute): Set DECL_NOINIT_P.
gcc/ChangeLog:
* cgraph.h (symtab_node): Add noinit flag.
* cgraphunit.c (process_function_and_variable_attributes): Set
noinit flag of varpool node for DECL_NOINIT_P decls.
* lto-cgraph.c (lto_output_varpool_node): Pack noinit flag
value.
(input_varpool_node): Unpack noinit flag value.
* tree-core.h (struct tree
Re: [RFC] Add support for the "retain" attribute utilizing SHF_GNU_RETAIN
On Mon, Oct 26, 2020 at 07:08:06PM +, Pedro Alves via Gcc-patches wrote:
> On 10/6/20 12:10 PM, Jozef Lawrynowicz wrote:
>
> > Should "used" apply SHF_GNU_RETAIN?
> > ===
> > Another talking point is whether the existing "used" attribute should
> > apply the SHF_GNU_RETAIN flag to the containing section.
> >
> > It seems unlikely that a user applies the "used" attribute to a
> > declaration, and means for it to be saved from only compiler
> > optimization, but *not* linker optimization. So perhaps it would be
> > beneficial for "used" to apply SHF_GNU_RETAIN in some way.
> >
> > If "used" did apply SHF_GNU_RETAIN, we would also have to
> > consider the above options for how to apply SHF_GNU_RETAIN to the
> > section. Since the "used" attribute has been around for a while
> > it might not be appropriate for its behavior to be changed to place the
> > associated declaration in its own, unique section, as in option (2).
> >
>
> To me, if I use attribute((used)), and the linker still garbage
> collects the symbol, then the toolchain has a bug. Is there any
> use case that would suggest otherwise?
>
> Thanks,
> Pedro Alves
>
I agree that "used" should imply SHF_GNU_RETAIN on whatever section
contains the declaration that the attribute is applied to. However, I
think that apart from the section flag being applied to the section, the
behaviour of "used" shouldn't be modified i.e. the declaration shouldn't
be put in a unique section.
I originally justified the addition of a "retain" attribute, alongside
"used" implying SHF_GNU_RETAIN, as indicating that the declaration
should be placed in it's own section. In hindsight, this is unnecessary;
if the user wants to increase the granularity of the portions of their
program being retained, they should build with
-f{function,data}-sections, or manually put the declaration in its own
section with the "section" attribute.
So we could shelve the "retain" attribute, and just modify the "used"
attribute to imply SHF_GNU_RETAIN. If we get consensus on that, I could
go ahead an implement it, but I never got any specific feedback on the
GCC behavior from anyone apart from you. I don't know whether to
interpret that lack of feedback, whilst the other aspects of the
implementation were commented on, as support for the "retain" attribute.
(I appreciate you giving that feedback in the Binutils discussions, and
should have engaged in those discussions more at the time. There was
just a lot of opinions flying about on many aspects of it, which is
attention for this proposal I now miss...)
Since I'm not proposing to modify the behavior of "used" apart from
applying SHF_GNU_RETAIN to its section, I'm hoping the GCC side of
things won't be too controversial.
However, the assembler will have to support mis-matched section
declarations, i.e.:
.section .text,"ax",%progbits
...
.section .text,"axR",%progbits
...
The Binutils patch that supported this would create two separate .text
sections in the assembled object file, one with SHF_GNU_RETAIN and one
without.
Perhaps they should be merged into a single .text section, with
SHF_GNU_RETAIN applied to that merged section, so as to truly not
interfere with "used" attribute behavior.
There was an opinion that allowing these separate .section directives
with the same name but different flags was undesirable.
Personally, I don't see it as a problem, this exception is beneficial
and makes sense, if the assembler merges the sections it is as if they
all had the flag applied anyway.
On Mon, Oct 26, 2020 at 07:12:45PM +, Pedro Alves via Gcc-patches wrote:
> On 10/6/20 12:10 PM, Jozef Lawrynowicz wrote:
> > The changes would also only affect targets
> > that support the GNU ELF OSABI, which would lead to inconsistent
> > behavior between non-GNU OS's.
>
> Well, a separate __attribute__((retain)) will necessarily only work
> on GNU ELF targets, so that just shifts the "inconsistent" behavior
> elsewhere.
True, a note in the documentation would cover this. For example:
"As a GNU ELF extension, the used attribute will also prevent the
linker from garbage collecting the section containing the symbol"
Thanks,
Jozef
Re: [PATCH] cp/decl.c: Set DECL_INITIAL before attribute processing
On Mon, Oct 26, 2020 at 01:30:29PM +, Jozef Lawrynowicz wrote:
> 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 bootstrapped and regtested for x86_64-pc-linux-gnu, and
> regtested for arm-eabi and msp430-elf.
>
> Ok for trunk?
Amended slightly misleading comment, shown below, in the attached patch.
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 0f32dd88bad..4c959377077 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -5235,8 +5235,8 @@ start_decl (const cp_declarator *declarator,
return error_mark_node;
}
- /* Save the DECL_INITIAL value since we clobber it with error_mark_node if
- INITIALIZED is true. */
+ /* Save the DECL_INITIAL value in case it gets clobbered to assist
+ with attribute validation. */
initial = DECL_INITIAL (decl);
if (initialized)
>From fad6cc4df13e00c55d381e82772438161282a008 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Tue, 20 Oct 2020 14:03:42 +0100
Subject: [PATCH] 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 5f370e60b4e..4c959377077 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -5210,6 +5210,7 @@ start_decl (const cp_declarator *declarator,
bool was_public;
int flags;
bool alias;
+ tree initial;
*pushed_scope_p = NULL_TREE;
@@ -5234,6 +5235,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 ()
@@ -5243,6 +5248,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;
@@ -5261,6 +5270,10 @@ start_decl (const cp_declarator *declarator,
/* Set attributes here so if duplicate decl, will have proper attributes. */
cplus_decl_attributes (, 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 --gi
[PATCH] 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 bootstrapped and regtested for x86_64-pc-linux-gnu, and
regtested for arm-eabi and msp430-elf.
Ok for trunk?
>From 6fbb18ab081069fb2730360f9e09425b9b1f6a7d Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Tue, 20 Oct 2020 14:03:42 +0100
Subject: [PATCH] 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 5f370e60b4e..0f32dd88bad 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -5210,6 +5210,7 @@ start_decl (const cp_declarator *declarator,
bool was_public;
int flags;
bool alias;
+ tree initial;
*pushed_scope_p = NULL_TREE;
@@ -5234,6 +5235,10 @@ start_decl (const cp_declarator *declarator,
return error_mark_node;
}
+ /* Save the DECL_INITIAL value since we clobber it with error_mark_node if
+ INITIALIZED is true. */
+ initial = DECL_INITIAL (decl);
+
if (initialized)
{
if (! toplevel_bindings_p ()
@@ -5243,6 +5248,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;
@@ -5261,6 +5270,10 @@ start_decl (const cp_declarator *declarator,
/* Set attributes here so if duplicate decl, will have proper attributes. */
cplus_decl_attributes (, 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 =
[PATCH] Implement the "retain" attribute
Hi, The attached patch adds support for the new "retain" attribute, which can be applied to function and variable declarations, to protect them from linker garbage collection. Declarations with this attribute will be placed in a new, unique section, and the ".section" assembler directive that gets output for that new section will have the "R" flag applied. The "R" flag indicates to GAS that the SHF_GNU_RETAIN flag should be applied to the section. SHF_GNU_RETAIN is a GNU OSABI ELF extension. SHF_GNU_RETAIN was discussed on the GNU gABI mailing list here: https://sourceware.org/pipermail/gnu-gabi/2020q3/000429.html The Binutils patch for SHF_GNU_RETAIN was discussed in the following threads: https://sourceware.org/pipermail/binutils/2020-September/113406.html https://sourceware.org/pipermail/binutils/2020-September/113499.html The latest Binutils patch is posted here: https://sourceware.org/pipermail/binutils/2020-October/113769.html It is awaiting final approval, but in the meantime I'm posting the GCC part of the implementation for review. Successfully bootstrapped and regtested for x86_64-pc-linux-gnu, and regtested for arm-none-eabi. Ok for trunk? Thanks, Jozef >From 82c4f86cde2155dd8b89ba01a2da88761586787b Mon Sep 17 00:00:00 2001 From: Jozef Lawrynowicz Date: Thu, 22 Oct 2020 14:23:40 +0100 Subject: [PATCH] Implement the "retain" attribute The "retain" attribute is used to protect the function or variable declaration it is applied to from linker garbage collection. Declarations with this attribute will be placed in a new, unique section, and the ".section" assembler directive that gets output for that new section will have the "R" flag applied. The "R" flag indicates to GAS that the SHF_GNU_RETAIN flag should be applied to the section. SHF_GNU_RETAIN is a GNU OSABI ELF extension. gcc/c-family/ChangeLog: * c-attribs.c (handle_retain_attribute): New. gcc/ChangeLog: * config.in: Regenerate. * configure: Regenerate. * configure.ac: Define HAVE_GAS_SECTION_RETAIN if the assembler .section directive supports the "R" flag. * doc/extend.texi: Document the "retain" function and variable attribute. * doc/sourcebuild.texi: Document the "retain" DejaGNU effective target keyword. * output.h (SECTION_RETAIN): Define. (SECTION_MACH_DEP): Adjust value. * tree-core.h (struct tree_decl_common): Add "retain_flag" member. * tree.h (DECL_RETAIN_P): New. * varasm.c (resolve_unique_section): Create unique section for DECL_RETAIN_P decls. (default_section_type_flags): Set the SECTION_RETAIN flag for sections created for DECL_RETAIN_P decls. (default_elf_asm_named_section): Emit "R" flag in .section directive for SECTION_RETAIN sections. gcc/testsuite/ChangeLog: * lib/target-supports.exp (check_effective_target_retain): New. * c-c++-common/attr-retain-1.c: New test. * c-c++-common/attr-retain-2.c: New test. * c-c++-common/attr-retain-3.c: New test. * c-c++-common/attr-retain-main.inc: New test. --- gcc/c-family/c-attribs.c | 42 +++ gcc/config.in | 6 +++ gcc/configure | 36 gcc/configure.ac | 9 gcc/doc/extend.texi | 23 ++ gcc/doc/sourcebuild.texi | 3 ++ gcc/output.h | 3 +- gcc/testsuite/c-c++-common/attr-retain-1.c| 19 + gcc/testsuite/c-c++-common/attr-retain-2.c| 21 ++ gcc/testsuite/c-c++-common/attr-retain-3.c| 10 + .../c-c++-common/attr-retain-main.inc | 26 gcc/testsuite/lib/target-supports.exp | 9 gcc/tree-core.h | 1 + gcc/tree.h| 7 gcc/varasm.c | 8 +++- 15 files changed, 221 insertions(+), 2 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-main.inc diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c index a3b2b3d58bd..72c0c61993e 100644 --- a/gcc/c-family/c-attribs.c +++ b/gcc/c-family/c-attribs.c @@ -155,6 +155,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 hand
[committed] MSP430: Support a memory operand for op1 of andneghi3
The attached patch fixes an ICE caused by an unrecognizeable insn
generated when compiling gcc.c-torture/execute/pr97386-1.c at -O0 for
msp430-elf.
Successfully regtested on trunk and committed as obvious.
>From 8c3846e80210ba437644b5b91d9bd9c564ca565a Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Tue, 20 Oct 2020 11:26:20 +0100
Subject: [PATCH] MSP430: Support a memory operand for op1 of andneghi3
This fixes an ICE caused by an unrecognizeable insn generated when
compiling gcc.c-torture/execute/pr97386-1.c at -O0.
gcc/ChangeLog:
* config/msp430/msp430.md (andneghi3): Allow general operand for
op1 and update output assembler template.
---
gcc/config/msp430/msp430.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/config/msp430/msp430.md b/gcc/config/msp430/msp430.md
index f70e61b97dd..ad244bb0f33 100644
--- a/gcc/config/msp430/msp430.md
+++ b/gcc/config/msp430/msp430.md
@@ -1346,12 +1346,12 @@ (define_insn "bis_SR"
;; instructions, so we provide a pattern to support it here.
(define_insn "andneghi3"
[(set (match_operand:HI 0 "register_operand" "=r")
- (and:HI (neg:HI (match_operand:HI 1 "register_operand" "r"))
+ (and:HI (neg:HI (match_operand:HI 1 "general_operand" "rm"))
(match_operand2 "immediate_operand" "n")))]
""
"*
if (REGNO (operands[0]) != REGNO (operands[1]))
- return \"MOV.W\t%1, %0 { INV.W\t%0 { INC.W\t%0 { AND.W\t%2, %0\";
+ return \"MOV%X1.W\t%1, %0 { INV.W\t%0 { INC.W\t%0 { AND.W\t%2, %0\";
else
return \"INV.W\t%0 { INC.W\t%0 { AND.W\t%2, %0\";
"
--
2.28.0
ping x3 [PATCH 0/5] MSP430: Implement macros to describe relative costs of operations
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 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
[RFC] Add support for the "retain" attribute utilizing SHF_GNU_RETAIN
t;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 (VAR_P (node))
+ DECL_READ_P (node) = 1;
+}
+ el
[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 (op));
/* Print the constant value, less four. */
- fprintf (file, "#%ld", INTVAL (op) - 4);
+ fprintf (file, "#%ld", (long) (INTVAL (op) - 4));
[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
[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
[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_
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: 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
[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: 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
[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
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
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
+ autoincrement (@Rn+) addres
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: > > * gcc.target/ms
[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
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-f5series.c
diff --git a/gc
[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
[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 \, \\+1
+** MOV.* #arr\+2, \
+** ...
+*/
+
+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 as expected for the default I
[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 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 ? _cost_double_op : _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, "msp430_costs unhan
[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 ()
+ 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 ? _cost_double_op_mov : _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_p->r2m;
+
+ /* All register to r
[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
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, _mode))
> > + && is_a (mode, _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 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 +- gcc/config/msp430/msp430.opt
[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 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, _mode))
+ && is_a (mode, _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 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
[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
[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: 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
Re: [PATCH] TESTSUITE: Fix tests for 16-bit targets
On Wed, May 20, 2020 at 03:37:30PM +0200, Christophe Lyon via Gcc-patches wrote: > Hi, > > > > On Mon, 18 May 2020 at 14:42, Jozef Lawrynowicz > wrote: > > > > On Fri, May 15, 2020 at 10:48:56PM +, Joseph Myers wrote: > > > On Fri, 15 May 2020, Jozef Lawrynowicz wrote: > > > > > > > The attached patch fixes many GCC and G++ tests for 16-bit targets. > > > > These > > > > targets can have the following properties: > > > > - "int", "size_t", "ptrdiff_t", "void *" are 16-bit types > > > > - sizeof(int) == sizeof(short) > > > > > > Some of the tests are disabled by the patch for the case where pointers > > > are the same size as int. Were those tests all previously failing for > > > 32-bit targets where that's the case? If not, ptr_eq_int seems an > > > inappropriate condition for disabling them. > > > > Ah yes, regarding g++.dg/init/new44.C, it seems that i386-pc-linux-gnu > > does require an array size cookie even though ptr_eq_int (in fact, > > since the decision relates to size_t, a pointer size effective target > > shouldn't > > have been used anyway). I'll amend the condition so it is skipped for msp430 > > only. > > > > The other test using ptr_eq_int (g++.dg/init/const7.C) is also passing > > on i386-pc-linux-gnu, so I'll amend that as well. > > > > I'll make sure to do a full regtest on i386-pc-linux-gnu before > > applying. > > > > I've noticed regressions on aarch64 with -mabi=ilp32: > g++.dg/warn/Wconversion-null-2.C -std=gnu++14 (test for warnings, line > 37) > g++.dg/warn/Wconversion-null-2.C -std=gnu++14 (test for warnings, line > 60) > g++.dg/warn/Wconversion-null-2.C -std=gnu++17 (test for warnings, line > 37) > g++.dg/warn/Wconversion-null-2.C -std=gnu++17 (test for warnings, line > 60) > g++.dg/warn/Wconversion-null-2.C -std=gnu++2a (test for warnings, line > 37) > g++.dg/warn/Wconversion-null-2.C -std=gnu++2a (test for warnings, line > 60) > g++.dg/warn/Wconversion-null-2.C -std=gnu++98 (test for warnings, line > 37) > g++.dg/warn/Wconversion-null-2.C -std=gnu++98 (test for warnings, line > 60) > > The logs say: > /gcc/testsuite/g++.dg/warn/Wconversion-null-2.C:37:9: error: call of > overloaded 'g(NULL)' is ambiguous > /gcc/testsuite/g++.dg/warn/Wconversion-null-2.C:60:11: error: call of > overloaded 'g(NULL)' is ambiguous > > Can you check/fix? Hmm, it seems that when performing overload resolution, the compiler considers g(long) and g(void*) equally viable candidates for g(NULL) and so the ambiguous error occurs. Even though sizeof(int) == sizeof(long) == sizeof(void*), the g(int) candidate is more viable than the others for g(NULL) so is required to break the tie between g(long) and g(void*). The problem for msp430/-mlarge is that the bitsize of a pointer is 20-bits and that doesn't match any of the g() declarations using integral types for arguments. So the reason I originally changed the test is because all of the g() declarations are considered equally viable and so the g(NULL) call was reported as ambiguous. I've committed the attached patch which reverts the changes to the Wconversion-null* tests and adds a special case for __MSP430X_LARGE__. Jozef > > Thanks > > Christophe > > > Thanks, > > Jozef > > > > > > > > -- > > > Joseph S. Myers > > > jos...@codesourcery.com >From edd482f310f4ec46310e7c2c82c88dad64b5a4ff Mon Sep 17 00:00:00 2001 From: Jozef Lawrynowicz Date: Wed, 20 May 2020 22:15:18 +0100 Subject: [PATCH] TESTSUITE: Fix Wconversion-null*.C tests for aarch64 -mabi=ilp32 This fixes regressions for aarch64 with -mabi=ilp32 of the Wconversion-null*.C tests, introduced by 92ea8e1bccc. The "g (int)" declaration is required for that target where sizeof(int) == sizeof(long) == sizeof(void *). To handle the msp430/-mlarge case, an explicit declaration of "g (__int20)" is required. gcc/testsuite/ChangeLog: * g++.dg/warn/Wconversion-null-2.C: Add explicit declarations for l() and g() with int, long, long long and __int20 arguments. * g++.dg/warn/Wconversion-null.C: Likewise. --- .../g++.dg/warn/Wconversion-null-2.C | 20 +-- gcc/testsuite/g++.dg/warn/Wconversion-null.C | 20 +-- 2 files changed, 36 insertions(+), 4 deletions(-) diff --git a/gcc/testsuite/g++.dg/warn/Wconversion-null-2.C b/gcc/testsuite/g++.dg/warn/Wconversion-null-2.C index 0f5bf58bd5d..3ba756e596b 100644 --- a/gcc/testsuite/g++.dg/warn/Wconversion-null-2.C +++ b/gcc/testsuite/g++.dg/warn/Wconversion-null-2.C @@ -3,7 +3,12 @@
Re: [PATCH] TESTSUITE: Fix tests for 16-bit targets
On Fri, May 15, 2020 at 10:48:56PM +, Joseph Myers wrote: > On Fri, 15 May 2020, Jozef Lawrynowicz wrote: > > > The attached patch fixes many GCC and G++ tests for 16-bit targets. These > > targets can have the following properties: > > - "int", "size_t", "ptrdiff_t", "void *" are 16-bit types > > - sizeof(int) == sizeof(short) > > Some of the tests are disabled by the patch for the case where pointers > are the same size as int. Were those tests all previously failing for > 32-bit targets where that's the case? If not, ptr_eq_int seems an > inappropriate condition for disabling them. Ah yes, regarding g++.dg/init/new44.C, it seems that i386-pc-linux-gnu does require an array size cookie even though ptr_eq_int (in fact, since the decision relates to size_t, a pointer size effective target shouldn't have been used anyway). I'll amend the condition so it is skipped for msp430 only. The other test using ptr_eq_int (g++.dg/init/const7.C) is also passing on i386-pc-linux-gnu, so I'll amend that as well. I'll make sure to do a full regtest on i386-pc-linux-gnu before applying. Thanks, Jozef > > -- > Joseph S. Myers > jos...@codesourcery.com
[PATCH] TESTSUITE: Fix tests for 16-bit targets
The attached patch fixes many GCC and G++ tests for 16-bit targets. These
targets can have the following properties:
- "int", "size_t", "ptrdiff_t", "void *" are 16-bit types
- sizeof(int) == sizeof(short)
These properties cause problems for a number of tests in the testsuite,
where int is often assumed to be a 32-bit type (and the test relies on that
property to run as expected or to not generate any unexpected warnings).
Other failures occur when arrays larger than what is supported for 16-bit
targets are declared, or the "short" type is expected to be smaller than "int".
The fixes fall into a few different categories:
- Explicitly defining a 32-bit int type and using that in place of "int" or
"unsigned int".
- Skipping tests which rely on arrays sized larger than what is supported by the
target.
- Adding or adjusting dg-{warning,error} directives
- Other testcase specific adjustments.
I've successfully regtested the patch on x86_64-pc-linux-gnu and msp430-elf in
the default, -mlarge and -mcpu=msp430 configurations.
There are no absolute changes to testresults on x86_64-pc-linux-gnu, but because
of changes to the line number of dg-{warning,message,error,etc} directives, the
results comparison shows:
UNTESTED->FAIL: 8 tests
UNTESTED->PASS: 986 tests
PASS->UNTESTED: 986 tests
FAIL->UNTESTED: 8 tests
Across the 3 configurations for msp430, the total is:
PASS->FAIL: 0 tests
FAIL->PASS: 1108 tests
UNTESTED->FAIL: 24 tests
UNTESTED->PASS: 2924 tests
FAIL->UNTESTED: 807 tests
PASS->UNTESTED: 2564 tests
Ok for trunk?
What about for gcc-10 branch? It would be nice to clean up the testresults for
MSP430, but I understand if it is undesirable to cause these line number changes
to appear on the stable branch.
Jozef
>From 7696941c75cf7d0cfbfb25dfd9c239e28314f570 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Tue, 12 May 2020 14:27:41 +0100
Subject: [PATCH] TESTSUITE: Fix tests for 16-bit targets
gcc/ChangeLog:
2020-05-15 Jozef Lawrynowicz
* doc/sourcebuild.texi: Document new short_eq_int, ptr_eq_short,
ptr_eq_int, msp430_large_memory_model and size24plus DejaGNU effective
targets.
Improve grammar in descriptions for size20plus and size32plus effective
targets.
gcc/testsuite/ChangeLog:
2020-05-15 Jozef Lawrynowicz
* c-c++-common/builtin-has-attribute-7.c: Require size24plus.
* c-c++-common/cpp/pr63831-1.c: Store result in _has_cpp_attribute in a
long.
* c-c++-common/pr81376.c: Skip scan-tree-dump for short_eq_int. Extend
test for short_eq_int.
* g++.dg/abi/scoped1.C: Skip dg-warning tests for short_eq_int.
* g++.dg/cpp0x/constexpr-70001-1.C: Require size24plus.
* g++.dg/cpp0x/constexpr-bitfield3.C: Require int32plus.
* g++.dg/cpp0x/enum13.C: Skip dg-warning for short_eq_int.
* g++.dg/cpp0x/initlist5.C: Add dg-error for short_eq_int.
* g++.dg/cpp0x/initlist7.C: Add dg-warning for !int32plus.
* g++.dg/cpp0x/nullptr04.C: Skip dg-error for ptr_eq_short.
* g++.dg/cpp0x/variadic-value1.C: Add typedef for int32_t.
* g++.dg/cpp1y/constexpr-arith-overflow.C: Fix test for
sizeof(int) == sizeof(short).
* g++.dg/cpp1y/digit-sep-neg.C: Add typedef for int32_t.
* g++.dg/cpp1y/pr57644.C: Add typedef for uint32_t.
* g++.dg/cpp1y/pr77321.C: Require size24plus.
* g++.dg/cpp1y/var-templ4.C: Add typedef for int32_t.
* g++.dg/cpp1z/direct-enum-init1.C: Skip dg-error for short_eq_int.
* g++.dg/delayedfold/fwrapv1.C: Skip for int16.
* g++.dg/expr/bitfield9.C: Add typedef for int32_t.
* g++.dg/ext/attribute-test-1.C: Add typedef for uint32_t.
* g++.dg/ext/bitfield1.C: Add typedef for int32_t.
* g++.dg/ext/flexary13.C: Add typedef for int32_t.
* g++.dg/ext/utf-cvt.C: Adjust dg-warning for int16.
* g++.dg/ext/vector28.C: Add typedef for int32_t.
* g++.dg/ext/vla15.C: Add typedef for int32_t.
* g++.dg/init/array11.C: Require size32plus.
* g++.dg/init/array15.C: Require size24plus.
* g++.dg/init/array4.C: Require size20plus.
* g++.dg/init/const7.C: Skip dg-message for ptr_eq_int.
* g++.dg/init/new38.C: Relax regex in dg-error.
* g++.dg/init/new44.C: Skip dg-error for when ptr_eq_int.
Adjust test for 16-bit size_t.
Add special case for msp430 -mlarge.
* g++.dg/init/value9.C: Add typedef for int32_t.
* g++.dg/ipa/pr77333.C: Add typedef for int32_t.
* g++.dg/lto/20080908-1_0.C: Add typedef for int32_t.
* g++.dg/opt/pr55717.C: Add typedef for uint32_t.
* g++.dg/opt/pr60597.C: Add typedef for int32_t.
* g++.dg/opt/pr81715.C: Require size20plus.
* g++.dg/opt/reload3.C: Add typedef for uint32_t.
* g++.dg/opt/te
[committed] MSP430: Define ASM_OUTPUT_ALIGNED_DECL_LOCAL
The attached patch implements ASM_OUTPUT_ALIGNED_DECL_LOCAL for msp430. The
default handler needs to be overridden so local common symbols which need
their own section (e.g. variables with the "noinit" attribute) will be placed
in that section rather than the common block.
This fixes "gcc.c-torture/execute/noinit-attribute.c -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects execution test", which was failing
because the global noinit variable would get optimized into a local common
variable by LTO and placed in the common block, which always get initialized to
0.
The attached patch also skips the noinit-attribute test for msp430 when -mlarge
is being tested. The simulator linker script for -mlarge simulates the copying
of data from ROM to RAM at startup, so a variable in the test which is supposed
to check if this is the first or second time round the test, is always reset to
its initial value, causing the test to loop forever and eventually timeout.
Successfully regtested for msp430-elf in the default, -mcpu=msp430 and -mlarge
configurations.
Committed as obvious.
>From e8fb1a3892f4e2f8268ac2649776a7bd0a967643 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Fri, 8 May 2020 14:45:20 +0100
Subject: [PATCH] MSP430: Define ASM_OUTPUT_ALIGNED_DECL_LOCAL
gcc/ChangeLog:
2020-05-12 Jozef Lawrynowicz
* config/msp430/msp430-protos.h (msp430_output_aligned_decl_common):
Update prototype to include "local" argument.
* config/msp430/msp430.c (msp430_output_aligned_decl_common): Add
"local" argument. Handle local common decls.
* config/msp430/msp430.h (ASM_OUTPUT_ALIGNED_DECL_COMMON): Adjust
msp430_output_aligned_decl_common call with 0 for "local" argument.
(ASM_OUTPUT_ALIGNED_DECL_LOCAL): Define.
gcc/testsuite/ChangeLog:
2020-05-12 Jozef Lawrynowicz
* gcc.c-torture/execute/noinit-attribute.c: Skip for msp430
in the large memory model.
---
gcc/ChangeLog | 10 ++
gcc/config/msp430/msp430-protos.h | 3 ++-
gcc/config/msp430/msp430.c| 19 +++
gcc/config/msp430/msp430.h| 8 +++-
gcc/testsuite/ChangeLog | 5 +
.../gcc.c-torture/execute/noinit-attribute.c | 6 +-
6 files changed, 44 insertions(+), 7 deletions(-)
diff --git gcc/ChangeLog gcc/ChangeLog
index b0a9212688a..e2b01aaae27 100644
--- gcc/ChangeLog
+++ gcc/ChangeLog
@@ -1,3 +1,13 @@
+2020-05-12 Jozef Lawrynowicz
+
+ * config/msp430/msp430-protos.h (msp430_output_aligned_decl_common):
+ Update prototype to include "local" argument.
+ * config/msp430/msp430.c (msp430_output_aligned_decl_common): Add
+ "local" argument. Handle local common decls.
+ * config/msp430/msp430.h (ASM_OUTPUT_ALIGNED_DECL_COMMON): Adjust
+ msp430_output_aligned_decl_common call with 0 for "local" argument.
+ (ASM_OUTPUT_ALIGNED_DECL_LOCAL): Define.
+
2020-05-12 Richard Biener
* cfghooks.c (split_edge): Preserve EDGE_DFS_BACK if set.
diff --git gcc/config/msp430/msp430-protos.h gcc/config/msp430/msp430-protos.h
index 657af4c7075..29ce9babc4a 100644
--- gcc/config/msp430/msp430-protos.h
+++ gcc/config/msp430/msp430-protos.h
@@ -39,7 +39,8 @@ boolmsp430_is_interrupt_func (void);
const char * msp430x_logical_shift_right (rtx);
const char * msp430_mcu_name (void);
voidmsp430_output_aligned_decl_common (FILE *, const tree, const char *,
- unsigned HOST_WIDE_INT, unsigned);
+ unsigned HOST_WIDE_INT, unsigned,
+ int);
void msp430_output_labelref (FILE *, const char *);
void msp430_register_pragmas (void);
rtx msp430_return_addr_rtx (int);
diff --git gcc/config/msp430/msp430.c gcc/config/msp430/msp430.c
index e77ca101599..6bb1714f465 100644
--- gcc/config/msp430/msp430.c
+++ gcc/config/msp430/msp430.c
@@ -2019,13 +2019,15 @@ msp430_unique_section (tree decl, int reloc)
/* Emit a declaration of a common symbol.
If a data region is in use then put the symbol into the
- equivalent .bss section instead. */
+ equivalent .bss section instead.
+ If LOCAL is 1, then DECL is for a local common variable. */
void
msp430_output_aligned_decl_common (FILE * stream,
const tree decl,
const char * name,
unsigned HOST_WIDE_INT size,
- unsigned int align)
+ unsigned int align,
+ int local)
{
/* Only emit a common symbol if the variable does not have a specific section
assigned. */
@@ -2039,6 +2041,12 @@ msp430_output_aligned_decl_common (FILE * stream,
&& !has_attr (ATTR_PERSIST, decl)
&& !has_attr (ATTR_NOINIT, decl))
{
+ if (local)
+ {
+ fprintf (stream, LOCAL_ASM_OP);
+ assemble_name (stream, name);
+ fprintf (stream, "\n");
+ }
fprintf (stream, COMMON_ASM_OP);
assemble_name (stream, name);
fprintf (stream, "," HOST_WIDE_INT_PRINT_
[committed] MSP430: Allow .bss section to be created in region-attribute-misuse test
Uninitialized global variables are put in the .bss section since the -fno-common
change, the attached patch prevents region-attribute-misuse.c failing if a .bss
section is in the assembler output.
Committed as obvious.
>From 89aa37dc3c71666d0ff05e96ea84e195d049a226 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Mon, 11 May 2020 16:58:11 +0100
Subject: [PATCH] MSP430: Allow .bss section to be created in
region-attribute-misuse test
2020-05-12 Jozef Lawrynowicz
* gcc.target/msp430/region-attribute-misuse.c: Allow a .bss section to
be created.
---
gcc/testsuite/ChangeLog | 5 +
gcc/testsuite/gcc.target/msp430/region-attribute-misuse.c | 1 -
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git gcc/testsuite/ChangeLog gcc/testsuite/ChangeLog
index 05952acab92..da776417bd5 100644
--- gcc/testsuite/ChangeLog
+++ gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2020-05-12 Jozef Lawrynowicz
+
+ * gcc.target/msp430/region-attribute-misuse.c: Allow a .bss section to
+ be created.
+
2020-05-12 Martin Liska
PR sanitizer/95033
diff --git gcc/testsuite/gcc.target/msp430/region-attribute-misuse.c gcc/testsuite/gcc.target/msp430/region-attribute-misuse.c
index a108e274123..2b5107f0b8c 100644
--- gcc/testsuite/gcc.target/msp430/region-attribute-misuse.c
+++ gcc/testsuite/gcc.target/msp430/region-attribute-misuse.c
@@ -1,6 +1,5 @@
/* { dg-do compile } */
/* { dg-skip-if "" { *-*-* } { "-mcpu=msp430" "-mlarge" "-mcode-region=*" "-mdata-region=*" } { "" } } */
-/* { dg-final { scan-assembler-not ".section.*bss" } } */
/* { dg-final { scan-assembler ".section.*upper.data" } } */
/* { dg-final { scan-assembler ".section.*lower.data" } } */
/* { dg-final { scan-assembler ".section.*either.data" } } */
--
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
[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: 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
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 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 Jozef Law
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 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 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 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: [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 >
[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
[PATCH v2][MSP430] Add msp430-elfbare target
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. --- contrib/config-list.mk| 2 +- gcc/config.gcc| 14 +- gcc/config/msp430/msp430-devices.c| 16 +- gcc/config/msp430/msp430.c| 10 + gcc/config/msp430/t-msp430| 2 +- gcc/doc/install.texi | 16 +- gcc/doc/invoke.texi | 4 +- 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/gcc.target/msp430/msp430.exp| 8 +- libgcc/config.host| 20 +- .../config/msp430/msp430-elfbare-crtstuff.c | 761 ++ libgcc/config/msp430/t-msp430 | 6 - libgcc/config/msp430/t-msp430-crtstuff| 29 + .../config/msp430/t-msp430-elfbare-crtstuff | 43 + libgcc/configure | 9 + libgcc/configure.ac | 8 + 18 files changed, 933 insertions(+), 18 deletions(-) create mode 100644 libgcc/config/msp430/msp430-elfbare-crtstuff.c create mode 100644 libgcc/config/msp430/t-msp430-crtstuff create mode 100644 libgcc/config/msp430/t-msp430-elfbare-crtstuff diff --git a
[PATCH v2][MSP430] -Add fno-exceptions multilib
Original patch here: https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00619.html
Late for stage 1 I know, but it's an iteration on a patch submitted before the
transition to stage 3 and the functional changes to the compiler are constrained
to the msp430 target.
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.
Since C++ libraries are built with exceptions enabled by default, there is
nothing the end user can do about this, even when they pass -fno-exceptions on
the command line.
So this patch adds a new -fno-exceptions multilib configuration for MSP430,
to reduce the code size linked executables when using C++ with -fno-exceptions.
Since building double the multilibs does significantly increase build time,
the patch also adds a configure option --disable-no-exceptions. This disables
the fno-exceptions multilibs from being built.
The changes from the original patch linked above are:
- Wrapped new gcc-dg-prune directives checking for disabled exception handling
in an if statement, so they are only used if exception handling has been
disabled in the global test configuration.
- Extended the spec strings used to check for when crt{begin,end}_no_eh.o can be
used. When linking a C program where exceptions are implicitly disabled,
crt{begin,end}_no_eh.o can always be used unless -fexceptions is explicitly
passed.
Successfully regtested for x86_64-pc-linux-gnu. There was no change in any of
the testresults (pass/fail/unsupported).
Regtested -fno-exceptions vs the default configuration for msp430-elf. There was
some fallout from exception handling tests not working, but nothing unexpected.
Ok to apply?
>From b74f34e5ae7f649296f7f6bcce35b75c34a2b0fd Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Mon, 25 Nov 2019 12:07:24 +
Subject: [PATCH] MSP430: Add fno-exceptions multilib
ChangeLog:
2019-11-27 Jozef Lawrynowicz
* config-ml.in: Support --disable-no-exceptions configure flag.
gcc/ChangeLog:
2019-11-27 Jozef Lawrynowicz
* config/msp430/msp430.h (STARTFILE_SPEC) [!fexceptions]: Use
crtbegin_no_eh.o if building for the C language.
[fno-exceptions]: Use crtbegin_no_eh.o if building for any language
except C.
(ENDFILE_SPEC) [!fexceptions]: Use crtend_no_eh.o if building for
the C language.
[fno-exceptions]: Use crtend_no_eh.o if building for any language
except C.
* config/msp430/t-msp430: Add -fno-exceptions multilib.
* doc/install.texi: Document --disable-no-exceptions multilib configure
option.
gcc/testsuite/ChangeLog:
2019-11-27 Jozef Lawrynowicz
* lib/gcc-dg.exp: Add dg-prune messages for when exception handling is
disabled.
* lib/target-supports.exp (check_effective_target_exceptions_enabled):
New.
libgcc/ChangeLog:
2019-11-27 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/testsuite/lib/gcc-dg.exp | 12
gcc/testsuite/lib/target-supports.exp | 18 ++
libgcc/config.host| 3 ++-
libgcc/config/msp430/t-msp430 | 6 ++
8 files changed, 68 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 0ea6b0a093e..7b94918a55d 100644
--- a/gcc/config/msp430/msp430.h
+++ b/gcc/config/msp430/msp430.h
@@ -44,13 +44,20 @@ extern bool msp430x;
} \
while (0)
+/* For the "c" language where exceptions are implicitly disabled, use
+ crt*_no_eh.o unless -fexceptions is passed. For other languages, only use
+ crt*_no_eh.o if -fno-exceptions is explicitly passed. */
#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:%{,c:%{!fexceptions:crtbegin_no_eh.o%s; :crtbegin.o%s}; " \
+":%{fno-exceptions:crtbegin_no_eh.o%s; :crtbegin.o%s}}}"
/* -lgcc is included be
Re: [PATCH 2/4] MSP430: Disable exception handling by default for C++
On Tue, 12 Nov 2019 21:08:48 +
Richard Sandiford wrote:
> Jozef Lawrynowicz writes:
> > diff --git a/gcc/testsuite/lib/gcc-dg.exp b/gcc/testsuite/lib/gcc-dg.exp
> > index 1df645e283c..1ce449cb935 100644
> > --- a/gcc/testsuite/lib/gcc-dg.exp
> > +++ b/gcc/testsuite/lib/gcc-dg.exp
> > @@ -417,6 +417,16 @@ proc gcc-dg-prune { system text } {
> > return "::unsupported::large return values"
> > }
> >
> > +# If exceptions are disabled, mark tests expecting exceptions to be
> > enabled
> > +# as unsupported.
> > +if [regexp "(^|\n)\[^\n\]*: error: exception handling disabled" $text]
> > {
> > + return "::unsupported::exception handling disabled"
> > +}
>
> This is probably safe, but...
>
> > +
> > +if [regexp "(^|\n)\[^\n\]*: error: #error .__cpp_exceptions." $text] {
> > + return "::unsupported::exception handling disabled"
> > +}
>
> ...it looks like this would disable g++.dg/cpp1y/feat-neg.C for all
> targets. I assume this was motivated by g++.dg/cpp2a/feat-cxx2a.C,
> but the kind of effective-target tests you had in the original patch
> are probably better there. It might then be more robust to test that
> [check_effective_target_...] for the "exception handling disabled" case
> above as well, so that other targets aren't affected accidentally.
>
> It'd be good to test a target/multilib that has exceptions enabled by
> default to make sure there's no change in the number of unsupported
> tests (rather than just no new fails).
Apologies for the delayed response.
The messages caught in gcc-dg-prune will only be pruned if they haven't already
been caught by dg-warning/error/etc. So basically only if the regex being tested
would trigger an "excess errors" failure.
As a result, there was no change in passes/fails/unsupported on
x86_64-pc-linux-gnu.
Checking if exceptions are actually disabled before enabling those prunes is a
nice suggestion though, I'll add it to the revised patch.
Thanks,
Jozef
>
> Thanks,
> Richard
Re: [PATCH 1/4] MSP430: Disable TM clone registry by default
On Sun, 24 Nov 2019 10:10:51 -0700 Jeff Law wrote: > On 11/24/19 7:20 AM, Jozef Lawrynowicz wrote: > > On Sun, 17 Nov 2019 12:11:23 -0700 > > Jeff Law wrote: > > > >> On 11/7/19 2:34 PM, Jozef Lawrynowicz wrote: > >>> 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. > >>> > >> I'm not a huge fan of making the default configurations behave > >> differently. But I can also see how something like TM in particular > >> isn't of much interest in the embedded space (hell, it's having trouble > >> getting real traction in the server space as well). > >> > >> May be a reasonable path forward is to add the configury bits, keep TM > >> on by default and create a different msp target which disables this stuff? > >> > > > > Ok fair enough, what would an acceptable form for a new target triplet look > > like? "msp430-*-elfbare"? > Yea, that seems reasonable. > > > > > Since we're into stage 3 now I'll look at doing this for GCC 11. > I'd seriously consider letting this into gcc-10. It's going to be well > isolated and it's an iteration of something you posted before the > stage1->stage3 transition. Your choice if you want to try and pull it > together quickly for gcc-10. Ok great, I will aim to get something together ASAP. Thanks, Jozef > > Jeff >
Re: [PATCH 4/4] MSP430: Deprecate -minrt option
On Sun, 17 Nov 2019 14:00:58 -0700
Jeff Law wrote:
> On 11/7/19 2:41 PM, Jozef Lawrynowicz wrote:
> > 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
> >
> >
> > 0004-MSP430-Remove-minrt-option.patch
> >
> > 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.
> This is fine. I leave the decision whether or not to install now or
> wait for resolution on the other changes in this space as your decision.
Unfortunately without the other changes installed by default this option is
still required if users want the bare minimum code size.
Jozef
>
> jeff
>
Re: [PATCH 1/4] MSP430: Disable TM clone registry by default
On Sun, 17 Nov 2019 12:11:23 -0700 Jeff Law wrote: > On 11/7/19 2:34 PM, Jozef Lawrynowicz wrote: > > 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. > > > I'm not a huge fan of making the default configurations behave > differently. But I can also see how something like TM in particular > isn't of much interest in the embedded space (hell, it's having trouble > getting real traction in the server space as well). > > May be a reasonable path forward is to add the configury bits, keep TM > on by default and create a different msp target which disables this stuff? Ok fair enough, what would an acceptable form for a new target triplet look like? "msp430-*-elfbare"? Since we're into stage 3 now I'll look at doing this for GCC 11. Thanks, Jozef > > Jeff > > ps. I thought libitm would fallback to a full software solution and the > hardware requirements were really just enabling fast-paths. >
