public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <jeffreyalaw@gmail.com>
To: Tatsuyuki Ishi <ishitatsuyuki@gmail.com>,
	Fangrui Song <maskray@google.com>
Cc: Kito Cheng <kito.cheng@gmail.com>,
	gcc-patches@gcc.gnu.org, Rui Ueyama <rui314@gmail.com>,
	ruiu@bluewhale.systems
Subject: Re: [PATCH v2] RISC-V: Implement TLS Descriptors.
Date: Wed, 15 Nov 2023 22:21:09 -0700	[thread overview]
Message-ID: <f65c9336-5c35-474e-ad83-085eed4f9d1f@gmail.com> (raw)
In-Reply-To: <AFE9B889-1FA7-4B9B-8A21-13414F55EAE8@gmail.com>



On 11/15/23 18:39, Tatsuyuki Ishi wrote:

> 
> As mentioned in the commit message, the use of relaxation-only labels 
> does not seem well supported in current GCC. Creating a label seems to 
> force a basic block and I’m not sure how we can avoid it.
> 
> If there’s a better way to implement this I’m happy to adopt.
In general, yes creating a label in the IL is going to create a new 
block.  But you could emit the label as part of the auipc so that it 
doesn't really show up in the IL.  Then you have to make sure the other 
insns reference the right label, which is certainly do-able.   THere's 
also linker relaxing to worry about....

jeff

  reply	other threads:[~2023-11-16  5:21 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-17 18:12 [PATCH] " Tatsuyuki Ishi
2023-08-29 13:40 ` Kito Cheng
2023-09-08 10:49 ` [PATCH v2] " Tatsuyuki Ishi
2023-10-02 14:10   ` Kito Cheng
2023-11-16  1:17     ` Fangrui Song
2023-11-16  1:39       ` Tatsuyuki Ishi
2023-11-16  5:21         ` Jeff Law [this message]
2023-11-16  5:18       ` Jeff Law
2023-11-16  1:07   ` Jeff Law
2023-11-16  1:51     ` Tatsuyuki Ishi
2023-11-16  5:23       ` Jeff Law
2023-11-16  5:33         ` Fangrui Song
2023-11-16  5:36           ` Jeff Law
2023-11-16  5:37           ` Tatsuyuki Ishi
2023-11-20 13:17 ` [PATCH v3] " Tatsuyuki Ishi
2023-11-21  6:59   ` Fangrui Song
2023-11-21  7:07     ` Tatsuyuki Ishi
2023-12-05 16:49     ` Tatsuyuki Ishi
2023-11-23 10:57   ` Florian Weimer
2023-11-23 11:34     ` Tatsuyuki Ishi
2023-11-23 11:40       ` Florian Weimer
2023-12-05  7:01 ` [PATCH v4] " Tatsuyuki Ishi
2024-01-27  3:24   ` Fangrui Song
2024-03-29  5:52 ` [PATCH v5] " Tatsuyuki Ishi
2024-03-29  6:32   ` Kito Cheng
2024-04-08 14:31     ` Kito Cheng

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=f65c9336-5c35-474e-ad83-085eed4f9d1f@gmail.com \
    --to=jeffreyalaw@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=ishitatsuyuki@gmail.com \
    --cc=kito.cheng@gmail.com \
    --cc=maskray@google.com \
    --cc=rui314@gmail.com \
    --cc=ruiu@bluewhale.systems \
    /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).