This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch ARM] Switch ARM to unified asm.
- From: Ramana Radhakrishnan <ramana dot gcc at googlemail dot com>
- To: Christian Bruel <christian dot bruel at st dot com>
- Cc: Ramana Radhakrishnan <ramana dot radhakrishnan at foss dot arm dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 12 Nov 2015 10:07:33 +0000
- Subject: Re: [Patch ARM] Switch ARM to unified asm.
- Authentication-results: sourceware.org; auth=none
- References: <5641D99E dot 2080607 at foss dot arm dot com> <56445A33 dot 5030901 at st dot com>
On Thu, Nov 12, 2015 at 9:21 AM, Christian Bruel <christian.bruel@st.com> wrote:
> Hi Ramana,
>
> On 11/10/2015 12:48 PM, Ramana Radhakrishnan wrote:
>>
>> [Resending as I managed to muck this up with my mail client]
>>
>> Hi,
>>
>> I held off committing a previous version of this patch that I posted in
>> July to be nice to folks backporting fixes and to watch for any objections
>> to move the ARM backend completely over into the unified assembler.
>>
>> The patch does the following.
>>
>> * The compiler now generates code in all ISA modes in unified asm.
>> * We've had unified asm only for the last 10 years, ever since the first
>> Thumb2 support was put in, the disassembler generates output in unified
>> assembler, while the compiler output is always in divided syntax for ARM
>> state.
>> * This means patterns get simpler not having to worry about the position
>> of the condition in a conditional instruction. For example we now
>> consistently use
>> a. ldrbeq rather than ldreqb
>> b. movseq rather than moveqs
>> c. Or indeed the appropriate push / pop instructions whereever
>> appropriate.
>>
>>
>> The compiler behaviour has not changed in terms of what it does with
>> inline assembler, that still remains in divided syntax and over time we need
>> to move all of this over to unified syntax if we can do so as all the
>> official documentation is now in terms of unified asm. I've been carrying
>> this in my tree for quite a while and am reasonably happy that it is stable.
>> I will watch out for any fallout in the coming weeks with this but it is
>> better to take this now rather than later given we are hitting the end of
>> stage1.
>>
>> Tested on arm-none-eabi - applied to trunk.
>>
>>
>
> I see a failure with an outdated check for the unified assembly. OK to fix ?
>
OK thanks.
Ramana
>
>