This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch ARM] Allow any register for DImode values in Thumb2.
- From: Ramana Radhakrishnan <ramana dot gcc at googlemail dot com>
- To: Christophe Lyon <christophe dot lyon at linaro dot org>
- Cc: "gcc-patches at gcc dot gnu dot org ," <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 23 Apr 2014 14:32:07 +0100
- Subject: Re: [Patch ARM] Allow any register for DImode values in Thumb2.
- Authentication-results: sourceware.org; auth=none
- References: <530F446D dot 2020007 at arm dot com> <CAKdteOYdPjRwFuEAiNdzXsC-5PTBwbk2soahpBxF4+iep+EFrA at mail dot gmail dot com> <CAJA7tRaQENWK8prY=N7TQgAaD6iVU99EbqG8t4ZU5s4kGiieEg at mail dot gmail dot com>
- Reply-to: ramrad01 at arm dot com
On Wed, Apr 23, 2014 at 2:06 PM, Ramana Radhakrishnan
<ramana.gcc@googlemail.com> wrote:
> On Wed, Apr 23, 2014 at 1:53 PM, Christophe Lyon
> <christophe.lyon@linaro.org> wrote:
>> On 27 February 2014 14:58, Ramana Radhakrishnan <ramrad01@arm.com> wrote:
>>> Hi
>>>
>>> I noticed that for T32 we don't allow any old register for DImode values.
>>> The restriction of an even register is true only for ARM state because the
>>> ISA doesn't allow any old register in this place. In a few large .i files
>>> that I had knocking about, noticed a nice drop in stack usage and a
>>> generally improved register allocation strategy.
>>>
>>> Queued for stage1 after suitable testing including a bootstrap and
>>> regression test in Thumb2 found no issues.
>>>
>>> regards
>>> Ramana
>>>
>>> <DATE> Ramana Radhakrishnan <ramana.radhakrishnan@arm.com>
>>>
>>> * config/arm/arm.c (arm_hard_regno_mode_ok): Loosen restrictions on
>>> core registers for DImode values in Thumb2.
>>>
>>
>> Hi Ramana,
>>
>> I've noticed some regressions after this patch has been committed (rev 209615):
>>
>> gcc.c-torture/compile/pr34856.c -O3 -fomit-frame-pointer
>> -funroll-all-loops -finline-functions
>> gcc.c-torture/compile/pr34856.c -O3 -fomit-frame-pointer -funroll-loops
>> gcc.c-torture/execute/scal-to-vec1.c compilation, -O2
>> gcc.c-torture/execute/scal-to-vec1.c compilation, -O2 -flto
>> -fno-use-linker-plugin -flto-partition=none
>> gcc.c-torture/execute/scal-to-vec1.c compilation, -O2 -flto
>> -fuse-linker-plugin -fno-fat-lto-objects
>
>
>> Now all produce ICE in several GCC configurations (mostly when
>> generating thumb code) eg:
>> --target arm-none-eabi --with-cpu=cortex-a9 --with-mode=thumb
>> --target arm-none-linux-gnueabi --with-cpu=cortex-a9 --with-mode=thumb
>>
>
> Thanks for the report - I'll have a look. I've had this in a tree for
> testing for sometime that runs these configurations atleast the
> bare-metal arm-none-eabi one with multilib testing for thumb.
Uggh I hate it that gmail sometimes cuts off your sentences.
"Needless to say, this is surprising"
>
>> but it's OK for target arm-none-linux-gnueabihf.
>>
>> See http://cbuild.validation.linaro.org/build/cross-validation/gcc/209615/report-build-info.html
>>
>> Christophe.