Displaying 20 results from an estimated 1000 matches similar to: "[LLVMdev] Disabling ExecutionEngine tests for Hexagon"
2013 Mar 11
0
[LLVMdev] Disabling ExecutionEngine tests for Hexagon
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
2013 Mar 12
2
[LLVMdev] Disabling ExecutionEngine tests for Hexagon
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
2013 Mar 13
2
[LLVMdev] Disabling ExecutionEngine tests for Hexagon
>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
2013 Mar 13
0
[LLVMdev] Disabling ExecutionEngine tests for Hexagon
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
2012 Aug 20
2
[LLVMdev] TableGen related question for the Hexagon backend
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
2012 Aug 21
1
[LLVMdev] TableGen related question for the Hexagon backend
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
2012 Aug 28
4
[LLVMdev] TableGen backend support to express relations between instruction
Hi Jakob,
Here is the first draft of the patch to add TableGen backend support for the
instruction mapping tables. Please take a look and let me know your
suggestions. As of now, I create one mapping table per relation which
results into a long .inc file. So, I'm planning to combine everything into a
single table and will include APIs (one per relation) to query from this
table.
Thanks,
2012 Aug 20
0
[LLVMdev] TableGen related question for the Hexagon backend
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)
>
2012 Aug 20
2
[LLVMdev] TableGen related question for the Hexagon backend
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 -
2012 Aug 28
1
[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 { //
2012 Aug 28
0
[LLVMdev] TableGen backend support to express relations between instruction
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
2012 Aug 21
0
[LLVMdev] TableGen related question for the Hexagon backend
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
2013 Mar 12
0
[LLVMdev] Disabling ExecutionEngine tests for Hexagon
On 2013-03-12 1:28 AM, "Jyotsna Verma" <jverma at codeaurora.org> wrote:
>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
2012 Aug 01
3
[LLVMdev] TableGen related question for the Hexagon backend
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 :
2012 Aug 31
0
[LLVMdev] TableGen backend support to express relations between instruction
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
2012 Aug 02
0
[LLVMdev] TableGen related question for the Hexagon backend
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
2012 Aug 16
2
[LLVMdev] TableGen related question for the Hexagon backend
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
2012 Aug 17
2
[LLVMdev] TableGen related question for the Hexagon backend
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
2012 Aug 17
0
[LLVMdev] TableGen related question for the Hexagon backend
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
2013 May 03
1
[LLVMdev] buildbot failure in LLVM on llvm-ppc64-linux1
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