similar to: [Hexagon] Failure to disassemble some new-value instructions

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

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

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: memw(##b) %0 = load i32* @a, align 4 %1 = load i32* @b, align 4 requires that the compiler emit the memory operations for

Hi, all I didn't get any response from swig for my question. see if I can get some help here Thanks ---------- Forwarded message ---------- From: charlie <charlie.xia.fdu@gmail.com> Date: Tue, Nov 4, 2008 at 1:55 PM Subject: SWIG with R and C++ STL To: swig-user@lists.sourceforge.net Hi all, I am new to SWIG. I encountered some problem when I try to SWIG to R some C++ modules. Here

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

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

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

I'm trying to apply a function defined in the VW R docs, that attemps to convert a data.table object to Vowpal Wabbit format. In the process i'm getting the error in printf mentioned in the subject. The original function is here: https://github.com/JohnLangford/vowpal_wabbit/blob/master/R/dt2vw.R Below there is a small example that reproduces the error. The function works great with

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

Wouldn't it make sense to have this in the man page? The 8192-byte limitation for 'fmt' is mentioned but not this one. Thanks, H. On 08/25/2015 02:08 AM, Prof Brian Ripley wrote: > From the sources: > > #define MAXNARGS 100 > /* ^^^ not entirely arbitrary, but strongly linked to > allowing %$1 to %$99 !*/ > > > > On 22/08/2015 04:21, Martin

Hello, I am trying to select the following headers from a data frame but when I try and run the command it executes halfway through and give me an error at V188 and V359. Temp <- data.frame(V4, V5, V6, V7, V8, V9, V10, V11, V12, V13, V14, V15, V16, V17, V18, V19, V20, V21, V22, V23, V24, V25, V26, V27, V28, V29, V30, V31, V32, V33, V34, V35, V36, V37, V38, V39, V40, V41, V42, V43, V44, V45,

Hi. I have a simple (I think) question My dataset have these variables: names(data) [1] "v1" "v2" "v3" "v4" "v5" "v6" "v7" "v8" "v9" "v10" "v11" "v12" "v13" "v14" "v15" "v16" "v17"

On 03/14/2013 12:51 PM, Anshuman Dasgupta wrote: > I wanted to give everybody a heads-up on upcoming commits for the > Hexagon backend. We will be removing support for older versions of the > Hexagon architecture - specifically Hexagon-v2 and Hexagon-v3. These are > no longer being used by compiler users. Matthew Curtis has committed the > first clang patch to remove driver support

I wanted to give everybody a heads-up on upcoming commits for the Hexagon backend. We will be removing support for older versions of the Hexagon architecture - specifically Hexagon-v2 and Hexagon-v3. These are no longer being used by compiler users. Matthew Curtis has committed the first clang patch to remove driver support for these versions. There will be follow-up patches on the LLVM side

Hello, Why do I get preceding "X." (that is a and X followed by a period) for negative numbers and an "X" for positive numbers when I read a csv file? Am I stuck with this? If so, how do I convert it to normal numbers? dat=read.csv(file_path) > dat [1] X0.0 X.0.240432350374 X0.355468069625 X.0.211469972378 X1.1812797415 X.0.227975150826

Dear List I have a fixed width file with variables of varying width. The help is pretty transparent for this feature, but I can't seem to figure out how I can make effective use of the package with my data. In my dataset, the first 80 columns are of width 1 followed by other variables with width larger than 1. I think the correct way to do this, by brute force, would be >

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