Re: [PATCH, ARM] PR71607: New approach to arm_disable_literal_pool

2017-01-30 Thread Andre Vieira (lists) 
On 27/01/17 12:13, Ramana Radhakrishnan wrote:
> On Thu, Jan 26, 2017 at 3:56 PM, Andre Vieira (lists)
>  wrote:
>> On 20/01/17 14:08, Ramana Radhakrishnan wrote:
>>> On Wed, Dec 28, 2016 at 9:58 AM, Andre Vieira (lists)
>>>  wrote:
 On 29/11/16 09:45, Andre Vieira (lists) wrote:
> On 17/11/16 10:00, Ramana Radhakrishnan wrote:
>> On Thu, Oct 6, 2016 at 2:57 PM, Andre Vieira (lists)
>>  wrote:
>>> Hello,
>>>
>>> This patch tackles the issue reported in PR71607. This patch takes a
>>> different approach for disabling the creation of literal pools. Instead
>>> of disabling the patterns that would normally transform the rtl into
>>> actual literal pools, it disables the creation of this literal pool rtl
>>> by making the target hook TARGET_CANNOT_FORCE_CONST_MEM return true if
>>> arm_disable_literal_pool is true. I added patterns to split floating
>>> point constants for both SF and DFmode. A pattern to handle the
>>> addressing of label_refs had to be included as well since all
>>> "memory_operand" patterns are disabled when
>>> TARGET_CANNOT_FORCE_CONST_MEM returns true. Also the pattern for
>>> splitting 32-bit immediates had to be changed, it was not accepting
>>> unsigned 32-bit unsigned integers with the MSB set. I believe
>>> const_int_operand expects the mode of the operand to be set to VOIDmode
>>> and not SImode. I have only changed it in the patterns that were
>>> affecting this code, though I suggest looking into changing it in the
>>> rest of the ARM backend.
>>>
>>> I added more test cases. No regressions for arm-none-eabi with
>>> Cortex-M0, Cortex-M3 and Cortex-M7.
>>>
>>> Is this OK for trunk?
>>
>> Including -mslow-flash-data in your multilib flags ? If no regressions
>> with that ok .
>>
>>
>> regards
>> Ramana
>>
>>>
>
> Hello,
>
> I found some new ICE's with the -mslow-flash-data testing so I had to
> rework this patch. I took the opportunity to rebase it as well.
>
> The problem was with the way the old version of the patch handled label
> references.  After some digging I found I wasn't using the right target
> hook and so I implemented the 'TARGET_USE_BLOCKS_FOR_CONSTANT_P' for
> ARM.  This target hook determines whether a literal pool ends up in an
> 'object_block' structure. So I reverted the changes made in the old
> version of the patch to the ARM implementation of the
> 'TARGET_CANNOT_FORCE_CONST_MEM' hook and rely on
> 'TARGET_USE_BLOCKS_FOR_CONSTANT_P' instead. This patch adds an ARM
> implementation for this hook that returns false if
> 'arm_disable_literal_pool' is set to true and true otherwise.
>
> This version of the patch also reverts back to using the check for
> 'SYMBOL_REF' in 'thumb2_legitimate_address_p' that was removed in the
> last version, this code is required to place the label references in
> rodata sections.
>
> Another thing this patch does is revert the changes made to the 32-bit
> constant split in arm.md. The reason this was needed before was because
> 'real_to_target' returns a long array and does not sign-extend values in
> it, which would make sense on hosts with 64-bit longs. To fix this the
> value is now casted to 'int' first.  It would probably be a good idea to
> change the 'real_to_target' function to return an array with
> 'HOST_WIDE_INT' elements instead and either use all 64-bits or
> sign-extend them.  Something for the future?
>
> I added more test cases in this patch and reran regression tests for:
> Cortex-M0, Cortex-M4 with and without -mslow-flash-data. Also did a
> bootstrap+regressions on arm-none-linux-gnueabihf.
>
> Is this OK for trunk?
>
> Cheers,
> Andre
>
> gcc/ChangeLog:
>
> 2016-11-29  Andre Vieira  
>
> PR target/71607
> * config/arm/arm.md (use_literal_pool): Removes.
> (64-bit immediate split): No longer takes cost into consideration
> if 'arm_disable_literal_pool' is enabled.
> * config/arm/arm.c (arm_use_blocks_for_constant_p): New.
> (TARGET_USE_BLOCKS_FOR_CONSTANT_P): Define.
> (arm_max_const_double_inline_cost): Remove use of
> arm_disable_literal_pool.
> * config/arm/vfp.md (no_literal_pool_df_immediate): New.
> (no_literal_pool_sf_immediate): New.
>
>
> gcc/testsuite/ChangeLog:
>
> 2016-11-29  Andre Vieira  
> Thomas Preud'homme  
>
> PR target/71607
> * gcc.target/arm/thumb2-slow-flash-data.c: Renamed to ...
> * gcc.target/arm/thumb2-slow-flash-data-1.c: ... this.
> *

Re: [PATCH, ARM] PR71607: New approach to arm_disable_literal_pool

2017-01-27 Thread Ramana Radhakrishnan 
On Thu, Jan 26, 2017 at 3:56 PM, Andre Vieira (lists)
 wrote:
> On 20/01/17 14:08, Ramana Radhakrishnan wrote:
>> On Wed, Dec 28, 2016 at 9:58 AM, Andre Vieira (lists)
>>  wrote:
>>> On 29/11/16 09:45, Andre Vieira (lists) wrote:
 On 17/11/16 10:00, Ramana Radhakrishnan wrote:
