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, 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.
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("")) 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.


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

From: [] On Behalf Of Chris Lattner
Subject: Re: [LLVMdev] Tablegen bug???

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


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

prevents the three following tests:

> if (NameR.startswith("")) 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.


Was a fix for this ever applied to trunk?