similar to: RFC: general machine-parsable backend for TableGen (e.g. JSON)

Hi Simon, that makes sense to me. Please add me on any reviews when you're done. Cheers, Nicolai On 23.04.2018 14:08, Simon Tatham via llvm-dev wrote: > Hello llvm-dev, > > Would there be any interest in adding a back end to TableGen to produce output in a general-purpose but machine-parsable format? > > At the moment, TableGen has two kinds of output option. The -gen-foo

Hello llvm-devs, I'm currently starting to look at implementing compiler intrinsics for the Arm MVE vector instruction set. In a similar sort of style to the existing NEON intrinsics, this is going to involve describing the set of functions needed in Tablegen, and then processing that data into a header file and some bits and pieces to compile into clang (the list of builtins, data tables

> On Jul 21, 2020, at 14:30, Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > >> On Jul 21, 2020, at 11:50 AM, Jonathan Roelofs via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> A question of preference came up in https://reviews.llvm.org/D83588 <https://reviews.llvm.org/D83588>

A question of preference came up in https://reviews.llvm.org/D83588 <https://reviews.llvm.org/D83588> as to whether we ought to prefer emitting TableGen error messages with all of the information in a single diagnostic, or whether it makes sense to split things in an error+note style as seen in many clang diagnostics. TableGen doesn’t use a DiagnosticsEngine, so the concept of a fatal note

Hi, Jonathan. > On Jul 21, 2020, at 17:15, Jonathan Roelofs <jonathan_roelofs at apple.com> wrote: > > > >> On Jul 21, 2020, at 1:46 PM, Evandro Menezes <evandro.menezes at sifive.com <mailto:evandro.menezes at sifive.com>> wrote: >> >> >> >>> On Jul 21, 2020, at 14:30, Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org

Hello. Are you aware of any document (preferably academic paper) describing TableGen's typing of the following fields used to describe Instruction: pattern, ins and outs. I found a few pages on TableGen, but none of them talking about these fields: http://llvm.org/docs/TableGen/LangRef.html http://llvm.org/docs/TableGen/LangIntro.html

Hi all, I'm sure that the last thing that you want to think about is TableGen's guts, but I'm pursuing a course in bringing TableGen up to snuff with the rest of LLVM. Basically, I would like to introduce a "TGContext" class (by analogy with LLVMContext) to harbor a proper unique'd type system and BumpPtr allocate all of TableGen's data (RecTy's, Record's,

On Oct 3, 2012, at 7:07 PM, Sean Silva <silvas at purdue.edu> wrote: > Hi all, I'm sure that the last thing that you want to think about is > TableGen's guts, but I'm pursuing a course in bringing TableGen up to > snuff with the rest of LLVM. > > Basically, I would like to introduce a "TGContext" class (by analogy > with LLVMContext) to harbor a

On Oct 3, 2012, at 7:07 PM, Sean Silva <silvas at purdue.edu> wrote: > Hi all, I'm sure that the last thing that you want to think about is > TableGen's guts, but I'm pursuing a course in bringing TableGen up to > snuff with the rest of LLVM. > > Basically, I would like to introduce a "TGContext" class (by analogy > with LLVMContext) to harbor a

Hi folks, It took a while, but I finally have some bandwidth to look at this. I've been reading the two existing TableGen documents: http://llvm.org/docs/TableGenFundamentals.html http://llvm.org/docs/TableGen/LangRef.html the first is linked from the index, but LangRef is not (though it has some remains in the metadata). I'm wondering what's the relationship between them two. My

Why do you want to eliminate dynamic_cast and exceptions from tablegen? This is just a tool run over a few thousand lines of td files. You can't measure the difference in performance if you eliminate dynamic_cast and exceptions. I think it was a huge mistake to not use RTTI and exceptions in the compiler itself but I'm sure that old horse has been beaten to death long ago. But for

Thanks for the feedback! >> Does anybody have anything else they think should go into TGContext or >> any other responsibilities it should have? Or any feedback about the >> idea in general? > > All memory allocations should go into its bump pointer, RecordKeeper should as well. Any other global state that exist should also. Sounds good. >> I'm also hoping

Why not just run the c preprocessor before running tablegen? Micah > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Jeroen Dobbelaere > Sent: Wednesday, August 07, 2013 1:33 AM > To: llvmdev at cs.uiuc.edu > Subject: [LLVMdev] tablegen question > > Hi, > > I am trying to make my tablegen

Hi, I am trying to make my tablegen files more flexible and for that I would like to have a name that in the end will be replaced with a type. If tablegen would support c preprocssing, I would do it like this: --- #define myBaseType i32 ... def imm32 : Operand<myBaseType>; def immZExt10 : ImmLeaf<myBaseType, [{return isUInt<10>(Imm);}]>; ... --- Is there a way to achieve

It won't cause a negative effect, go for it! Dynamic_cast is realllly slow compared to dyn_cast, it is worth the memory. -Chris On Oct 3, 2012, at 9:39 PM, Sean Silva <silvas at purdue.edu> wrote: > Thanks for the feedback! > >>> Does anybody have anything else they think should go into TGContext or >>> any other responsibilities it should have? Or any

On 08/22/2017 03:59 AM, Alex Bradbury via llvm-dev wrote: > On 21 August 2017 at 13:23, Martin J. O'Riordan via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> But there is a downside. >> >> For each of the above I also have variations that are a result of different >> processor and ISA versions, and because of this I have to use >> ‘multiclass/defm’

On Apr 15, 2009, at 11:15 AM, Villmow, Micah wrote: > I still think there is a bug somewhere, but not sure where yet. > This is what is generated in intrinsic.gen: > case Intrinsic::opencl_math_fdistance: // > llvm.opencl.math.fdistance > ResultTy = Type::FloatTy; > ArgTys.push_back(Tys[0]); > ArgTys.push_back(Tys[0]); > break; OK. That looks right to me.

> On Jul 22, 2020, at 18:09, Jonathan Roelofs <jonathan_roelofs at apple.com> wrote: > > > >> On Jul 22, 2020, at 4:31 PM, Evandro Menezes <evandro.menezes at sifive.com <mailto:evandro.menezes at sifive.com>> wrote: >>> Sure, let’s talk about what that end goal should be! Can you give some other examples of where these inconsistencies could be

I'd like to store a tablegen generated enumeration in a record field/value. Clearly this enumeration isn't available yet so it seems that a code fragment should be the escape mechanism I need. Looking at the other backends for examples, I see things like [{ return Imm >= 0 && Imm < 64; }] // promising code Requires = [{ {} }];

On 08/23/2017 11:35 AM, Jakob Stoklund Olesen wrote: > >> On Aug 22, 2017, at 14:15, Hal Finkel via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> For situations well beyond TableGen's current language capabilities, >> we have a decision to make. We can continue extending TableGen until >> it can