This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [i386, patch, RFC] HLE support in GCC


On Wed, Apr 11, 2012 at 12:51 PM, Jakub Jelinek <jakub@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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]