From: Richard Biener <richard.guenther@gmail.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: Jakub Jelinek <jakub@redhat.com>, Andi Kleen <ak@linux.intel.com>,
Jonathan Wakely <jwakely.gcc@gmail.com>,
gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org, rth@redhat.com
Subject: Re: [PATCH 1/4] Mark all member functions with memory models always inline
Date: Wed, 20 Mar 2013 10:38:00 -0000 [thread overview]
Message-ID: <CAFiYyc3Gfc_KMupTFdA9V3DEz8bXovKb_E7inG7CNwwgEw3MCg@mail.gmail.com> (raw)
In-Reply-To: <20130319173016.GF20853@two.firstfloor.org>
On Tue, Mar 19, 2013 at 6:30 PM, Andi Kleen <andi@firstfloor.org> wrote:
> On Tue, Mar 19, 2013 at 05:10:22PM +0100, Jakub Jelinek wrote:
>> On Tue, Mar 19, 2013 at 08:51:21AM -0700, Andi Kleen wrote:
>> > > Using __always_inline as the name of the macro is a bad idea, glibc
>> > > headers use that macro already. Just use something else in public headers
>> > > that aren't part of glibc.
>> >
>> > That's why I had the ifdef, but ok. I'll use __force_inline then.
>>
>> I'd say Jonathan's _GLIBCXX_ALWAYS_INLINE would be better.
>>
>> BTW, have you verified always_inline works fine for -O0?
>
> I did some simple tests and it seemed to work.
>
> But thanks for the counter example.
>
>>
>> with -O0 -mhle doesn't result in xacquire, guess for !optimize
>> get_memmodel would need to look through chain of SSA_NAMEs if SSA_NAME
>> (that can appear because of inlining), looking for INTEGER_CSTs.
>
> interesting. so need more fixes. i'll look into that. Is there
> already a convenient helper for it?
Not without using information created by TER which is disabled for this
case because of different line information. If TER would not be disabled
for this reason it would already work automagically.
Eventually we can relax this restriction for constants that are only fed
through temporaries ...
> There was an alternative approach of using a template, but I suppose
> that would have the same problem.
Possibly yes, but I guess the frontend substitutes without going through
an extra temporary (if all arguments are template parameters!)
Richard.
>
> -Andi
next prev parent reply other threads:[~2013-03-20 10:38 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-16 13:30 Andi Kleen
2013-03-16 13:29 ` [PATCH 2/4] Avoid non constant memory model uses in libatomic Andi Kleen
2013-03-19 21:23 ` Richard Henderson
2013-03-16 13:29 ` [PATCH 4/4] Add warning for non-constant memory models Andi Kleen
2013-03-19 21:23 ` Richard Henderson
2013-03-16 13:30 ` [PATCH 3/4] Avoid nonconst memmodels in libitm's local outdated copy of <atomic> too Andi Kleen
2013-03-19 21:23 ` Richard Henderson
[not found] ` <CAH6eHdR=VhEfAes6S97CfBf0Newe1h3EeoxreRKKHpi4mpJh=w@mail.gmail.com>
[not found] ` <20130319064639.GA12913@tucnak.redhat.com>
2013-03-19 15:51 ` [PATCH 1/4] Mark all member functions with memory models always inline Andi Kleen
2013-03-19 16:10 ` Jakub Jelinek
2013-03-19 17:30 ` Andi Kleen
2013-03-20 10:38 ` Richard Biener [this message]
2013-03-20 10:46 ` Jakub Jelinek
2013-03-20 11:21 ` Richard Biener
2013-03-20 11:25 ` Jakub Jelinek
2013-03-20 11:29 ` Richard Biener
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=CAFiYyc3Gfc_KMupTFdA9V3DEz8bXovKb_E7inG7CNwwgEw3MCg@mail.gmail.com \
--to=richard.guenther@gmail.com \
--cc=ak@linux.intel.com \
--cc=andi@firstfloor.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=jwakely.gcc@gmail.com \
--cc=libstdc++@gcc.gnu.org \
--cc=rth@redhat.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).