[1/4] MSP430: Disable TM clone registry by default

Message ID 20191107213418.2b32fc3c@jozef-kubuntu
State New
Headers show
Series
  • Tweaks to default configuration to reduce code size
Related show

Commit Message

Jozef Lawrynowicz Nov. 7, 2019, 9:34 p.m.
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.

Comments

Jeff Law Nov. 17, 2019, 7:11 p.m. | #1
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?

Jeff

ps.  I thought libitm would fallback to a full software solution and the
hardware requirements were really just enabling fast-paths.
Jozef Lawrynowicz Nov. 24, 2019, 2:20 p.m. | #2
On Sun, 17 Nov 2019 12:11:23 -0700
Jeff Law <law@redhat.com> 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.

>
Jeff Law Nov. 24, 2019, 5:10 p.m. | #3
On 11/24/19 7:20 AM, Jozef Lawrynowicz wrote:
> On Sun, 17 Nov 2019 12:11:23 -0700

> Jeff Law <law@redhat.com> 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.

Jeff
Jozef Lawrynowicz Nov. 24, 2019, 5:48 p.m. | #4
On Sun, 24 Nov 2019 10:10:51 -0700
Jeff Law <law@redhat.com> wrote:

> On 11/24/19 7:20 AM, Jozef Lawrynowicz wrote:

> > On Sun, 17 Nov 2019 12:11:23 -0700

> > Jeff Law <law@redhat.com> 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

>

Patch

From 9dfc5fde568c5a4cd29471888bff538943a995b1 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz <jozef.l@mittosystems.com>
Date: Tue, 29 Oct 2019 14:49:08 +0000
Subject: [PATCH 1/4] MSP430: Disable TM clone registry by default

libgcc/ChangeLog:

2019-11-07  Jozef Lawrynowicz  <jozef.l@mittosystems.com>

	* configure: Regenerate.
	* configure.ac (tm-clone-registry): Disable by default for MSP430.
---
 libgcc/configure    | 9 +++++++++
 libgcc/configure.ac | 8 ++++++++
 2 files changed, 17 insertions(+)

diff --git a/libgcc/configure b/libgcc/configure
index 117e9c97e57..26d4d68a510 100755
--- a/libgcc/configure
+++ b/libgcc/configure
@@ -4964,6 +4964,15 @@  if test "$enable_tm_clone_registry" = no; then
   use_tm_clone_registry=-DUSE_TM_CLONE_REGISTRY=0
 fi
 
+else
+
+use_tm_clone_registry=
+case $target in
+  msp430*)
+   use_tm_clone_registry=-DUSE_TM_CLONE_REGISTRY=0
+   ;;
+esac
+
 fi
 
 
diff --git a/libgcc/configure.ac b/libgcc/configure.ac
index f63c5e736e5..0f225b84117 100644
--- a/libgcc/configure.ac
+++ b/libgcc/configure.ac
@@ -268,6 +268,14 @@  use_tm_clone_registry=
 if test "$enable_tm_clone_registry" = no; then
   use_tm_clone_registry=-DUSE_TM_CLONE_REGISTRY=0
 fi
+],
+[
+use_tm_clone_registry=
+case $target in
+  msp430*)
+   use_tm_clone_registry=-DUSE_TM_CLONE_REGISTRY=0
+   ;;
+esac
 ])
 AC_SUBST([use_tm_clone_registry])
 
-- 
2.17.1