From: Mark Mitchell <mark@codesourcery.com>
To: David Daney <ddaney@avtrex.com>
Cc: Paolo Bonzini <bonzini@gnu.org>, gcc-patches@gcc.gnu.org
Subject: Re: [Patch] 1/3 Add new builtin __builtin_flush_icache().
Date: Fri, 06 Jul 2007 06:07:00 -0000 [thread overview]
Message-ID: <468DB46D.50709@codesourcery.com> (raw)
In-Reply-To: <468C999B.1000102@avtrex.com>
David Daney wrote:
> Ok, I think I have come around to your way of thinking. I still have
> the new predicate __builtin_clear_cache_inline_p() for use in target
> CLEAR_INSN_CACHE definitions, but I leave __clear_cache unchanged.
I don't understand the need for the inline_p function. It seems to me
there are two scenarios:
1. The back-end has an inline definition of __builtin___clear_cache. In
that case, it does:
#define CLEAR_INSN_CACHE(BEG, END) __builtin___clear_cache(BEG, END);
2. The back-end does not have an inline definition of
__builtin_clear_cache. In that case, it does:
#define CLEAR_INSN_CACHE(BEG, END) \
/* Something not involving __builtin___clear_cache */
In both cases, the libgcc __clear_cache routine just does:
CLEAR_INSN_CACHE (beg, end);
And, in both cases, the user can write either __clear_cache (always an
out-of-line call), or __builtin_clear_cache (may be an out-of-line call,
or may be inline code).
Is your concern that in case (1) the back-end has to do two things:
define the builtin and define CLEAR_INSN_CACHE? That's a little lame,
but it doesn't seem worse than having to define two builtins.
Am I missing some intermediate case?
Thanks,
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713
next prev parent reply other threads:[~2007-07-06 3:18 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-01 5:01 David Daney
2007-07-01 5:05 ` [Patch] 2/3 MIPS support for " David Daney
2007-07-01 10:56 ` Richard Sandiford
2007-07-05 7:50 ` David Daney
2007-07-05 19:05 ` Richard Sandiford
2007-07-08 20:00 ` David Daney
2007-07-09 19:07 ` Richard Sandiford
2007-07-11 5:45 ` David Daney
2007-07-01 5:11 ` [Patch] 3/3 FFI: Use __builtin_flush_icache() to flush MIPS i-cache David Daney
2007-07-05 8:34 ` David Daney
2007-07-05 19:08 ` Richard Sandiford
2007-07-11 18:55 ` Tom Tromey
2007-07-01 8:01 ` [Patch] 1/3 Add new builtin __builtin_flush_icache() Paolo Bonzini
2007-07-01 17:51 ` Thiemo Seufer
2007-07-01 18:47 ` David Daney
2007-07-02 5:04 ` Paolo Bonzini
2007-07-03 23:55 ` Mark Mitchell
2007-07-04 7:18 ` Paolo Bonzini
2007-07-04 17:17 ` Mark Mitchell
2007-07-04 17:10 ` David Daney
2007-07-04 17:51 ` Mark Mitchell
2007-07-05 7:36 ` David Daney
2007-07-05 17:59 ` Richard Sandiford
2007-07-05 18:23 ` David Daney
2007-07-05 19:11 ` Richard Sandiford
2007-07-06 6:07 ` Mark Mitchell [this message]
2007-07-06 6:19 ` David Daney
2007-07-06 16:39 ` Mark Mitchell
2007-07-08 19:22 ` David Daney
2007-07-09 19:04 ` Richard Sandiford
2007-07-11 2:22 ` Mark Mitchell
2007-07-11 4:47 ` David Daney
2007-07-05 9:05 ` [Patch] 4/3 i386 target support for __builtin___clear_cache() David Daney
2007-07-08 20:39 ` David Daney
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=468DB46D.50709@codesourcery.com \
--to=mark@codesourcery.com \
--cc=bonzini@gnu.org \
--cc=ddaney@avtrex.com \
--cc=gcc-patches@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: 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).