public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "H.J. Lu" <hjl.tools@gmail.com>
To: Uros Bizjak <ubizjak@gmail.com>,
	"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
		Jakub Jelinek <jakub@redhat.com>,
	Richard Sandiford <rdsandiford@googlemail.com>
Subject: Re: [PATCH] x86-64: Load external function address via GOT slot
Date: Mon, 20 Jun 2016 20:34:00 -0000	[thread overview]
Message-ID: <CAMe9rOrQkuA8J6vYFWM=eYKTknbzeeW3aB_Pc+MYPY5p1_uazg@mail.gmail.com> (raw)
In-Reply-To: <87shw7d4nl.fsf@googlemail.com>

On Mon, Jun 20, 2016 at 12:46 PM, Richard Sandiford
<rdsandiford@googlemail.com> wrote:
> Uros Bizjak <ubizjak@gmail.com> writes:
>> On Mon, Jun 20, 2016 at 9:19 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>> On Mon, Jun 20, 2016 at 12:13 PM, Uros Bizjak <ubizjak@gmail.com> wrote:
>>>> On Mon, Jun 20, 2016 at 7:05 PM, H.J. Lu <hongjiu.lu@intel.com> wrote:
>>>>> Hi,
>>>>>
>>>>> This patch implements the alternate code sequence recommended in
>>>>>
>>>>> https://groups.google.com/forum/#!topic/x86-64-abi/de5_KnLHxtI
>>>>>
>>>>> to load external function address via GOT slot with
>>>>>
>>>>> movq func@GOTPCREL(%rip), %rax
>>>>>
>>>>> so that linker won't create an PLT entry for extern function
>>>>> address.
>>>>>
>>>>> Tested on x86-64.  OK for trunk?
>>>>
>>>>> +  else if (ix86_force_load_from_GOT_p (op1))
>>>>> +    {
>>>>> +      /* Load the external function address via the GOT slot to
>>>>> +        avoid PLT.  */
>>>>> +      op1 = gen_rtx_UNSPEC (Pmode, gen_rtvec (1, op1),
>>>>> +                           (TARGET_64BIT
>>>>> +                            ? UNSPEC_GOTPCREL
>>>>> +                            : UNSPEC_GOT));
>>>>> +      op1 = gen_rtx_CONST (Pmode, op1);
>>>>> +      op1 = gen_const_mem (Pmode, op1);
>>>>> +      /* This symbol must be referenced via a load from the Global
>>>>> +        Offset Table.  */
>>>>> +      set_mem_alias_set (op1, ix86_GOT_alias_set ());
>>>>> +      op1 = convert_to_mode (mode, op1, 1);
>>>>> +      op1 = force_reg (mode, op1);
>>>>> +      emit_insn (gen_rtx_SET (op0, op1));
>>>>> +      /* Generate a CLOBBER so that there will be no REG_EQUAL note
>>>>> +        on the last insn to prevent cse and fwprop from replacing
>>>>> +        a GOT load with a constant.  */
>>>>> +      rtx tmp = gen_reg_rtx (Pmode);
>>>>> +      emit_clobber (tmp);
>>>>> +      return;
>>>>
>>>> Jeff, is this the recommended way to prevent CSE, as far as RTL
>>>> infrastructure is concerned? I didn't find any example of this
>>>> approach with other targets.
>>>>
>>>
>>> FWIW, the similar approach is used in ix86_expand_vector_move_misalign,
>>> ix86_expand_convert_uns_didf_sse and ix86_expand_vector_init_general
>>> as well as other targets:
>>>
>>> frv/frv.c:  emit_clobber (op0);
>>> frv/frv.c:  emit_clobber (op1);
>>> im32c/m32c.c:  /*  emit_clobber (gen_rtx_REG (HImode, R0L_REGNO)); */
>>> s390/s390.c:  emit_clobber (addr);
>>> s390/s390.md:  emit_clobber (reg0);
>>> s390/s390.md:  emit_clobber (reg1);
>>> s390/s390.md:  emit_clobber (reg0);
>>> s390/s390.md:  emit_clobber (reg0);
>>> s390/s390.md:  emit_clobber (reg1);
>>
>> These usages mark the whole register as being "clobbered"
>> (=undefined), before only a part of register is written, e.g.:
>>
>>       emit_clobber (int_xmm);
>>       emit_move_insn (gen_lowpart (DImode, int_xmm), input);
>>
>> They aren't used to prevent unwanted CSE.
>
> Since it's being called in the move expander, I thought the normal
> way of preventing the constant being rematerialised would be to reject
> it in the move define_insn predicates.
>
> FWIW, I agree that using a clobber for this is going to be fragile.
>

Here is the alternative from clobber.


-- 
H.J.
--
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index a68983c..79999df 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -2347,7 +2347,7 @@
 (define_insn "*movsi_internal"
   [(set (match_operand:SI 0 "nonimmediate_operand"
  "=r,m ,*y,*y,?rm,?*y,*v,*v,*v,m ,?r ,?r,?*Yi,*k  ,*rm")
- (match_operand:SI 1 "general_operand"
+ (match_operand:SI 1 "ix86_general_operand"
  "g ,re,C ,*y,*y ,rm ,C ,*v,m ,*v,*Yj,*v,r   ,*krm,*k"))]
   "!(MEM_P (operands[0]) && MEM_P (operands[1]))"
 {
@@ -2564,7 +2564,7 @@
 (define_insn "*movqi_internal"
   [(set (match_operand:QI 0 "nonimmediate_operand"
  "=q,q ,q ,r,r ,?r,m ,k,k,r ,m,k")
- (match_operand:QI 1 "general_operand"
+ (match_operand:QI 1 "ix86_general_operand"
  "q ,qn,qm,q,rn,qm,qn,r ,k,k,k,m"))]
   "!(MEM_P (operands[0]) && MEM_P (operands[1]))"
 {
diff --git a/gcc/config/i386/predicates.md b/gcc/config/i386/predicates.md
index 06a0002..a471deb 100644
--- a/gcc/config/i386/predicates.md
+++ b/gcc/config/i386/predicates.md
@@ -367,6 +367,12 @@
     }
 })

+;; Return true if OP is general operand representable on ix86
+(define_predicate "ix86_general_operand"
+  (and (match_operand 0 "general_operand")
+       (ior (not (match_code "symbol_ref"))
+    (match_test "!ix86_force_load_from_GOT_p (op)"))))
+
 ;; Return true if size of VALUE can be stored in a sign
 ;; extended immediate field.
 (define_predicate "x86_64_immediate_size_operand"
@@ -1036,6 +1042,9 @@
   struct ix86_address parts;
   int ok;

+  if (ix86_force_load_from_GOT_p (op))
+    return false;
+
   if (!CONST_INT_P (op)
       && mode != VOIDmode
       && GET_MODE (op) != mode)

  reply	other threads:[~2016-06-20 20:34 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-20 17:05 H.J. Lu
2016-06-20 19:13 ` Uros Bizjak
2016-06-20 19:19   ` H.J. Lu
2016-06-20 19:27     ` Uros Bizjak
2016-06-20 19:47       ` Richard Sandiford
2016-06-20 20:34         ` H.J. Lu [this message]
2016-06-21 12:40         ` H.J. Lu
2016-06-21 18:22           ` Uros Bizjak
2016-06-21 19:51             ` H.J. Lu
2016-06-22 22:12               ` Uros Bizjak

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='CAMe9rOrQkuA8J6vYFWM=eYKTknbzeeW3aB_Pc+MYPY5p1_uazg@mail.gmail.com' \
    --to=hjl.tools@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=rdsandiford@googlemail.com \
    --cc=ubizjak@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).