public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Eric Botcazou <ebotcazou@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc r12-5008] Fix couple of issues in large PIC model on x86-64/VxWorks Date: Mon, 8 Nov 2021 21:13:33 +0000 (GMT) [thread overview] Message-ID: <20211108211333.2A0393858D3C@sourceware.org> (raw) https://gcc.gnu.org/g:6c5fffd127ec00038f379773f751bf803bc548b0 commit r12-5008-g6c5fffd127ec00038f379773f751bf803bc548b0 Author: Eric Botcazou <ebotcazou@adacore.com> Date: Mon Nov 8 22:09:16 2021 +0100 Fix couple of issues in large PIC model on x86-64/VxWorks The first issue is that the !gotoff_operand path of legitimize_pic_address in the large PIC model does not make use of REG when it is available, which breaks for thunks because new pseudo-registers can no longer be created. And the second issue is that the system compiler (LLVM) generates @GOTOFF in large model even for RTP, so we do the same. gcc/ * config/i386/i386.c (legitimize_pic_address): Adjust comment and use the REG argument on the CM_LARGE_PIC code path as well. * config/i386/predicates.md (gotoff_operand): Do not treat VxWorks specially with the large code models. Diff: --- gcc/config/i386/i386.c | 16 +++++++++++++--- gcc/config/i386/predicates.md | 6 ++++-- 2 files changed, 17 insertions(+), 5 deletions(-) diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c index 96635d6858f..e94efdf39fb 100644 --- a/gcc/config/i386/i386.c +++ b/gcc/config/i386/i386.c @@ -11161,7 +11161,7 @@ legitimize_pic_address (rtx orig, rtx reg) new_rtx = gen_rtx_PLUS (Pmode, pic_offset_table_rtx, new_rtx); } else if ((GET_CODE (addr) == SYMBOL_REF && SYMBOL_REF_TLS_MODEL (addr) == 0) - /* We can't use @GOTOFF for text labels + /* We can't always use @GOTOFF for text labels on VxWorks, see gotoff_operand. */ || (TARGET_VXWORKS_RTP && GET_CODE (addr) == LABEL_REF)) { @@ -11190,9 +11190,19 @@ legitimize_pic_address (rtx orig, rtx reg) from the Global Offset Table (@GOT). */ new_rtx = gen_rtx_UNSPEC (Pmode, gen_rtvec (1, addr), UNSPEC_GOT); new_rtx = gen_rtx_CONST (Pmode, new_rtx); + if (TARGET_64BIT) - new_rtx = force_reg (Pmode, new_rtx); - new_rtx = gen_rtx_PLUS (Pmode, pic_offset_table_rtx, new_rtx); + new_rtx = copy_to_suggested_reg (new_rtx, reg, Pmode); + + if (reg != 0) + { + gcc_assert (REG_P (reg)); + new_rtx = expand_simple_binop (Pmode, PLUS, pic_offset_table_rtx, + new_rtx, reg, 1, OPTAB_DIRECT); + } + else + new_rtx = gen_rtx_PLUS (Pmode, pic_offset_table_rtx, new_rtx); + new_rtx = gen_const_mem (Pmode, new_rtx); set_mem_alias_set (new_rtx, ix86_GOT_alias_set ()); } diff --git a/gcc/config/i386/predicates.md b/gcc/config/i386/predicates.md index 114d8d448f1..4ccbe11b842 100644 --- a/gcc/config/i386/predicates.md +++ b/gcc/config/i386/predicates.md @@ -617,9 +617,11 @@ ;; use @GOTOFF unless we are absolutely sure that the symbol is in the ;; same segment as the GOT. Unfortunately, the flexibility of linker ;; scripts means that we can't be sure of that in general, so assume -;; that @GOTOFF is never valid on VxWorks. +;; @GOTOFF is not valid on VxWorks, except with the large code model. (define_predicate "gotoff_operand" - (and (not (match_test "TARGET_VXWORKS_RTP")) + (and (ior (not (match_test "TARGET_VXWORKS_RTP")) + (match_test "ix86_cmodel == CM_LARGE") + (match_test "ix86_cmodel == CM_LARGE_PIC")) (match_operand 0 "local_symbolic_operand"))) ;; Test for various thread-local symbols.
reply other threads:[~2021-11-08 21:13 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20211108211333.2A0393858D3C@sourceware.org \ --to=ebotcazou@gcc.gnu.org \ --cc=gcc-cvs@gcc.gnu.org \ /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: linkBe 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).