Tablegen bug???

Should tablegen detect this as an error, or is it documented as a limitation somewhere that we've missed?

    In the tablegen-generated file AMDILGenIntrinsics.inc, we have a bunch of if statements comparing strings, many of which are dead, preventing correct recognition of some intrinsics in the their text form. I'm not quite sure what GET_FUNCTION_RECOGNIZER is used for, but if it's used, it's broken… :wink:

    Here's a small segment:

// Function name -> enum value recognizer code.
#ifdef GET_FUNCTION_RECOGNIZER
StringRef NameR(Name+6, Len-6); // Skip over 'llvm.'
switch (Name[5]) { // Dispatch on first letter.
default: break;
case 'A':

   if (NameR.startswith("MDIL.barrier.")) return AMDILIntrinsic::AMDIL_barrier;
   if (NameR.startswith("MDIL.barrier.global.")) return AMDILIntrinsic::AMDIL_barrier_global;
   if (NameR.startswith("MDIL.barrier.local.")) return AMDILIntrinsic::AMDIL_barrier_local;
   if (NameR.startswith("MDIL.barrier.region.")) return AMDILIntrinsic::AMDIL_barrier_region;

   if (NameR.startswith("MDIL.fma.")) return AMDILIntrinsic::AMDIL_fma;
   if (NameR.startswith("MDIL.fma.rte.")) return AMDILIntrinsic::AMDIL_fma_rte;
   if (NameR.startswith("MDIL.fma.rtn.")) return AMDILIntrinsic::AMDIL_fma_rtn;
   if (NameR.startswith("MDIL.fma.rtp.")) return AMDILIntrinsic::AMDIL_fma_rtp;
   if (NameR.startswith("MDIL.fma.rtz.")) return AMDILIntrinsic::AMDIL_fma_rtz;

   and several other similar instances.

Out of curiosity, what is wrong about that? It looks ok to me.

-Chris

If the source being scanned has "llvm.AMDIL.barrier.global, it will match the first barrier test and return AMDIL_barrier, not AMDIL_barrier_global.

From: llvmdev-bounces@cs.uiuc.edu [mailto:llvmdev-bounces@cs.uiuc.edu] On Behalf Of Chris Lattner
Subject: Re: [LLVMdev] Tablegen bug???

Out of curiosity, what is wrong about that? It looks ok to me.

This:

> if (NameR.startswith("MDIL.barrier.")) return AMDILIntrinsic::AMDIL_barrier;

prevents the three following tests:

> if (NameR.startswith("MDIL.barrier.global.")) return AMDILIntrinsic::AMDIL_barrier_global;
> if (NameR.startswith("MDIL.barrier.local.")) return AMDILIntrinsic::AMDIL_barrier_local;
> if (NameR.startswith("MDIL.barrier.region.")) return AMDILIntrinsic::AMDIL_barrier_region;

from ever matching. The order needs to be changed so the common substring is checked last.

- Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.

Yes that definitely sounds like a bug, no intrinsically in mainline are a prefix if another one, or we are getting lucky.

-Chris

Was a fix for this ever applied to trunk?