On Wed, Apr 11, 2012 at 12:51 PM, Jakub Jelinek <ja...@redhat.com> wrote:
> What is TARGET_HLE good for? I thought the point of HLE prefixes
> is that they are silently ignored on older CPUs. So, HLE should be
> always enabled IMHO. If you don't use __ATOMIC_HLE_* bits in __atomic_*
> in your source, it won't be emitted, if you use them, you are supposedly
> intending to compile code that will use normal locking on older CPUs
> and HLE TM on new CPUs.
I think that we should keep -mhle, since it controls if we want HLE
prefixes or not, saving a byte per lock prefix if we know that binary
won't run on HLE enabled processor.
You will also need to check assembler support for new prefixes and
emit ASM_BYTE "0xXX" if not supported. Please see how
HAVE_AS_IX86_SAHF is handled.
+{
+ static char buf[128], hle[16]="";
+ if (INTVAL (operands[4]) & IX86_HLE_ACQUIRE)
+ snprintf (hle, sizeof (hle), "xacquire ");
+ else if (INTVAL (operands[4]) & IX86_HLE_RELEASE)
+ snprintf (hle, sizeof (hle), "release ");
+
Ouch...
const char *hle;
if (INTVAL (...)
hle = "xacquire ";
else if (INTVAL (...)
hle = "xrelease ";
else
hle = "";
I assume that all this will be moved to a helper function that will
also handle HAVE_AS_IX86_HLE.
Uros.
