This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC, ARM] later split of symbol_refs
- From: Dmitry Melnik <dm at ispras dot ru>
- To: Ramana Radhakrishnan <ramana dot radhakrishnan at linaro dot org>
- Cc: Richard Earnshaw <rearnsha at arm dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Ramana Radhakrishnan <Ramana dot Radhakrishnan at arm dot com>, "julian at codesourcery dot com" <julian at codesourcery dot com>, "jie at codesourcery dot com" <jie at codesourcery dot com>, "leitz at ispras dot ru" <leitz at ispras dot ru>, "abel at ispras dot ru" <abel at ispras dot ru>
- Date: Wed, 04 Jul 2012 18:47:20 +0400
- Subject: Re: [RFC, ARM] later split of symbol_refs
- References: <4FEB1F9C.40004@ispras.ru> <4FEB2C87.7070602@arm.com> <4FEDB23E.8070705@ispras.ru> <CACUk7=VMZT7WUBvRdk8NzcVzdYmvGzkeHFm3EOp6FTfyHY_Lgw@mail.gmail.com>
On 06/29/2012 06:31 PM, Ramana Radhakrishnan wrote:
Ok with this comment?
+;; Split symbol_refs at the later stage (after cprop), instead of
generating
+;; movt/movw pair directly at expand. Otherwise corresponding high_sum
+;; and lo_sum would be merged back into memory load at cprop. However,
+;; if the default is to prefer movt/movw rather than a load from the
constant
+;; pool, the performance is usually better.
+;; Split symbol_refs at the later stage (after cprop), instead of generating
+;; movt/movw pair directly at expand. Otherwise corresponding high_sum
+;; and lo_sum would be merged back into memory load at cprop. However,
I would rewrite part of your comment as
+;; movt/movw is preferable, because it usually executes faster than a load
"However if the default is to prefer to use movw/movt rather than the
constant pool use that. instead of a load from the constant pool."
--
Best regards,
Dmitry
2009-05-29 Julian Brown <julian@codesourcery.com>
gcc/
* config/arm/arm.md (movsi): Don't split symbol refs here.
(define_split): New.
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -5472,14 +5472,6 @@
optimize && can_create_pseudo_p ());
DONE;
}
-
- if (TARGET_USE_MOVT && !target_word_relocations
- && GET_CODE (operands[1]) == SYMBOL_REF
- && !flag_pic && !arm_tls_referenced_p (operands[1]))
- {
- arm_emit_movpair (operands[0], operands[1]);
- DONE;
- }
}
else /* TARGET_THUMB1... */
{
@@ -5588,6 +5580,24 @@
"
)
+;; Split symbol_refs at the later stage (after cprop), instead of generating
+;; movt/movw pair directly at expand. Otherwise corresponding high_sum
+;; and lo_sum would be merged back into memory load at cprop. However,
+;; if the default is to prefer movt/movw rather than a load from the constant
+;; pool, the performance is usually better.
+(define_split
+ [(set (match_operand:SI 0 "arm_general_register_operand" "")
+ (match_operand:SI 1 "general_operand" ""))]
+ "TARGET_32BIT
+ && TARGET_USE_MOVT && GET_CODE (operands[1]) == SYMBOL_REF
+ && !flag_pic && !target_word_relocations
+ && !arm_tls_referenced_p (operands[1])"
+ [(clobber (const_int 0))]
+{
+ arm_emit_movpair (operands[0], operands[1]);
+ DONE;
+})
+
(define_insn "*thumb1_movsi_insn"
[(set (match_operand:SI 0 "nonimmediate_operand" "=l,l,l,l,l,>,l, m,*l*h*k")
(match_operand:SI 1 "general_operand" "l, I,J,K,>,l,mi,l,*l*h*k"))]