similar to: [LLVMdev] teaching FileCheck to handle variations in order

Displaying 20 results from an estimated 200 matches similar to: "[LLVMdev] teaching FileCheck to handle variations in order"

2012 Sep 07
1
[LLVMdev] teaching FileCheck to handle variations in order
On 9/7/2012 12:12 PM, Krzysztof Parzyszek wrote: > On 9/7/2012 7:20 AM, Matthew Curtis wrote: >> >> The attached patch implements one possible solution. It introduces a >> position stack and a couple of directives: >> >> * 'CHECK-PUSH:' pushes the current match position onto the stack. >> * 'CHECK-POP:' pops the top value off of the stack
2012 Sep 07
0
[LLVMdev] teaching FileCheck to handle variations in order
On 9/7/2012 7:20 AM, Matthew Curtis wrote: > > The attached patch implements one possible solution. It introduces a > position stack and a couple of directives: > > * 'CHECK-PUSH:' pushes the current match position onto the stack. > * 'CHECK-POP:' pops the top value off of the stack and uses it to set > the current match position. > > The above
2012 Sep 10
3
[LLVMdev] teaching FileCheck to handle variations in order
On 9/7/2012 4:08 PM, Chandler Carruth wrote: > On Fri, Sep 7, 2012 at 8:20 AM, Matthew Curtis <mcurtis at codeaurora.org > <mailto:mcurtis at codeaurora.org>> wrote: > > Hello all, > > For the hexagon target, we have a couple of tests that are failing > due to variations in the order of checked text. In these cases the > ordering is not directly
2012 Sep 07
0
[LLVMdev] teaching FileCheck to handle variations in order
On Fri, Sep 7, 2012 at 8:20 AM, Matthew Curtis <mcurtis at codeaurora.org>wrote: > Hello all, > > For the hexagon target, we have a couple of tests that are failing due to > variations in the order of checked text. In these cases the ordering is not > directly relevant to the functionality being tested. > > For example: > > ; CHECK: memw(##a) > ; CHECK:
2019 Jun 30
6
[hexagon][PowerPC] code regression (sub-optimal code) on LLVM 9 when generating hardware loops, and the "llvm.uadd" intrinsic.
Hi All, The following code : void hexagon2( int *a, int *res ) { int i = 100; while ( i-- ) { *res++ = *a++; } } gets compiled as a sub-optimal Software loop on LLVM 9.0 instead of a Hardware loop, whereas it was compiled as a Hardware Loop in LLVM 7.0. This is the final assembly code generated by LLVM 9.0 : .text .file "main.c" .globl hexagon2 // --
2012 Sep 10
0
[LLVMdev] teaching FileCheck to handle variations in order
My 2c: I think that ability to pattern match “out-of-order” in tests is critical. I currently have to disable instruction scheduling on several Hexagon tests in order to preserve “expected” order of patterns, which has nothing to do with actual correctness of the test… So if nothing else, scheduler is left untested for those cases. Needless to say, this feature must maintain status quo for all
2012 Sep 13
2
[LLVMdev] teaching FileCheck to handle variations in order
Just adding to the clamor for FileChecks ability to pattern match out-of-order (match for mere presence); Just in the last 2 weeks, I have come across at least a couple instances when I was unable to add small unit tests to the testsuite because of this deficiency in FileCheck. Also, I agree with Krzysztof about the lack of any real recurring overhead. Can this feature please be added to
2009 Aug 28
1
Calling C funtion from R help Needed
Hello Forum, I'm calling C function from R.It is a small sample trial program. The C function will accept a character and a integer and print them. It is printing some special character instead of input character. Below are the C function, Wrapper code ,R code and R output. Please help me in this issue Thank you in advance C function (Name : checkstr.c) #include<stdio.h> int
2016 Feb 01
2
[Hexagon] Failure to disassemble some new-value instructions
Dear list, I noticed that the Hexagon disassembler has issues with disassembling some firmwares I have. When tracing one of these problems, the handling of some new-value instructions in HexagonDisassembler::getSingleInstruction() turned out to be the cause, specifically this statement: [lines 384-386 in HexagonDisassembler.cpp in HEAD] else if (SubregBit) // Subreg bit should not be
2010 Jun 21
2
[LLVMdev] MC: Object file specific parsing
Hi Daniel, attached is a patch that pushes most of the object file specific parsing out of AsmParser and down into MachOAsmParser. This was done as a cleanup for the ELF work. I know that you're not happy with this approach, particularly the fact that as we add more object file formats and assembler dialects, it's going to cause a class explosion. But I was hoping that we could use this
2012 Apr 19
0
[LLVMdev] Target Dependent Hexagon Packetizer patch
Sure I will split it and put it in two patches. Give me few hours. I need to test those patches. Sirish On 4/19/2012 8:40 AM, Tom Stellard wrote: > On Wed, Apr 18, 2012 at 11:18:05PM -0500, Sirish Pande wrote: >> Hi, >> >> Here's a patch for Hexagon Packetizer for review. This patch does >> not yield any warnings. >> > Would it be possible to split this
2012 Sep 13
0
[LLVMdev] teaching FileCheck to handle variations in order
On Thu, Sep 13, 2012 at 1:14 PM, Pranav Bhandarkar <pranavb at codeaurora.org>wrote: > Just adding to the clamor for FileChecks ability to pattern match > out-of-order (match for mere presence); Just in the last 2 weeks, I have > come across at least a couple instances when I was unable to add small unit > tests to the testsuite because of this deficiency in FileCheck. Also, I
2019 Jul 01
0
[hexagon][PowerPC] code regression (sub-optimal code) on LLVM 9 when generating hardware loops, and the "llvm.uadd" intrinsic.
The Hexagon part is fixed in r364790. -- Krzysztof Parzyszek kparzysz at quicinc.com<mailto:kparzysz at quicinc.com> LLVM compiler development From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Joan Lluch via llvm-dev Sent: Sunday, June 30, 2019 2:04 PM To: llvm-dev <llvm-dev at lists.llvm.org> Subject: [EXT] [llvm-dev] [hexagon][PowerPC] code regression
2014 Apr 08
2
[LLVMdev] 3.4.1 Release Plans
On Tue, Apr 08, 2014 at 04:08:13PM +0400, Robert Khasanov wrote: > Hi Reid, > > Would you approve your patches r203146 and r202774 to be backported to > 3.4.1? They fix stability issues in x86 asm. > Hi Robert, I was able to merge r203146, but it used a c++11 feature: std::string::back() which I replaced with std::string::at(std::string::size() - 1). r202774 was not merged,
2011 Dec 05
0
[LLVMdev] RFC: Machine Instruction Bundle
On Dec 2, 2011, at 12:40 PM, Evan Cheng wrote: > There have been quite a bit of discussions about adding machine instruction bundle to support VLIW targets. I have been pondering what the right representation should be and what kind of impact it might have on the LLVM code generator. I believe I have a fairly good plan now and would like to share with the LLVM community. Let me add some
2013 Jan 31
2
[LLVMdev] std::string suffices for Init* argument?
Hi Jakob, How is `FieldName`, which is a std::string, being passed as the third argument to SetValue on line 1848 of TGParser.cpp, which is declared as being an Init*? The nearly identical (FIXME) codepath in ParseDeclaration immediately puts the string into a StringInit, which makes sense, but how on earth is the std::string being passed in? This is really freaking me out. -- Sean Silva
2013 Jan 31
0
[LLVMdev] std::string suffices for Init* argument?
On Jan 30, 2013, at 9:37 PM, Sean Silva <silvas at purdue.edu> wrote: > How is `FieldName`, which is a std::string, being passed as the third > argument to SetValue on line 1848 of TGParser.cpp, which is declared > as being an Init*? The nearly identical (FIXME) codepath in > ParseDeclaration immediately puts the string into a StringInit, which > makes sense, but how on earth
2017 May 27
6
Should we split llvm Support and ADT?
Changing a header file somewhere and having to spend 10 minutes waiting for a build leads to a lot of wasted developer time. The real culprit here is tablegen. Can we split support and ADT into two - the parts that tablegen depends on and the parts that it doesn't? >From what I can gather, Tablegen currently depends on these headers and all of their transitive dependencies. #include
2013 Jul 16
0
[LLVMdev] [PATCH 2/2] X86: infer immediate forms of bit-test instructions
The instruction mnemonics for the immediate forms of bit-test instructions including bt, btr and bts, btc do not work. llvm-mc barfs with: error: ambiguous instructions require an explicit suffix This is highly user-unfriendly, since we can easily infer what the user meant by inspecting $imm and translating the instruction appropriately. Do it exactly as the Intel manual describes. Note that
2017 May 29
3
Should we split llvm Support and ADT?
On Mon, May 29, 2017 at 9:25 AM Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Sun, May 28, 2017 at 8:54 PM Mehdi AMINI via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> 2017-05-26 17:47 GMT-07:00 Zachary Turner via llvm-dev < >> llvm-dev at lists.llvm.org>: >> >>> Changing a header file somewhere and having to