> All of the tablegen backends work this way. As you mentioned, > there are no target-specific tablegen backends at present. > > The underlying observation here is that features are never > fundamentally "specific for a target". For example, a mapping > between vector opcodes and associated scalar opcodes could > reasonably be made on many architectures. Even > load-balancing between functional units on a processor is a > target-independent concept, with details like the number and > nature of the functional units being target-dependent.Sorry to be such a pest, but I am still trying to understand the usage model for tablegen. Are you saying it is not a good idea to write a tablegen backend for something very specific to a target? The examples I gave happen to be applicable to many targets. But the usage depends on AN implementation of codegen for a target, no? I mean, I could choose to put the related scalar instruction in a field with a specific name in the myInst class in the .td file, and would want to populate a data structure with a specific name in my C++ code. The tablegen backend should "know" the names of both the field in the .td file and the name of the data structure. How can I make this generic? Thanks, Manjunath
On Jun 9, 2009, at 1:16 PM, Manjunath Kudlur wrote:>> All of the tablegen backends work this way. As you mentioned, >> >> there are no target-specific tablegen backends at present. >> >> >> >> The underlying observation here is that features are never >> >> fundamentally "specific for a target". For example, a mapping >> >> between vector opcodes and associated scalar opcodes could >> >> reasonably be made on many architectures. Even >> >> load-balancing between functional units on a processor is a >> >> target-independent concept, with details like the number and >> >> nature of the functional units being target-dependent. >> > > Sorry to be such a pest, but I am still trying to understand the usage > model for tablegen. Are you saying it is not a good idea to write a > tablegen backend for something very specific to a target?The underlying observation here is that features are never fundamentally "specific for a target".> The examples > I gave happen to be applicable to many targets. But the usage depends > on AN implementation of codegen for a target, no? I mean, I could > choose to put the related scalar instruction in a field with a > specific name in the myInst class in the .td file, and would want to > populate a data structure with a specific name in my C++ code. The > tablegen backend should "know" the names of both the field in the .td > file and the name of the data structure. How can I make this generic?It's hard to say without knowing more details, but in general the way to do this is to make the data-types used in your C++ code target-independent. Obviously the actual data would be target-dependent. Then the code that uses the data structures and the tablegen backend could both be target-independent. In general, when features are designed in this way, it is easier to reuse the code for new targets. Dan
Hi all, Greetings. I'm a Ph.D. student in UIUC. Now I'm working on SAFECode, a research compiler based on LLVM which insert necessary runtime checks to guarantee memory-safety of programs. SAFECode needs to insert checks into the programs (say, please check this load instruction for me). Currently SAFECode inserts these checks as normal call instructions. It would be great that LLVM can treat them as first-class intrinsics (like "llvm.ctz"), which have additional semantics and could be lowered as ordinary function calls in subsequent passes. This would be very useful because 1) It simplifies the analysis logic 2) LLVM can apply out-of-box compiler optimization technique way more easily on these programs (for example, SAFECode has special hacks to teach the LICM pass understand these runtime checks) 3) It completely avoid the naming conflicts between the tool and the program. Based on my observation, there are a number of research tools might have the same requirement above. For instance, Automatic Pool Allocation(PLDI'05), KLEE(OSDI'08) and SoftBound(PLDI'09) all insert special intrinsics into programs to perform domain-specific tasks. Having pluggable, first-class intrinsics would simplify the tasks a lot. I'm glad to dig in and implement it if you guys are interested. It seems to me that simply making llvm::CallInst inheritable would be enough. Comments and suggestions are highly appreciated. Thanks. Haohui