From: "H.J. Lu" <hjl.tools@gmail.com>
To: "Uros Bizjak" <ubizjak@gmail.com>
Cc: "GCC Patches" <gcc-patches@gcc.gnu.org>,
"Ross Ridge" <rridge@csclub.uwaterloo.ca>
Subject: Re:
Date: Sun, 23 Nov 2008 22:08:00 -0000 [thread overview]
Message-ID: <6dc9ffc80811231346g4ea0e4b1o47359d18b8b4c447@mail.gmail.com> (raw)
In-Reply-To: <4929BEBA.9070207@gmail.com>
On Sun, Nov 23, 2008 at 12:36 PM, Uros Bizjak <ubizjak@gmail.com> wrote:
> Hello!
>
>> H.J. Lu writes:
>> >I am not sure how useful that is for 32bit since it will generate a
>> >nop for most machines which do need mfence.
>>
>> I don't understand what you're saying. Using "lock orb" should result
>> in a memory fence on any IA-32 SMP system, old or new. It's just a more
>> heavyweight way of ordering loads and stores.
>>
>> The Linux kernel apparently takes the same approach, using either "lock
>> addl" or "mfence" depending on whether SSE2 instructions are available
>> at compile time.
>>
>
> No, linux dynamically patches its code:
>
> #define mb() alternative("lock; addl $0,0(%%esp)", "mfence",
> X86_FEATURE_XMM2)
> #define rmb() alternative("lock; addl $0,0(%%esp)", "lfence",
> X86_FEATURE_XMM2)
> #define wmb() alternative("lock; addl $0,0(%%esp)", "sfence",
> X86_FEATURE_XMM)
>
> But anyway, gcc can't do that by itself.
>
Can we call cpuid to initialize __cpuid_edx if it is referenced?
--
H.J.
next prev parent reply other threads:[~2008-11-23 21:47 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-23 20:58 Re: Uros Bizjak
2008-11-23 22:08 ` H.J. Lu [this message]
-- strict thread matches above, loose matches on Subject: below --
2023-10-03 9:09 Kito Cheng
2023-10-03 9:11 ` Kito Cheng
2023-08-13 19:05 Eddy Young Tie Yang
2023-08-13 19:18 ` Andrew Pinski
2023-04-02 17:58 Re: d-ni
2021-06-01 14:02 [PATCH][i386] Split not+broadcast+pand to broadcast+pandn Segher Boessenkool
2021-06-02 5:39 ` liuhongt
2021-06-02 5:49 ` Hongtao Liu
2020-05-14 21:05 [PATCH RFC] bootstrap: Update requirement to C++11 Jason Merrill
2020-05-15 7:14 ` Richard Biener
2020-05-15 8:30 ` Richard Sandiford
2020-05-15 9:26 ` Richard Biener
2020-05-15 9:58 ` Richard Sandiford
2020-05-15 10:15 ` Richard Biener
2020-05-15 14:08 ` Richard Sandiford
2020-05-16 1:47 ` Martin Sebor
2020-05-16 2:45 ` Re: Jason Merrill
[not found] <Pine.NEB.4.64.1302141014370.336@cesium.clock.org>
2013-02-14 18:40 ` Re: Xinliang David Li
2013-02-14 19:53 ` Re: Matt Hargett
2013-02-14 20:10 ` Re: Xinliang David Li
2013-02-14 20:37 ` Re: Matt
[not found] <CAGqM8fbk_QwhWoQ=6i_429diC0-v29BpNRaF=xkwX61ETz+T3g@mail.gmail.com>
2012-10-26 9:54 ` Re: Richard Biener
[not found] <CACkGtrg=-AFkMZdxKvzvZ-9OHqAp-aDBr5nQmhEpBCRy7uoC0w@mail.gmail.com>
2012-03-08 22:57 ` Re: Diego Novillo
2011-09-03 13:19 Re: Uros Bizjak
[not found] <20080730133704.GC28583@mx.loc>
2008-07-30 15:07 ` Re: Rafael Espindola
2007-07-06 8:06 Re: Tobias Burnus
2007-07-06 8:30 ` Re: Lee Millward
2007-03-27 22:35 [libstdc++] Richard Henderson
2007-03-27 23:29 ` [libstdc++] Paolo Carlini
2007-03-28 6:10 ` Paolo Bonzini
2007-02-03 3:51 Kenneth Zadeck
2005-07-15 21:25 ИнфоПространство
2005-05-14 18:28 Re: John David Anglin
2004-12-11 3:38 Re: Ульяна Викентьевна
2004-11-29 5:57 Re: Лора Маратовна
[not found] <E9D208E2-EFA8-11D8-8323-000393673036@apple.com>
2004-08-16 19:28 ` Re: Ziemowit Laski
2004-08-16 19:43 ` Re: Zack Weinberg
2004-08-16 20:24 ` Re: Mark Mitchell
2004-08-16 20:36 ` Re: Zack Weinberg
2004-08-16 22:01 ` Re: Ziemowit Laski
2004-08-17 21:35 ` Re: Geoffrey Keating
2004-08-16 20:32 ` Re: Richard Henderson
2004-08-16 20:54 ` Re: Joseph S. Myers
2004-08-16 21:28 ` Re: Ziemowit Laski
2004-08-16 21:47 ` Re: Joseph S. Myers
2004-08-16 22:19 ` Re: Stan Shebs
2001-04-19 3:49 Re: Richard Earnshaw
[not found] <200004180508.BAA08466@jwlab.FEITH.COM>
[not found] ` <20000423104611.B6170@atrey.karlin.mff.cuni.cz>
2000-04-24 5:29 ` Re: grahams
2000-04-25 4:34 ` Re: Jan Hubicka
1998-10-16 10:31 No Subject Nick Clifton
1998-10-17 1:50 ` Jeffrey A Law
1998-10-06 9:51 No Subject Nick Clifton
1998-10-06 19:52 ` Jeffrey A Law
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=6dc9ffc80811231346g4ea0e4b1o47359d18b8b4c447@mail.gmail.com \
--to=hjl.tools@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=rridge@csclub.uwaterloo.ca \
--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).