[PATCH] Move X86DisassemblerDecoderCommon.h to public includes

Craig Topper craig.topper at gmail.com
Thu Dec 26 12:28:42 PST 2013


I think it's really only used by tablegen because of this macroized struct
definition. Seems like since the majority of the struct is in a macro as it
is it might make more sense to just give tablegen its own full struct
definition.

struct InstructionSpecifier {
  uint8_t modifierType;
  uint8_t modifierBase;

  /* The macro below must be defined wherever this file is included. */
  INSTRUCTION_SPECIFIER_FIELDS
};


On Thu, Dec 26, 2013 at 1:56 PM, Chandler Carruth <chandlerc at google.com>wrote:

>
> On Thu, Dec 26, 2013 at 1:14 PM, Reid Kleckner <rnk at google.com> wrote:
>
>>   I don't think moving to include/llvm/TableGen is the right way to go.
>>  It's not like the X86 disassembler links against a tablegen library.  The
>> only correct layering without adding new libraries is moving it to
>> include/llvm/Support, since both llvm-tblgen and the x86 target link
>> against Support.  I don't really like that arrangement, but we already have
>> these kind of enums-and-types-only headers like ELF.h and COFF.h in Support.
>
>
> My question is -- why does *tablegen* need this header, rather than it
> simply generating code that uses the header? I suspect the real problem is
> that the header contains information which should really be in a .td file
> and thus an input to the tablegen backend.
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>


-- 
~Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131226/2a2e997b/attachment.html>


More information about the llvm-commits mailing list