similar to: [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

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

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

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:

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 // --

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

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

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

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

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

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

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

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

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,

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

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

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

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

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

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