> On Thu, Oct 6, 2016 at 2:57 PM, Andre Vieira (lists)
>  wrote:
>> Hello,
>>
>> This patch tackles the issue reported in PR71607. This patch takes a
>> different approach for disabling the creation of literal pools. Instead
>> of disabling the patterns that would normally transform the rtl into
>> actual literal pools, it disables the creation of this literal pool rtl
>> by making the target hook TARGET_CANNOT_FORCE_CONST_MEM return true if
>> arm_disable_literal_pool is true. I added patterns to split floating
>> point constants for both SF and DFmode. A pattern to handle the
>> addressing of label_refs had to be included as well since all
>> "memory_operand" patterns are disabled when
>> TARGET_CANNOT_FORCE_CONST_MEM returns true. Also the pattern for
>> splitting 32-bit immediates had to be changed, it was not accepting
>> unsigned 32-bit unsigned integers with the MSB set. I believe
>> const_int_operand expects the mode of the operand to be set to VOIDmode
>> and not SImode. I have only changed it in the patterns that were
>> affecting this code, though I suggest looking into changing it in the
>> rest of the ARM backend.
>>
>> I added more test cases. No regressions for arm-none-eabi with
>> Cortex-M0, Cortex-M3 and Cortex-M7.
>>
>> Is this OK for trunk?
>
> Including -mslow-flash-data in your multilib flags ? If no regressions
> with that ok .
>
>
> regards
> Ramana
>
>>

 Hello,

 I found some new ICE's with the -mslow-flash-data testing so I had to
 rework this patch. I took the opportunity to rebase it as well.

 The problem was with the way the old version of the patch handled label
 references.  After some digging I found I wasn't using the right target
 hook and so I implemented the 'TARGET_USE_BLOCKS_FOR_CONSTANT_P' for
 ARM.  This target hook determines whether a literal pool ends up in an
 'object_block' structure. So I reverted the changes made in the old
 version of the patch to the ARM implementation of the
 'TARGET_CANNOT_FORCE_CONST_MEM' hook and rely on
 'TARGET_USE_BLOCKS_FOR_CONSTANT_P' instead. This patch adds an ARM
 implementation for this hook that returns false if
 'arm_disable_literal_pool' is set to true and true otherwise.

 This version of the patch also reverts back to using the check for
 'SYMBOL_REF' in 'thumb2_legitimate_address_p' that was removed in the
 last version, this code is required to place the label references in
 rodata sections.

 Another thing this patch does is revert the changes made to the 32-bit
 constant split in arm.md. The reason this was needed before was because
 'real_to_target' returns a long array and does not sign-extend values in
 it, which would make sense on hosts with 64-bit longs. To fix this the
 value is now casted to 'int' first.  It would probably be a good idea to
 change the 'real_to_target' function to return an array with
 'HOST_WIDE_INT' elements instead and either use all 64-bits or
 sign-extend them.  Something for the future?

 I added more test cases in this patch and reran regression tests for:
 Cortex-M0, Cortex-M4 with and without -mslow-flash-data. Also did a
 bootstrap+regressions on arm-none-linux-gnueabihf.

 Is this OK for trunk?

 Cheers,
 Andre

 gcc/ChangeLog:

 2016-11-29  Andre Vieira  

 PR target/71607
 * config/arm/arm.md (use_literal_pool): Removes.
 (64-bit immediate split): No longer takes cost into consideration
 if 'arm_disable_literal_pool' is enabled.
 * config/arm/arm.c (arm_use_blocks_for_constant_p): New.
 (TARGET_USE_BLOCKS_FOR_CONSTANT_P): Define.
 (arm_max_const_double_inline_cost): Remove use of
 arm_disable_literal_pool.
 * config/arm/vfp.md (no_literal_pool_df_immediate): New.
 (no_literal_pool_sf_immediate): New.


 gcc/testsuite/ChangeLog:

 2016-11-29  Andre Vieira  
 Thomas Preud'homme  

 PR target/71607
 * gcc.target/arm/thumb2-slow-flash-data.c: Renamed to ...
 * gcc.target/arm/thumb2-slow-flash-data-1.c: ... this.
 * gcc.target/arm/thumb2-slow-flash-data-2.c: New.
 * gcc.target/arm/thumb2-slow-flash-data-3.c: New.
 * gcc.target/arm/thumb2-slow-flash-data-4.c:

Re: [PATCH, ARM] PR71607: New approach to arm_disable_literal_pool

2017-01-26 Thread Andre Vieira (lists) 
On 20/01/17 14:08, Ramana Radhakrishnan wrote:
> On Wed, Dec 28, 2016 at 9:58 AM, Andre Vieira (lists)
>  wrote:
>> On 29/11/16 09:45, Andre Vieira (lists) wrote:
>>> On 17/11/16 10:00, Ramana Radhakrishnan wrote:
 On Thu, Oct 6, 2016 at 2:57 PM, Andre Vieira (lists)
  wrote:
> Hello,
>
> This patch tackles the issue reported in PR71607. This patch takes a
> different approach for disabling the creation of literal pools. Instead
> of disabling the patterns that would normally transform the rtl into
> actual literal pools, it disables the creation of this literal pool rtl
> by making the target hook TARGET_CANNOT_FORCE_CONST_MEM return true if
> arm_disable_literal_pool is true. I added patterns to split floating
> point constants for both SF and DFmode. A pattern to handle the
> addressing of label_refs had to be included as well since all
> "memory_operand" patterns are disabled when
> TARGET_CANNOT_FORCE_CONST_MEM returns true. Also the pattern for
> splitting 32-bit immediates had to be changed, it was not accepting
> unsigned 32-bit unsigned integers with the MSB set. I believe
> const_int_operand expects the mode of the operand to be set to VOIDmode
> and not SImode. I have only changed it in the patterns that were
> affecting this code, though I suggest looking into changing it in the
> rest of the ARM backend.
>
> I added more test cases. No regressions for arm-none-eabi with
> Cortex-M0, Cortex-M3 and Cortex-M7.
>
> Is this OK for trunk?

 Including -mslow-flash-data in your multilib flags ? If no regressions
 with that ok .


 regards
 Ramana

