All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tim Bird <tim.bird@am.sony.com>
To: "Jon Medhurst (Tixy)" <tixy@linaro.org>
Cc: "linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"Kleen, Andi" <andi.kleen@intel.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	linux kernel <linux-kernel@vger.kernel.org>,
	Russell King <rmk@arm.linux.org.uk>
Subject: Re: RFC: right way to conditional-ize some macros for LTO
Date: Tue, 2 Apr 2013 14:08:46 -0700	[thread overview]
Message-ID: <515B48DE.4000808@am.sony.com> (raw)
In-Reply-To: <1364907037.3650.54.camel@linaro1.home>

On 04/02/2013 05:50 AM, Jon Medhurst (Tixy) wrote:
> On Fri, 2013-03-29 at 11:50 -0700, Tim Bird wrote:
>> The macros themselves seem empty.  Can someone tell me what they do?
>> What is the status of these macros?  Are they even needed?
> 
> The names of the macros are for Thumb2 instructions which are redundant
> when building for the ARM instruction set. Newer toolchains which
> support the unified assembler syntax will effectively ignore them and I
> guess these empty macros are there so people can write assembler which
> will compile with older toolchains.
> 
>> Could they be
>> made conditional on something like NEED_IT_MACROS, and then have that set only
>> in the arch/arm/kernel/kprobes-test-thumb.c, before the unified.h is included?
> 
> That file needs the real Thumb2 instructions, not empty macros, and
> indeed it doesn't use them, because it is only compiled when
> CONFIG_THUMB2_KERNEL=y and that selects CONFIG_ARM_ASM_UNIFIED and those
> 'it' macro's are guarded by #ifndef CONFIG_ARM_ASM_UNIFIED.
> 
> Note, there are other files which use the 'it' instructions, e.g.
> arch/arm/include/asm/futex.h.
> 
>> I would like get this minor issue resolved in mainline, to make it easier for Andi
>> to get his LTO work upstream and have it work with ARM.
>>
>> Any suggestions are welcome.
> 
> If your toolchain supports the unified assembler syntax, you could try
> enabling CONFIG_ARM_ASM_UNIFIED in ARM builds.

Thanks very much!  It may well be that any toolchain capable of supporting
LTO will support the unified assembler syntax, in which case it would make
sense for LTO to enable this, on ARM.  I'll check it out.
 -- Tim

=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================


WARNING: multiple messages have this Message-ID (diff)
From: tim.bird@am.sony.com (Tim Bird)
To: linux-arm-kernel@lists.infradead.org
Subject: RFC: right way to conditional-ize some macros for LTO
Date: Tue, 2 Apr 2013 14:08:46 -0700	[thread overview]
Message-ID: <515B48DE.4000808@am.sony.com> (raw)
In-Reply-To: <1364907037.3650.54.camel@linaro1.home>

On 04/02/2013 05:50 AM, Jon Medhurst (Tixy) wrote:
> On Fri, 2013-03-29 at 11:50 -0700, Tim Bird wrote:
>> The macros themselves seem empty.  Can someone tell me what they do?
>> What is the status of these macros?  Are they even needed?
> 
> The names of the macros are for Thumb2 instructions which are redundant
> when building for the ARM instruction set. Newer toolchains which
> support the unified assembler syntax will effectively ignore them and I
> guess these empty macros are there so people can write assembler which
> will compile with older toolchains.
> 
>> Could they be
>> made conditional on something like NEED_IT_MACROS, and then have that set only
>> in the arch/arm/kernel/kprobes-test-thumb.c, before the unified.h is included?
> 
> That file needs the real Thumb2 instructions, not empty macros, and
> indeed it doesn't use them, because it is only compiled when
> CONFIG_THUMB2_KERNEL=y and that selects CONFIG_ARM_ASM_UNIFIED and those
> 'it' macro's are guarded by #ifndef CONFIG_ARM_ASM_UNIFIED.
> 
> Note, there are other files which use the 'it' instructions, e.g.
> arch/arm/include/asm/futex.h.
> 
>> I would like get this minor issue resolved in mainline, to make it easier for Andi
>> to get his LTO work upstream and have it work with ARM.
>>
>> Any suggestions are welcome.
> 
> If your toolchain supports the unified assembler syntax, you could try
> enabling CONFIG_ARM_ASM_UNIFIED in ARM builds.

Thanks very much!  It may well be that any toolchain capable of supporting
LTO will support the unified assembler syntax, in which case it would make
sense for LTO to enable this, on ARM.  I'll check it out.
 -- Tim

=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================

  reply	other threads:[~2013-04-02 21:04 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-29 18:50 RFC: right way to conditional-ize some macros for LTO Tim Bird
2013-03-29 18:50 ` Tim Bird
2013-04-02 12:50 ` Jon Medhurst (Tixy)
2013-04-02 12:50   ` Jon Medhurst (Tixy)
2013-04-02 21:08   ` Tim Bird [this message]
2013-04-02 21:08     ` Tim Bird
2013-04-08 18:10   ` Dave Martin
2013-04-08 18:10     ` Dave Martin
2013-04-11 18:18   ` Tim Bird
2013-04-11 18:18     ` Tim Bird

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=515B48DE.4000808@am.sony.com \
    --to=tim.bird@am.sony.com \
    --cc=andi.kleen@intel.com \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rmk@arm.linux.org.uk \
    --cc=tixy@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.