This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [i386, patch, RFC] HLE support in GCC
> What if another vendor shows up, perhaps on another architecture?
HLE code is currently usually x86 specific. e.g. for practical spin locks
you have to include a __builtin_ia32_pause() on lock locked to stop speculation,
otherwise the lock path will speculate too, which is very inefficient.
So if you wanted abstracted HLE, you would need more abstracted builtins first.
> > Currently it's highly error prone -- on the Russel hard to misuse scale not higher
> > than 1 as is [1]
>
> It would be a three, if the patch would contain documentation of the
> additional bit. I guess that's a hint :)
Yes :)
> However, I'm not 100% sure that HLE is only useful paired with
> acquire/release memory orders in general (ie, possibly on other archs).
It's actually stronger on the instruction level (see other mail),
except for the MOV release.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
- References:
- Re: [i386, patch, RFC] HLE support in GCC
- Re: [i386, patch, RFC] HLE support in GCC
- Re: [i386, patch, RFC] HLE support in GCC
- Re: [i386, patch, RFC] HLE support in GCC
- Re: [i386, patch, RFC] HLE support in GCC
- Re: [i386, patch, RFC] HLE support in GCC
- Re: [i386, patch, RFC] HLE support in GCC
- Re: [i386, patch, RFC] HLE support in GCC
- Re: [i386, patch, RFC] HLE support in GCC
- Re: [i386, patch, RFC] HLE support in GCC