Patchwork [CONSOLIDATED,PULL,16/19] tunearch/arm: Differentiate between thumb code generation and thumb capability

login
register
mail settings
Submitter Saul Wold
Date Jan. 31, 2012, 4:13 a.m.
Message ID <79a999f69d58ca98393991d18d0efd274932ff56.1327980240.git.sgw@linux.intel.com>
Download mbox | patch
Permalink /patch/20409/
State New
Headers show

Comments

Saul Wold - Jan. 31, 2012, 4:13 a.m.
From: Khem Raj <raj.khem@gmail.com>

We have diverged a bit from oe.dev where thumb in OVERRIDES meant
the code was being compiled in thumb mode. With tunearch this got
a different meaning where it meant that if a core is capable of
generating thumb code them we will have this in overrides. With this
patch I am trying to address the problem where 'thumbmode' in TUNE_FEATURES
means that code will be compiled in thumb mode by default and
'thumb' is to denote that core is capable of thumb instruction set.

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 .../conf/machine/include/arm/feature-arm-thumb.inc |   18 ++++++++++++++----
 1 files changed, 14 insertions(+), 4 deletions(-)
Phil Blundell - Jan. 31, 2012, 10:48 a.m.
On Mon, 2012-01-30 at 20:13 -0800, Saul Wold wrote:
> We have diverged a bit from oe.dev where thumb in OVERRIDES meant
> the code was being compiled in thumb mode. With tunearch this got
> a different meaning where it meant that if a core is capable of
> generating thumb code them we will have this in overrides. With this
> patch I am trying to address the problem where 'thumbmode' in TUNE_FEATURES
> means that code will be compiled in thumb mode by default and
> 'thumb' is to denote that core is capable of thumb instruction set.

So this patch is changing the meaning of the "thumb" override in
oe-core, right?  Is that really a good idea?

Also, I'm not quite sure I understand what the "thumb" tuning would be
useful for when this patch is applied.  You seem to have removed most of
the code which checks for "thumb" in TUNE_FEATURES which seems to leave
it not doing anything very much.

Can you clarify what exactly is the problem that this patch is solving,
what the old and new semantics of the overrides and tune flags are, and
why it's an improvement?

p.
Khem Raj - Jan. 31, 2012, 3:24 p.m.
On Tue, Jan 31, 2012 at 2:48 AM, Phil Blundell <philb@gnu.org> wrote:
> On Mon, 2012-01-30 at 20:13 -0800, Saul Wold wrote:
>> We have diverged a bit from oe.dev where thumb in OVERRIDES meant
>> the code was being compiled in thumb mode. With tunearch this got
>> a different meaning where it meant that if a core is capable of
>> generating thumb code them we will have this in overrides. With this
>> patch I am trying to address the problem where 'thumbmode' in TUNE_FEATURES
>> means that code will be compiled in thumb mode by default and
>> 'thumb' is to denote that core is capable of thumb instruction set.
>
> So this patch is changing the meaning of the "thumb" override in
> oe-core, right?  Is that really a good idea?
>

yes see below it bridges the gap that was created with tune overhaul

> Also, I'm not quite sure I understand what the "thumb" tuning would be
> useful for when this patch is applied.  You seem to have removed most of
> the code which checks for "thumb" in TUNE_FEATURES which seems to leave
> it not doing anything very much.

it adds 't' or 't2' to package arch but it wont mean the package is
compiled in thumb
mode.

>
> Can you clarify what exactly is the problem that this patch is solving,
> what the old and new semantics of the overrides and tune flags are, and
> why it's an improvement?

recipes has used thumb override when they were being compiled in thumbmode
and not thumb enabled. Currently override gets added regardless of mode which
is not right. This is what it fixes there are few recipes in oe-core
which use this
override and plus helps in porting recipes from oe.dev which uses the override
as explained.

>
> p.
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Patch

diff --git a/meta/conf/machine/include/arm/feature-arm-thumb.inc b/meta/conf/machine/include/arm/feature-arm-thumb.inc
index da29102..cb6f4e7 100644
--- a/meta/conf/machine/include/arm/feature-arm-thumb.inc
+++ b/meta/conf/machine/include/arm/feature-arm-thumb.inc
@@ -4,10 +4,20 @@ 
 # encoded RISC sub-set. Thumb code is smaller (maybe 70% of the ARM size)
 # but requires more instructions (140% for 70% smaller code) so may be
 # slower.
-TUNEVALID[thumb] = "Use thumb instructions instead of ARM"
-ARM_THUMB_M_OPT = "${@['-marm', '-mthumb'][d.getVar('ARM_INSTRUCTION_SET', 1) == 'thumb']}"
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)}"
-OVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "thumb", ":thumb", "", d)}"
+
+# 'thumbmode' in TUNE_FEATURES means default ISA for code generation is thumb
+# 'thumb' in TUNE_FEATURES means the core supports thumb ISA but code
+# generation can happen in arm or thumb
+# having 'thumbmode' would imply 'thumb' naturally
+
+TUNEVALID[thumbmode] = "Use THUMB instruction set instead of ARM"
+ARM_INSTRUCTION_SET ?= "arm"
+AVAILTUNES += "${@bb.utils.contains("ARM_INSTRUCTION_SET", "thumb", "thumbmode", "", d)}"
+TUNE_FEATURES_tune-thumbmode += "${@bb.utils.contains("ARM_INSTRUCTION_SET", "thumb", "thumbmode", "", d)}"
+TUNE_CCARGS += "${@bb.utils.contains("ARM_INSTRUCTION_SET", "thumb", "-mthumb", "-marm", d)}"
+OVERRIDES .= "${@bb.utils.contains("ARM_INSTRUCTION_SET", "thumb", ":thumb", "", d)}"
+
+TUNEVALID[thumb] = "THUMB instruction set capable ARM core"
 
 # Note armv7 will hit on armv7a as well
 ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv4", "thumb" ], "t", "", d)}"