>
>>>
>>> Hello,
>>>
>>> I found some new ICE's with the -mslow-flash-data testing so I had to
>>> rework this patch. I took the opportunity to rebase it as well.
>>>
>>> The problem was with the way the old version of the patch handled label
>>> references.  After some digging I found I wasn't using the right target
>>> hook and so I implemented the 'TARGET_USE_BLOCKS_FOR_CONSTANT_P' for
>>> ARM.  This target hook determines whether a literal pool ends up in an
>>> 'object_block' structure. So I reverted the changes made in the old
>>> version of the patch to the ARM implementation of the
>>> 'TARGET_CANNOT_FORCE_CONST_MEM' hook and rely on
>>> 'TARGET_USE_BLOCKS_FOR_CONSTANT_P' instead. This patch adds an ARM
>>> implementation for this hook that returns false if
>>> 'arm_disable_literal_pool' is set to true and true otherwise.
>>>
>>> This version of the patch also reverts back to using the check for
>>> 'SYMBOL_REF' in 'thumb2_legitimate_address_p' that was removed in the
>>> last version, this code is required to place the label references in
>>> rodata sections.
>>>
>>> Another thing this patch does is revert the changes made to the 32-bit
>>> constant split in arm.md. The reason this was needed before was because
>>> 'real_to_target' returns a long array and does not sign-extend values in
>>> it, which would make sense on hosts with 64-bit longs. To fix this the
>>> value is now casted to 'int' first.  It would probably be a good idea to
>>> change the 'real_to_target' function to return an array with
>>> 'HOST_WIDE_INT' elements instead and either use all 64-bits or
>>> sign-extend them.  Something for the future?
>>>
>>> I added more test cases in this patch and reran regression tests for:
>>> Cortex-M0, Cortex-M4 with and without -mslow-flash-data. Also did a
>>> bootstrap+regressions on arm-none-linux-gnueabihf.
>>>
>>> Is this OK for trunk?
>>>
>>> Cheers,
>>> Andre
>>>
>>> gcc/ChangeLog:
>>>
>>> 2016-11-29  Andre Vieira  
>>>
>>> PR target/71607
>>> * config/arm/arm.md (use_literal_pool): Removes.
>>> (64-bit immediate split): No longer takes cost into consideration
>>> if 'arm_disable_literal_pool' is enabled.
>>> * config/arm/arm.c (arm_use_blocks_for_constant_p): New.
>>> (TARGET_USE_BLOCKS_FOR_CONSTANT_P): Define.
>>> (arm_max_const_double_inline_cost): Remove use of
>>> arm_disable_literal_pool.
>>> * config/arm/vfp.md (no_literal_pool_df_immediate): New.
>>> (no_literal_pool_sf_immediate): New.
>>>
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>> 2016-11-29  Andre Vieira  
>>> Thomas Preud'homme  
>>>
>>> PR target/71607
>>> * gcc.target/arm/thumb2-slow-flash-data.c: Renamed to ...
>>> * gcc.target/arm/thumb2-slow-flash-data-1.c: ... this.
>>> * gcc.target/arm/thumb2-slow-flash-data-2.c: New.
>>> * gcc.target/arm/thumb2-slow-flash-data-3.c: New.
>>> * gcc.target/arm/thumb2-slow-flash-data-4.c: New.
>>> * gcc.target/arm/thumb2-slow-flash-data-5.c: New.
>>>
>> Hello,
>>
>> As I have mentioned in my commit message for the fix on embedded-6  (see
>>

Re: [PATCH, ARM] PR71607: New approach to arm_disable_literal_pool

2017-01-20 Thread Ramana Radhakrishnan 
On Wed, Dec 28, 2016 at 9:58 AM, Andre Vieira (lists)
 wrote:
> On 29/11/16 09:45, Andre Vieira (lists) wrote:
>> On 17/11/16 10:00, Ramana Radhakrishnan wrote:
>>> On Thu, Oct 6, 2016 at 2:57 PM, Andre Vieira (lists)
>>>  wrote:
 Hello,

 This patch tackles the issue reported in PR71607. This patch takes a
 different approach for disabling the creation of literal pools. Instead
 of disabling the patterns that would normally transform the rtl into
 actual literal pools, it disables the creation of this literal pool rtl
 by making the target hook TARGET_CANNOT_FORCE_CONST_MEM return true if
 arm_disable_literal_pool is true. I added patterns to split floating
 point constants for both SF and DFmode. A pattern to handle the
 addressing of label_refs had to be included as well since all
 "memory_operand" patterns are disabled when
 TARGET_CANNOT_FORCE_CONST_MEM returns true. Also the pattern for
 splitting 32-bit immediates had to be changed, it was not accepting
 unsigned 32-bit unsigned integers with the MSB set. I believe
 const_int_operand expects the mode of the operand to be set to VOIDmode
 and not SImode. I have only changed it in the patterns that were
 affecting this code, though I suggest looking into changing it in the
 rest of the ARM backend.

 I added more test cases. No regressions for arm-none-eabi with
 Cortex-M0, Cortex-M3 and Cortex-M7.

 Is this OK for trunk?
>>>
>>> Including -mslow-flash-data in your multilib flags ? If no regressions
>>> with that ok .
>>>
>>>
>>> regards
>>> Ramana
>>>

>>
>> Hello,
>>
>> I found some new ICE's with the -mslow-flash-data testing so I had to
>> rework this patch. I took the opportunity to rebase it as well.
>>
>> The problem was with the way the old version of the patch handled label
>> references.  After some digging I found I wasn't using the right target
>> hook and so I implemented the 'TARGET_USE_BLOCKS_FOR_CONSTANT_P' for
>> ARM.  This target hook determines whether a literal pool ends up in an
>> 'object_block' structure. So I reverted the changes made in the old
>> version of the patch to the ARM implementation of the
>> 'TARGET_CANNOT_FORCE_CONST_MEM' hook and rely on
>> 'TARGET_USE_BLOCKS_FOR_CONSTANT_P' instead. This patch adds an ARM
>> implementation for this hook that returns false if
>> 'arm_disable_literal_pool' is set to true and true otherwise.
>>
>> This version of the patch also reverts back to using the check for
>> 'SYMBOL_REF' in 'thumb2_legitimate_address_p' that was removed in the
>> last version, this code is required to place the label references in
>> rodata sections.
>>
>> Another thing this patch does is revert the changes made to the 32-bit
>> constant split in arm.md. The reason this was needed before was because
>> 'real_to_target' returns a long array and does not sign-extend values in
>> it, which would make sense on hosts with 64-bit longs. To fix this the
>> value is now casted to 'int' first.  It would probably be a good idea to
>> change the 'real_to_target' function to return an array with
>> 'HOST_WIDE_INT' elements instead and either use all 64-bits or
>> sign-extend them.  Something for the future?
>>
>> I added more test cases in this patch and reran regression tests for:
>> Cortex-M0, Cortex-M4 with and without -mslow-flash-data. Also did a
>> bootstrap+regressions on arm-none-linux-gnueabihf.
>>
>> Is this OK for trunk?
>>
>> Cheers,
>> Andre
>>
>> gcc/ChangeLog:
>>
>> 2016-11-29  Andre Vieira  
>>
>> PR target/71607
>> * config/arm/arm.md (use_literal_pool): Removes.
>> (64-bit immediate split): No longer takes cost into consideration
>> if 'arm_disable_literal_pool' is enabled.
>> * config/arm/arm.c (arm_use_blocks_for_constant_p): New.
>> (TARGET_USE_BLOCKS_FOR_CONSTANT_P): Define.
>> (arm_max_const_double_inline_cost): Remove use of
>> arm_disable_literal_pool.
>> * config/arm/vfp.md (no_literal_pool_df_immediate): New.
>> (no_literal_pool_sf_immediate): New.
>>
>>
>> gcc/testsuite/ChangeLog:
>>
>> 2016-11-29  Andre Vieira  
>> Thomas Preud'homme  
>>
>> PR target/71607
>> * gcc.target/arm/thumb2-slow-flash-data.c: Renamed to ...
>> * gcc.target/arm/thumb2-slow-flash-data-1.c: ... this.
>> * gcc.target/arm/thumb2-slow-flash-data-2.c: New.
>> * gcc.target/arm/thumb2-slow-flash-data-3.c: New.
>> * gcc.target/arm/thumb2-slow-flash-data-4.c: New.
>> * gcc.target/arm/thumb2-slow-flash-data-5.c: New.
>>
> Hello,
>
> As I have mentioned in my commit message for the fix on embedded-6  (see
> https://gcc.gnu.org/ml/gcc-patches/2016-12/msg01304.html) I found an
> issue with this code when testing its backport on the embedded-6-branch.
>
> I misread the definition of the target hook
>

[PING][PATCH, ARM] PR71607: New approach to arm_disable_literal_pool

2017-01-16 Thread Andre Vieira (lists) 
On 28/12/16 09:58, Andre Vieira (lists) wrote:
> On 29/11/16 09:45, Andre Vieira (lists) wrote:
>> On 17/11/16 10:00, Ramana Radhakrishnan wrote:
>>> On Thu, Oct 6, 2016 at 2:57 PM, Andre Vieira (lists)
>>>  wrote:
 Hello,

 This patch tackles the issue reported in PR71607. This patch takes a
 different approach for disabling the creation of literal pools. Instead
 of disabling the patterns that would normally transform the rtl into
 actual literal pools, it disables the creation of this literal pool rtl
 by making the target hook TARGET_CANNOT_FORCE_CONST_MEM return true if
 arm_disable_literal_pool is true. I added patterns to split floating
 point constants for both SF and DFmode. A pattern to handle the
 addressing of label_refs had to be included as well since all
 "memory_operand" patterns are disabled when
 TARGET_CANNOT_FORCE_CONST_MEM returns true. Also the pattern for
 splitting 32-bit immediates had to be changed, it was not accepting
 unsigned 32-bit unsigned integers with the MSB set. I believe
 const_int_operand expects the mode of the operand to be set to VOIDmode
 and not SImode. I have only changed it in the patterns that were
 affecting this code, though I suggest looking into changing it in the
 rest of the ARM backend.

 I added more test cases. No regressions for arm-none-eabi with
 Cortex-M0, Cortex-M3 and Cortex-M7.

 Is this OK for trunk?
>>>
>>> Including -mslow-flash-data in your multilib flags ? If no regressions
>>> with that ok .
>>>
>>>
>>> regards
>>> Ramana
>>>

>>
>> Hello,
>>
>> I found some new ICE's with the -mslow-flash-data testing so I had to
>> rework this patch. I took the opportunity to rebase it as well.
>>
>> The problem was with the way the old version of the patch handled label
>> references.  After some digging I found I wasn't using the right target
>> hook and so I implemented the 'TARGET_USE_BLOCKS_FOR_CONSTANT_P' for
>> ARM.  This target hook determines whether a literal pool ends up in an
>> 'object_block' structure. So I reverted the changes made in the old
>> version of the patch to the ARM implementation of the
>> 'TARGET_CANNOT_FORCE_CONST_MEM' hook and rely on
>> 'TARGET_USE_BLOCKS_FOR_CONSTANT_P' instead. This patch adds an ARM
>> implementation for this hook that returns false if
>> 'arm_disable_literal_pool' is set to true and true otherwise.
>>
>> This version of the patch also reverts back to using the check for
>> 'SYMBOL_REF' in 'thumb2_legitimate_address_p' that was removed in the
>> last version, this code is required to place the label references in
>> rodata sections.
>>
>> Another thing this patch does is revert the changes made to the 32-bit
>> constant split in arm.md. The reason this was needed before was because
>> 'real_to_target' returns a long array and does not sign-extend values in
>> it, which would make sense on hosts with 64-bit longs. To fix this the
>> value is now casted to 'int' first.  It would probably be a good idea to
>> change the 'real_to_target' function to return an array with
>> 'HOST_WIDE_INT' elements instead and either use all 64-bits or
>> sign-extend them.  Something for the future?
>>
>> I added more test cases in this patch and reran regression tests for:
>> Cortex-M0, Cortex-M4 with and without -mslow-flash-data. Also did a
>> bootstrap+regressions on arm-none-linux-gnueabihf.
>>
>> Is this OK for trunk?
>>
>> Cheers,
>> Andre
>>
>> gcc/ChangeLog:
>>
>> 2016-11-29  Andre Vieira  
>>
>> PR target/71607
>> * config/arm/arm.md (use_literal_pool): Removes.
>> (64-bit immediate split): No longer takes cost into consideration
>> if 'arm_disable_literal_pool' is enabled.
>> * config/arm/arm.c (arm_use_blocks_for_constant_p): New.
>> (TARGET_USE_BLOCKS_FOR_CONSTANT_P): Define.
>> (arm_max_const_double_inline_cost): Remove use of
>> arm_disable_literal_pool.
>> * config/arm/vfp.md (no_literal_pool_df_immediate): New.
>> (no_literal_pool_sf_immediate): New.
>>
>>
>> gcc/testsuite/ChangeLog:
>>
>> 2016-11-29  Andre Vieira  
>> Thomas Preud'homme  
>>
>> PR target/71607
>> * gcc.target/arm/thumb2-slow-flash-data.c: Renamed to ...
>> * gcc.target/arm/thumb2-slow-flash-data-1.c: ... this.
>> * gcc.target/arm/thumb2-slow-flash-data-2.c: New.
>> * gcc.target/arm/thumb2-slow-flash-data-3.c: New.
>> * gcc.target/arm/thumb2-slow-flash-data-4.c: New.
>> * gcc.target/arm/thumb2-slow-flash-data-5.c: New.
>>
> Hello,
> 
> As I have mentioned in my commit message for the fix on embedded-6  (see
> https://gcc.gnu.org/ml/gcc-patches/2016-12/msg01304.html) I found an
> issue with this code when testing its backport on the embedded-6-branch.
> 
> I misread the definition of the target hook
> TARGET_USE_BLOCKS_FOR_CONSTANT_P and it seems the

Re: [PATCH, ARM] PR71607: New approach to arm_disable_literal_pool

2016-12-28 Thread Andre Vieira (lists) 
On 29/11/16 09:45, Andre Vieira (lists) wrote:
> On 17/11/16 10:00, Ramana Radhakrishnan wrote:
>> On Thu, Oct 6, 2016 at 2:57 PM, Andre Vieira (lists)
>>  wrote:
>>> Hello,
>>>
>>> This patch tackles the issue reported in PR71607. This patch takes a
>>> different approach for disabling the creation of literal pools. Instead
>>> of disabling the patterns that would normally transform the rtl into
>>> actual literal pools, it disables the creation of this literal pool rtl
>>> by making the target hook TARGET_CANNOT_FORCE_CONST_MEM return true if
>>> arm_disable_literal_pool is true. I added patterns to split floating
>>> point constants for both SF and DFmode. A pattern to handle the
>>> addressing of label_refs had to be included as well since all
>>> "memory_operand" patterns are disabled when
>>> TARGET_CANNOT_FORCE_CONST_MEM returns true. Also the pattern for
>>> splitting 32-bit immediates had to be changed, it was not accepting
>>> unsigned 32-bit unsigned integers with the MSB set. I believe
>>> const_int_operand expects the mode of the operand to be set to VOIDmode
>>> and not SImode. I have only changed it in the patterns that were
>>> affecting this code, though I suggest looking into changing it in the
>>> rest of the ARM backend.
>>>
>>> I added more test cases. No regressions for arm-none-eabi with
>>> Cortex-M0, Cortex-M3 and Cortex-M7.
>>>
>>> Is this OK for trunk?
>>
>> Including -mslow-flash-data in your multilib flags ? If no regressions
>> with that ok .
>>
>>
>> regards
>> Ramana
>>
>>>
> 
> Hello,
> 
> I found some new ICE's with the -mslow-flash-data testing so I had to
> rework this patch. I took the opportunity to rebase it as well.
> 
> The problem was with the way the old version of the patch handled label
> references.  After some digging I found I wasn't using the right target
> hook and so I implemented the 'TARGET_USE_BLOCKS_FOR_CONSTANT_P' for
> ARM.  This target hook determines whether a literal pool ends up in an
> 'object_block' structure. So I reverted the changes made in the old
> version of the patch to the ARM implementation of the
> 'TARGET_CANNOT_FORCE_CONST_MEM' hook and rely on
> 'TARGET_USE_BLOCKS_FOR_CONSTANT_P' instead. This patch adds an ARM
> implementation for this hook that returns false if
> 'arm_disable_literal_pool' is set to true and true otherwise.
> 
> This version of the patch also reverts back to using the check for
> 'SYMBOL_REF' in 'thumb2_legitimate_address_p' that was removed in the
> last version, this code is required to place the label references in
> rodata sections.
> 
> Another thing this patch does is revert the changes made to the 32-bit
> constant split in arm.md. The reason this was needed before was because
> 'real_to_target' returns a long array and does not sign-extend values in
> it, which would make sense on hosts with 64-bit longs. To fix this the
> value is now casted to 'int' first.  It would probably be a good idea to
> change the 'real_to_target' function to return an array with
> 'HOST_WIDE_INT' elements instead and either use all 64-bits or
> sign-extend them.  Something for the future?
> 
> I added more test cases in this patch and reran regression tests for:
> Cortex-M0, Cortex-M4 with and without -mslow-flash-data. Also did a
> bootstrap+regressions on arm-none-linux-gnueabihf.
> 
> Is this OK for trunk?
> 
> Cheers,
> Andre
> 
> gcc/ChangeLog:
> 
> 2016-11-29  Andre Vieira  
> 
> PR target/71607
> * config/arm/arm.md (use_literal_pool): Removes.
> (64-bit immediate split): No longer takes cost into consideration
> if 'arm_disable_literal_pool' is enabled.
> * config/arm/arm.c (arm_use_blocks_for_constant_p): New.
> (TARGET_USE_BLOCKS_FOR_CONSTANT_P): Define.
> (arm_max_const_double_inline_cost): Remove use of
> arm_disable_literal_pool.
> * config/arm/vfp.md (no_literal_pool_df_immediate): New.
> (no_literal_pool_sf_immediate): New.
> 
> 
> gcc/testsuite/ChangeLog:
> 
> 2016-11-29  Andre Vieira  
> Thomas Preud'homme  
> 
> PR target/71607
> * gcc.target/arm/thumb2-slow-flash-data.c: Renamed to ...
> * gcc.target/arm/thumb2-slow-flash-data-1.c: ... this.
> * gcc.target/arm/thumb2-slow-flash-data-2.c: New.
> * gcc.target/arm/thumb2-slow-flash-data-3.c: New.
> * gcc.target/arm/thumb2-slow-flash-data-4.c: New.
> * gcc.target/arm/thumb2-slow-flash-data-5.c: New.
> 
Hello,

As I have mentioned in my commit message for the fix on embedded-6  (see
https://gcc.gnu.org/ml/gcc-patches/2016-12/msg01304.html) I found an
issue with this code when testing its backport on the embedded-6-branch.

I misread the definition of the target hook
TARGET_USE_BLOCKS_FOR_CONSTANT_P and it seems the way I implemented it
before only changed code generation if the -mslow-flash-data option
wasn't passed. I.e. I don't need to implement it to solve this

Re: [PATCH, ARM] PR71607: New approach to arm_disable_literal_pool

2016-11-29 Thread Andre Vieira (lists) 
On 17/11/16 10:00, Ramana Radhakrishnan wrote:
> On Thu, Oct 6, 2016 at 2:57 PM, Andre Vieira (lists)
>  wrote:
>> Hello,
>>
>> This patch tackles the issue reported in PR71607. This patch takes a
>> different approach for disabling the creation of literal pools. Instead
>> of disabling the patterns that would normally transform the rtl into
>> actual literal pools, it disables the creation of this literal pool rtl
>> by making the target hook TARGET_CANNOT_FORCE_CONST_MEM return true if
>> arm_disable_literal_pool is true. I added patterns to split floating
>> point constants for both SF and DFmode. A pattern to handle the
>> addressing of label_refs had to be included as well since all
>> "memory_operand" patterns are disabled when
>> TARGET_CANNOT_FORCE_CONST_MEM returns true. Also the pattern for
>> splitting 32-bit immediates had to be changed, it was not accepting
>> unsigned 32-bit unsigned integers with the MSB set. I believe
>> const_int_operand expects the mode of the operand to be set to VOIDmode
>> and not SImode. I have only changed it in the patterns that were
>> affecting this code, though I suggest looking into changing it in the
>> rest of the ARM backend.
>>
>> I added more test cases. No regressions for arm-none-eabi with
>> Cortex-M0, Cortex-M3 and Cortex-M7.
>>
>> Is this OK for trunk?
> 
> Including -mslow-flash-data in your multilib flags ? If no regressions
> with that ok .
> 
> 
> regards
> Ramana
> 
>>

Hello,

I found some new ICE's with the -mslow-flash-data testing so I had to
rework this patch. I took the opportunity to rebase it as well.

The problem was with the way the old version of the patch handled label
references.  After some digging I found I wasn't using the right target
hook and so I implemented the 'TARGET_USE_BLOCKS_FOR_CONSTANT_P' for
ARM.  This target hook determines whether a literal pool ends up in an
'object_block' structure. So I reverted the changes made in the old
version of the patch to the ARM implementation of the
'TARGET_CANNOT_FORCE_CONST_MEM' hook and rely on
'TARGET_USE_BLOCKS_FOR_CONSTANT_P' instead. This patch adds an ARM
implementation for this hook that returns false if
'arm_disable_literal_pool' is set to true and true otherwise.

This version of the patch also reverts back to using the check for
'SYMBOL_REF' in 'thumb2_legitimate_address_p' that was removed in the
last version, this code is required to place the label references in
rodata sections.

Another thing this patch does is revert the changes made to the 32-bit
constant split in arm.md. The reason this was needed before was because
'real_to_target' returns a long array and does not sign-extend values in
it, which would make sense on hosts with 64-bit longs. To fix this the
value is now casted to 'int' first.  It would probably be a good idea to
change the 'real_to_target' function to return an array with
'HOST_WIDE_INT' elements instead and either use all 64-bits or
sign-extend them.  Something for the future?

I added more test cases in this patch and reran regression tests for:
Cortex-M0, Cortex-M4 with and without -mslow-flash-data. Also did a
bootstrap+regressions on arm-none-linux-gnueabihf.

Is this OK for trunk?

Cheers,
Andre

gcc/ChangeLog:

2016-11-29  Andre Vieira  

PR target/71607
* config/arm/arm.md (use_literal_pool): Removes.
(64-bit immediate split): No longer takes cost into consideration
if 'arm_disable_literal_pool' is enabled.
* config/arm/arm.c (arm_use_blocks_for_constant_p): New.
(TARGET_USE_BLOCKS_FOR_CONSTANT_P): Define.
(arm_max_const_double_inline_cost): Remove use of
arm_disable_literal_pool.
* config/arm/vfp.md (no_literal_pool_df_immediate): New.
(no_literal_pool_sf_immediate): New.


gcc/testsuite/ChangeLog:

2016-11-29  Andre Vieira  
Thomas Preud'homme  

PR target/71607
* gcc.target/arm/thumb2-slow-flash-data.c: Renamed to ...
* gcc.target/arm/thumb2-slow-flash-data-1.c: ... this.
* gcc.target/arm/thumb2-slow-flash-data-2.c: New.
* gcc.target/arm/thumb2-slow-flash-data-3.c: New.
* gcc.target/arm/thumb2-slow-flash-data-4.c: New.
* gcc.target/arm/thumb2-slow-flash-data-5.c: New.
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 
abd3276f13125e87fe7a88b60f0bf98cd580e7fb..1fcf57ccd9bda6c477db7a98084fd6f0e359de21
 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -300,6 +300,8 @@ static bool arm_asm_elf_flags_numeric (unsigned int flags, 
unsigned int *num);
 static unsigned int arm_elf_section_type_flags (tree decl, const char *name,
int reloc);
 static void arm_expand_divmod_libfunc (rtx, machine_mode, rtx, rtx, rtx *, rtx 
*);
+static bool arm_use_blocks_for_constant_p (machine_mode var, const_rtx x);
+
 
 /* Table of machine attributes.  */
 static const struct attribute_spec

Re: [PATCH, ARM] PR71607: New approach to arm_disable_literal_pool

2016-11-17 Thread Ramana Radhakrishnan 
On Thu, Oct 6, 2016 at 2:57 PM, Andre Vieira (lists)
 wrote:
> Hello,
>
> This patch tackles the issue reported in PR71607. This patch takes a
> different approach for disabling the creation of literal pools. Instead
> of disabling the patterns that would normally transform the rtl into
> actual literal pools, it disables the creation of this literal pool rtl
> by making the target hook TARGET_CANNOT_FORCE_CONST_MEM return true if
> arm_disable_literal_pool is true. I added patterns to split floating
> point constants for both SF and DFmode. A pattern to handle the
> addressing of label_refs had to be included as well since all
> "memory_operand" patterns are disabled when
> TARGET_CANNOT_FORCE_CONST_MEM returns true. Also the pattern for
> splitting 32-bit immediates had to be changed, it was not accepting
> unsigned 32-bit unsigned integers with the MSB set. I believe
> const_int_operand expects the mode of the operand to be set to VOIDmode
> and not SImode. I have only changed it in the patterns that were
> affecting this code, though I suggest looking into changing it in the
> rest of the ARM backend.
>
> I added more test cases. No regressions for arm-none-eabi with
> Cortex-M0, Cortex-M3 and Cortex-M7.
>
> Is this OK for trunk?

Including -mslow-flash-data in your multilib flags ? If no regressions
with that ok .


regards
Ramana

>
> Cheers,
> Andre
>
> gcc/ChangeLog:
>
> 2016-10-06  Andre Vieira  
>
> PR target/71607
> * config/arm/arm.md (use_literal_pool): Remove.
> (64-bit immediate split): No longer take cost into consideration
> if 'arm_disable_literal_pool' is enabled.
> (32-bit const split): Remove SImode from constant, which was
> not allowing large unsigned integers to be split.
> * config/arm/arm.c (thumb2_legitimate_address_p): Remove handling
> of 'arm_disable_literal_pool' here.
> (arm_max_const_double_inline_cost): Likewise.
> (arm_cannot_force_const_mem): Return false for
> 'arm_disable_literal_pool'.
> (thumb2_legitimate_address_p): Remove check involving
> 'arm_disable_literal_pool'
> that is no longer relevant.
> (arm_legitimate_constant_p): Ignore the outcome of
> 'arm_cannot_force_const_mem'
> if 'arm_disable_literal_pool' is enabled.
> * config/arm/vfp.md (no_literal_pool_df_immediate): New.
> (no_literal_pool_sf_immediate): New.
> * config/arm/thumb2.md (*thumb2_movsi_labelref_insn): New.
>
> gcc/testsuite/ChangeLog:
>
> 2016-10-06  Andre Vieira  
> Thomas Preud'homme  
>
> PR target/71607
> * gcc.target/arm/thumb2-slow-flash-data.c: Rename to ...
> * gcc.target/arm/thumb2-slow-flash-data-1.c: ... this.
> * gcc.target/arm/thumb2-slow-flash-data-2.c: New.
> * gcc.target/arm/thumb2-slow-flash-data-3.c: New.
>
>

Re: [Ping][PATCH, ARM] PR71607: New approach to arm_disable_literal_pool

2016-11-08 Thread Andre Vieira (lists) 
On 21/10/16 09:55, Andre Vieira (lists) wrote:
> On 06/10/16 14:57, Andre Vieira (lists) wrote:
>> Hello,
>>
>> This patch tackles the issue reported in PR71607. This patch takes a
>> different approach for disabling the creation of literal pools. Instead
>> of disabling the patterns that would normally transform the rtl into
>> actual literal pools, it disables the creation of this literal pool rtl
>> by making the target hook TARGET_CANNOT_FORCE_CONST_MEM return true if
>> arm_disable_literal_pool is true. I added patterns to split floating
>> point constants for both SF and DFmode. A pattern to handle the
>> addressing of label_refs had to be included as well since all
>> "memory_operand" patterns are disabled when
>> TARGET_CANNOT_FORCE_CONST_MEM returns true. Also the pattern for
>> splitting 32-bit immediates had to be changed, it was not accepting
>> unsigned 32-bit unsigned integers with the MSB set. I believe
>> const_int_operand expects the mode of the operand to be set to VOIDmode
>> and not SImode. I have only changed it in the patterns that were
>> affecting this code, though I suggest looking into changing it in the
>> rest of the ARM backend.
>>
>> I added more test cases. No regressions for arm-none-eabi with
>> Cortex-M0, Cortex-M3 and Cortex-M7.
>>
>> Is this OK for trunk?
>>
>> Cheers,
>> Andre
>>
>> gcc/ChangeLog:
>>
>> 2016-10-06  Andre Vieira  
>>
>> PR target/71607
>> * config/arm/arm.md (use_literal_pool): Remove.
>> (64-bit immediate split): No longer take cost into consideration
>> if 'arm_disable_literal_pool' is enabled.
>> (32-bit const split): Remove SImode from constant, which was
>> not allowing large unsigned integers to be split.
>> * config/arm/arm.c (thumb2_legitimate_address_p): Remove handling
>> of 'arm_disable_literal_pool' here.
>> (arm_max_const_double_inline_cost): Likewise.
>> (arm_cannot_force_const_mem): Return false for
>> 'arm_disable_literal_pool'.
>> (thumb2_legitimate_address_p): Remove check involving
>> 'arm_disable_literal_pool'
>> that is no longer relevant.
>> (arm_legitimate_constant_p): Ignore the outcome of
>> 'arm_cannot_force_const_mem'
>> if 'arm_disable_literal_pool' is enabled.
>> * config/arm/vfp.md (no_literal_pool_df_immediate): New.
>> (no_literal_pool_sf_immediate): New.
>> * config/arm/thumb2.md (*thumb2_movsi_labelref_insn): New.
>>
>> gcc/testsuite/ChangeLog:
>>
>> 2016-10-06  Andre Vieira  
>> Thomas Preud'homme  
>>
>> PR target/71607
>> * gcc.target/arm/thumb2-slow-flash-data.c: Rename to ...
>> * gcc.target/arm/thumb2-slow-flash-data-1.c: ... this.
>> * gcc.target/arm/thumb2-slow-flash-data-2.c: New.
>> * gcc.target/arm/thumb2-slow-flash-data-3.c: New.
>>
>>
> Ping.
> 
Ping.

[Ping][PATCH, ARM] PR71607: New approach to arm_disable_literal_pool

2016-10-21 Thread Andre Vieira (lists) 
On 06/10/16 14:57, Andre Vieira (lists) wrote:
> Hello,
> 
> This patch tackles the issue reported in PR71607. This patch takes a
> different approach for disabling the creation of literal pools. Instead
> of disabling the patterns that would normally transform the rtl into
> actual literal pools, it disables the creation of this literal pool rtl
> by making the target hook TARGET_CANNOT_FORCE_CONST_MEM return true if
> arm_disable_literal_pool is true. I added patterns to split floating
> point constants for both SF and DFmode. A pattern to handle the
> addressing of label_refs had to be included as well since all
> "memory_operand" patterns are disabled when
> TARGET_CANNOT_FORCE_CONST_MEM returns true. Also the pattern for
> splitting 32-bit immediates had to be changed, it was not accepting
> unsigned 32-bit unsigned integers with the MSB set. I believe
> const_int_operand expects the mode of the operand to be set to VOIDmode
> and not SImode. I have only changed it in the patterns that were
> affecting this code, though I suggest looking into changing it in the
> rest of the ARM backend.
> 
> I added more test cases. No regressions for arm-none-eabi with
> Cortex-M0, Cortex-M3 and Cortex-M7.
> 
> Is this OK for trunk?
> 
> Cheers,
> Andre
> 
> gcc/ChangeLog:
> 
> 2016-10-06  Andre Vieira  
> 
> PR target/71607
> * config/arm/arm.md (use_literal_pool): Remove.
> (64-bit immediate split): No longer take cost into consideration
> if 'arm_disable_literal_pool' is enabled.
> (32-bit const split): Remove SImode from constant, which was
> not allowing large unsigned integers to be split.
> * config/arm/arm.c (thumb2_legitimate_address_p): Remove handling
> of 'arm_disable_literal_pool' here.
> (arm_max_const_double_inline_cost): Likewise.
> (arm_cannot_force_const_mem): Return false for
> 'arm_disable_literal_pool'.
> (thumb2_legitimate_address_p): Remove check involving
> 'arm_disable_literal_pool'
> that is no longer relevant.
> (arm_legitimate_constant_p): Ignore the outcome of
> 'arm_cannot_force_const_mem'
> if 'arm_disable_literal_pool' is enabled.
> * config/arm/vfp.md (no_literal_pool_df_immediate): New.
> (no_literal_pool_sf_immediate): New.
> * config/arm/thumb2.md (*thumb2_movsi_labelref_insn): New.
> 
> gcc/testsuite/ChangeLog:
> 
> 2016-10-06  Andre Vieira  
> Thomas Preud'homme  
> 
> PR target/71607
> * gcc.target/arm/thumb2-slow-flash-data.c: Rename to ...
> * gcc.target/arm/thumb2-slow-flash-data-1.c: ... this.
> * gcc.target/arm/thumb2-slow-flash-data-2.c: New.
> * gcc.target/arm/thumb2-slow-flash-data-3.c: New.
> 
> 
Ping.

[PATCH, ARM] PR71607: New approach to arm_disable_literal_pool

2016-10-06 Thread Andre Vieira (lists) 
Hello,

This patch tackles the issue reported in PR71607. This patch takes a
different approach for disabling the creation of literal pools. Instead
of disabling the patterns that would normally transform the rtl into
actual literal pools, it disables the creation of this literal pool rtl
by making the target hook TARGET_CANNOT_FORCE_CONST_MEM return true if
arm_disable_literal_pool is true. I added patterns to split floating
point constants for both SF and DFmode. A pattern to handle the
addressing of label_refs had to be included as well since all
"memory_operand" patterns are disabled when
TARGET_CANNOT_FORCE_CONST_MEM returns true. Also the pattern for
splitting 32-bit immediates had to be changed, it was not accepting
unsigned 32-bit unsigned integers with the MSB set. I believe
const_int_operand expects the mode of the operand to be set to VOIDmode
and not SImode. I have only changed it in the patterns that were
affecting this code, though I suggest looking into changing it in the
rest of the ARM backend.

I added more test cases. No regressions for arm-none-eabi with
Cortex-M0, Cortex-M3 and Cortex-M7.

Is this OK for trunk?

Cheers,
Andre

gcc/ChangeLog:

2016-10-06  Andre Vieira  

PR target/71607
* config/arm/arm.md (use_literal_pool): Remove.
(64-bit immediate split): No longer take cost into consideration
if 'arm_disable_literal_pool' is enabled.
(32-bit const split): Remove SImode from constant, which was
not allowing large unsigned integers to be split.
* config/arm/arm.c (thumb2_legitimate_address_p): Remove handling
of 'arm_disable_literal_pool' here.
(arm_max_const_double_inline_cost): Likewise.
(arm_cannot_force_const_mem): Return false for
'arm_disable_literal_pool'.
(thumb2_legitimate_address_p): Remove check involving
'arm_disable_literal_pool'
that is no longer relevant.
(arm_legitimate_constant_p): Ignore the outcome of
'arm_cannot_force_const_mem'
if 'arm_disable_literal_pool' is enabled.
* config/arm/vfp.md (no_literal_pool_df_immediate): New.
(no_literal_pool_sf_immediate): New.
* config/arm/thumb2.md (*thumb2_movsi_labelref_insn): New.

gcc/testsuite/ChangeLog:

2016-10-06  Andre Vieira  
Thomas Preud'homme  

PR target/71607
* gcc.target/arm/thumb2-slow-flash-data.c: Rename to ...
* gcc.target/arm/thumb2-slow-flash-data-1.c: ... this.
* gcc.target/arm/thumb2-slow-flash-data-2.c: New.
* gcc.target/arm/thumb2-slow-flash-data-3.c: New.


From 88304e3d5507787a5453c9745c42c4c5f4093975 Mon Sep 17 00:00:00 2001
From: Andre Simoes Dias Vieira 
Date: Tue, 30 Aug 2016 13:26:49 +0100
Subject: [PATCH 1/2] gcc32rm-709

Fix disabling of literal pool

mend
---
 gcc/config/arm/arm.c   | 30 ++---
 gcc/config/arm/arm.md  | 13 ++--
 gcc/config/arm/thumb2.md   | 11 
 gcc/config/arm/vfp.md  | 34 ++
 .../gcc.target/arm/thumb2-slow-flash-data-1.c  | 73 ++
 .../gcc.target/arm/thumb2-slow-flash-data-2.c  | 27 
 .../gcc.target/arm/thumb2-slow-flash-data-3.c  | 24 +++
 .../gcc.target/arm/thumb2-slow-flash-data.c| 73 --
 8 files changed, 179 insertions(+), 106 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/arm/thumb2-slow-flash-data-1.c
 create mode 100644 gcc/testsuite/gcc.target/arm/thumb2-slow-flash-data-2.c
 create mode 100644 gcc/testsuite/gcc.target/arm/thumb2-slow-flash-data-3.c
 delete mode 100644 gcc/testsuite/gcc.target/arm/thumb2-slow-flash-data.c

diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 946f308ca84e232af8af6eca4813464914cbd59c..dce2569a2c3867464039e6a57e11acee2b28c423 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -7380,25 +7380,6 @@ thumb2_legitimate_address_p (machine_mode mode, rtx x, int strict_p)
 		  && thumb2_legitimate_index_p (mode, xop0, strict_p)));
 }
 
-  /* Normally we can assign constant values to target registers without
- the help of constant pool.  But there are cases we have to use constant
- pool like:
- 1) assign a label to register.
- 2) sign-extend a 8bit value to 32bit and then assign to register.
-
- Constant pool access in format:
- (set (reg r0) (mem (symbol_ref (".LC0"
- will cause the use of literal pool (later in function arm_reorg).
- So here we mark such format as an invalid format, then the compiler
- will adjust it into:
- (set (reg r0) (symbol_ref (".LC0")))
- (set (reg r0) (mem (reg r0))).
- No extra register is required, and (mem (reg r0)) won't cause the use
- of literal pools.  */
-  else if (arm_disable_literal_pool && code == SYMBOL_REF
-	   && CONSTANT_POOL_ADDRESS_P (x))
-return 0;
-
   else if (GET_MODE_CLASS (mode) !=