similar to: [LLVMdev] [ARM] Bugs in decode / encode of PC-relative t2 LDR in the ARM backend

Hi, after perusing through llc -debug output and stepping through the ARMGenDAGIsel.inc in the debugger, I would greatly like some help in tracking down a failing match to a pattern I specified: First, here is a snippet of a successful match (done in ARM mode) ISEL: Starting pattern match on root node: 0x1e7adf0: i32,ch = load 0x1e4c030, 0x1e78210, 0x1e78310<LD4[ConstantPool]> [ID=10]

Hi, I have a question about the definitions of t2LDRSB and t2LDRSB_PRE in ARMInstrThumb2.td : I was aware that the definitions of target RegisterClass (outs) are different in t2LDRSB and t2LDRSB_PRE. While t2LDRSB uses rGPR, t2LDRSB_PRE uses GPR. I wonder if lr and pc are already prevented from being allocated in pre-indexing case, because of some register hint that is being enforced?

Dear All It is very kind of you to guide me. When I want to run this line, I see this error stat.obs <- apply(GS, 2, function(z) Hott2(t(DATA[which(z==1),]), cl)) Error in colSums(w * x) : 'x' must be an array of at least two dimensions cl <- as.factor(y) GS: a matrix with 0 or 1 GS: gene sets -> a data matrix with rows=genes, columns= gene sets, GS[i,j]=1 if gene i in

Dear R-users I've simulated a longitudinal multivariate normal data set from which I've simulated missing-patterns such as MCAR MAR and a simple kind of non-MAR. I've imputated the values so I now have 'complete' data sets. I'm trying to perform a T2-test as done in the multivariate case under th enormal assumption. Is there something I've to think about when performing

Hi, I want to do a 2 sample hotelling's test but i can't figure out how. When i type T2.test it says there is no such test and when i tried library(rrcov) it says there is no such program. Cheers. -- View this message in context: http://r.789695.n4.nabble.com/How-to-do-Hotelling-s-t2-test-tp4128748p4128748.html Sent from the R help mailing list archive at Nabble.com.

Hi all, I've got the following matrix : ? mat <- matrix(rnorm(700), ncol=5, dimnames=list( paste("f", c(1:140), sep="_"), c("A", "B", "C", "D", "E"))) I can see that currently most of the multivariate Hotelling T2 tests are limited for application on two groups/samples. I wud appreciate if someone can provide me a

I want to calculate the probability that a group will include a particular point using the squared Mahalanobis distance to the centroid. I understand that the squared Mahalanobis distance is distributed as chi-squared but that for a small number of random samples from a multivariate normal population the Hotellings T2 (T squared) distribution should be used. I cannot find a function for

Martin Storsjo wrote: > This is required in order to build using the built-in assembler > in clang. These patches break the gcc build (with "Error: bad instruction"). Documentation I've seen is contradictory on which order ({cond}{size} or {size}{cond}) is correct. If clang really does require the latter, then the arm2gnu.pl translation script will need to be updated

>> Do the ARM usages include allowing a single pseudo-instruction to expand >> to multiple real instructions? For example, a movw/movt pair? If so, I’m >> *very* opposed to that part. > > > Why? For people writing assembly manually, having pseudo instructions to > encapsulate common patterns is very useful. Would it be acceptable for this pseudo-instruction to

Hi David, > 8. Check that an error is issued when the constant pool would be placed too > far away I'd say this one is actually the most involved constraint but there don't actually seem to be any tests in the attached file for it. And I believe the directive Jim's referring to is ".ltorg". It's presumably going to have some interesting quirks of its own.

> > I was thinking that without the .ltorg directive the constant pool > > would go at the end of the section. > > > So where does the assembler place the constant pool(s) if that directive > isn't present? I was under the impression it was always required. >From my understanding it is not required. I see that GCC will place it at the end of the section. I don't

> I put the test in a separate file and forgot to attach it earlier. I've > attached it to this email. The ".space" directive could be very useful in making the test more manageable. Other than that I'd be wary of instructions that might be relaxed during object emission and suddenly make a load out of range. LLVM seems to do this for Bcc, pc-relative loads, ADR and B.

On Fri, Oct 25, 2013 at 1:33 PM, David Peixotto <dpeixott at codeaurora.org>wrote: > Both armasm and gnu as support an ldr pseudo instruction for loading > constants that lowers to either a mov, movn, or a pc-relative ldr from the > constant pool. It would be great if the llvm integrated assembler could > support this feature as well. > > For example, using gnu as to

> > I wrote the tests before I did the actual implementation and I thought > > I would be generating the relocations myself. The implementation > > turned out to be much simpler than I imagined and I was able to lean > > on the existing support for generating relocations and fixups. I > > expect all these relocations would be covered by other tests. > > >

Hi all. I'm investigating an issue with incorrect lldb's disassembly output. I have two bytes in question: 4e5f lldb (via the llvm's LLVMARMCodeGen) is providing the following mnemonics: ldr r6, #380, However the value for ldr is "an 8-bit value that is multiplied by 4 and added to the value of the PC to form the memory address" (via ARMARM), so that the correct

Hi David, In these examples, I don’t see the directive that indicates where the assembler should place the constant pool? -Jim On Nov 1, 2013, at 11:16 AM, David Peixotto <dpeixott at codeaurora.org> wrote: > In an earlier email[1] I proposed adding support for the ldr > pseud-instruction to the ARM integrated assembler. After some discussion the > overall consensus seemed to be

On 25 October 2013 22:35, Sean Silva <chisophugis at gmail.com> wrote: > I would like to see this features supported. > Hi Sean, I'm not opposing, I'm just saying that we'll need critical reasons for having a support that will introduce GCC-extensions blindly. > I have run into code in the wild that cannot be handled by the LLVM > toolchain due to this issue.

Hi Tim, > > 8. Check that an error is issued when the constant pool would be > > placed too far away > > I'd say this one is actually the most involved constraint but there don't > actually seem to be any tests in the attached file for it. I put the test in a separate file and forgot to attach it earlier. I've attached it to this email. I can't say how

So, it seems there are enough people on the plus side, I just wanted to make sure we evaluate all sides before taking a decision to add syntactic sugar to LLVM assembler. My main concern is still the same as earlier this year: the integrated assembler for ARM is still not complete, and the more extensions we add to the back-end, the harder it'll be to get it into production quality. That

Hi Amara, Thanks for your suggestions. I have made the changes you suggested and added a new test to check that we print an error when parsing a non-ldr mnemonic with an operand containing `=`. The updated patch is attached. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation > -----Original Message----- > From: Amara Emerson