similar to: [LLVMdev] TableGen backend support to express relations between instruction

Hi Hal, I will try to explain the functionality using a simple example. Let's say that we have three formats for 'ADD' instruction and we want to relate them. ADD - non-predicated form ADD_pt : predicate true ADD_pf : predicate false We can define the relationship between the non-predicated instructions and their predicate formats as follows: def getPredOpcode : InstrMapping { //

Jyotsna, I hadn't been following this, so I apologize if this has already been provided, but can you give a quick example of how this functionality is used? Thanks in advance, Hal On Tue, 28 Aug 2012 13:01:17 -0500 "Jyotsna Verma" <jverma at codeaurora.org> wrote: > Hi Jakob, > > Here is the first draft of the patch to add TableGen backend support > for the

You're right. I can have use RowFields for that purpose. Thanks, Jyotsna -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum. -----Original Message----- From: Jakob Stoklund Olesen [mailto:stoklund at 2pi.dk] Sent: Monday, August 20, 2012 3:42 PM To: Jyotsna Verma Cc: 'Tony Linthicum'; llvmdev at cs.uiuc.edu Subject: Re: TableGen related question for the Hexagon

Hi Jacob, Your suggestion worked for the simple relations between instructions as you've included in your example. With one small change, I am able to represent more complex relations as well. In the Hexagon backend, a predicated instruction can translate into another form called 'predicate new'. So, in our example of 'ADD', we can have another transformation like this -

Hi Jacob, Thanks for the suggestions. I have a few questions here. > You are on to something here, but you don't need to define a 'Relations' class > on top of the tablegen records. They are already relations, you just need the > proper query language to match the instructions you want. Are you saying that the mechanism is already present which allows us to relate

Hi Everyone, After some more thoughts to the Jacob's suggestion of using multiclasses for Opcode mapping, this is what I have come up with. Please take a look at the design below and let me know if you have any suggestions/questions. I have tried to keep the design target independent so that other targets could benefit from it. 1) The idea is to add 3 new classes into

On Aug 20, 2012, at 1:32 PM, "Jyotsna Verma" <jverma at codeaurora.org> wrote: > In the Hexagon backend, a predicated instruction can translate into another > form called 'predicate new'. So, in our example of 'ADD', we can have > another transformation like this - > > ADD--- ---> ADDtrue -----> ADDtru_new (predicate new form of true) >

On Aug 17, 2012, at 10:02 AM, "Jyotsna Verma" <jverma at codeaurora.org> wrote: > > Hi Jacob, > > Thanks for the suggestions. I have a few questions here. > >> You are on to something here, but you don't need to define a 'Relations' > class >> on top of the tablegen records. They are already relations, you just need > the >>

On Aug 16, 2012, at 1:39 PM, Jyotsna Verma <jverma at codeaurora.org> wrote: > Hi Everyone, > > After some more thoughts to the Jacob's suggestion of using multiclasses for > Opcode mapping, this is what I have come up with. Please take a look at the > design below and let me know if you have any suggestions/questions. Hi Jyotsna, You are on to something here, but you

Jakob, One more question. You had suggested 'ValueCols' as of type list<list<string> >. Does the TableGen know how to extract it? It appears to me that we may have to add support for that. Thanks, Jyotsna -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at

Hi Jakob, Did you get a chance to look at the patch? Thanks, Jyotsna -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Jyotsna Verma Sent: Tuesday, August 28, 2012 1:01 PM To: 'Jakob Stoklund Olesen' Cc: llvmdev at

On Aug 20, 2012, at 9:22 PM, Jyotsna Verma <jverma at codeaurora.org> wrote: > Jakob, > > One more question. You had suggested 'ValueCols' as of type > list<list<string> >. Does the TableGen know how to extract it? It appears to > me that we may have to add support for that. You just start from getValueAsListInit() and go from there. /jakob

Hi Jyotsna, Currently there's a preprocessor trick that prevents llvm/unittests/ExecutionEngine/MCJIT tests from running on architectures and operating systems that are known to fail. Specifically, check out the functions OSSupportsMCJIT() and ArchSupportsMCJIT() functions in unittests/ExecutionEngine/MCJIT/MCJITTestBase.h, and the corresponding macro SKIP_UNSUPPORTED_PLATFORM that is used

Hi There, We want to disable all ExecutionEngine JIT/MCJIT tests (llvm/unittests/ExecutionEngine) for Hexagon. I have been looking into the test framework but haven't quite figured out how to turn them off. We cross compile Hexagon on X86 and are not interested in JIT support. Thanks, Jyotsna -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux

>Since MCJIT works on x86, please don't remove it from the supported >platforms list. One downside of using the macro trick is that the test names >are still printed even when they are disabled. It sounds like you need to >modify the macro to also check for the target triple as well... This was just a temporary change to see how it works. >There isn't anything in MCJIT as

On 2013-03-13 3:15 AM, "Jyotsna Verma" <jverma at codeaurora.org> wrote: > >I noticed "TARGET_HAS_JIT" flag in Makefile.config. Can I use this flag to >exclude MCJIT and JIT tests when not set? This will be a simpler change >than >modifying the macro. > >Thanks, >Jyotsna TARGET_HAS_JIT seems to be an autoconf thing (also, not really sure how it

Thanks Dan! The ArchSupportMCJIT() functions in unittests/ExecutionEngine/MCJIT/MCJITTestBase.h uses "Host Triple" to check for compatibility. Since we cross-compile on X86, "Host Triple" for us will be "X86" which is a supported architecture. I tried removing it from the supported arch list but didn't see any effect. I was just wondering if these tests are

Hi, I'm looking for some suggestions on a problem related to the Hexagon backend. Hexagon architecture allows instructions in various formats. For example, we have 3 variations of the add instruction as defined below: ADDrr : r1 = add(r2, r3) --> add 2 32-bit registers ADDrr_p : if(p0) r1 = add(r2, r3) --> predicated version of ADDrr instruction, executed when p0 is true ADDrr_np :

On Aug 1, 2012, at 1:53 PM, Jyotsna Verma <jverma at codeaurora.org> wrote: > > Currently, we rely on switch tables to transform between formats. However, > we would like to have a different mechanism to represent these relationships > instead of switch tables. I am thinking of modeling these relations in > HexagonInstrInfo.td file and use TableGen to generate a table with

Hi All, I'm trying to reproduce a failure on llvm-ppc64-linux1 (http://lab.llvm.org:8011/builders/llvm-ppc64-linux1/builds/5382) and llvm-ppc64-linux2 builders caused by one of my patches yesterday. Some of the CodeGen/Hexagon tests failed to compile with stack dump problem. I tried to configure and build LLVM for PowerPC on my machine locally but don't see the failures. I had to remove