search for: inputargs

...oes anyone have any advice on how I could make a single object that would do this? Other relevant info: I want to use the pdata() function, and I have all the phenotype data available as csv files. Here is what I have in regards to the expression data: library(affy) library(arrayQualityMetrics) inputargs <- commandArgs(TRUE) print(inputargs) sessionInfo() strInputAccession <- inputargs[1] strBaseDir <- inputargs[2] processedDir <- paste(strBaseDir,strInputAccession,"PROCESSED/DEFAULT",sep="/") qcDir <- paste(strBaseDir,strInputAccession,"QC",sep="...

> what does "refuses to compile" mean? I.e. what error do you get? > Specifically I get this message when compiling with the default -mattr: Call result #2 has unhandled type i32 UNREACHABLE executed at CallingConvLower.cpp:162! 0 llc 0x0000000100a1e115 PrintStackTrace(void*) + 38 1 llc 0x0000000100a1e6d0 SignalHandler(int) + 254 2

Hi Josef, > Okay, I've done a lot more testing and I now have a .bc file that compiles for x86, sparc, mips but refuses to compile for the mblaze and powerPC backends because of the calling convention. Is there anyone that would know how to fix the microblaze calling convention or point me in the right direction on how to fix it? what does "refuses to compile" mean? I.e. what

On Wednesday 04 Apr 2012 12:41:49 Patrik Hägglund H wrote: > Hi Tim, > > > So I've come to the conclusion that the real flaw is LLVM > > not exposing enough information to the target-dependent > > backend code for it to do the right thing. > > We also had this problem. You might find this patch useful as a starting > point:

...uld do this? Other relevant info: I want to use the pdata() >> function, and I have all the phenotype data available as csv files. Here >> is >> what I have in regards to the expression data: >> >> library(affy) >> library(arrayQualityMetrics) >> >> inputargs<- commandArgs(TRUE) >> print(inputargs) >> sessionInfo() >> >> strInputAccession<- inputargs[1] >> strBaseDir<- inputargs[2] >> >> processedDir<- >> paste(strBaseDir,**strInputAccession,"PROCESSED/**DEFAULT",sep="/") &g...

Hello, I am working on a backend for a custom ISA that is somewhat similar to the MicroBlaze ISA so I've decided to use that as a starting point. I am trying to compile a custom ray tracer (lots of floating point) and the llvm-g++ frontend generates an fneg instruction which is not supported by the MBlaze backend in the 2.8 release. I added code to emit an fneg assembly instruction and now

> > what does "refuses to compile" mean? I.e. what error do you get? > Specifically I get this message when compiling with the default -mattr: Call result #2 has unhandled type i32 UNREACHABLE executed at CallingConvLower.cpp:162! 0 llc 0x0000000100a1e115 PrintStackTrace(void*) + 38 1 llc 0x0000000100a1e6d0 SignalHandler(int) + 254 2

Hello, Am 15.03.2011 um 19:27 schrieb Josef Spjut: > Does anyone know what common causes of "UNREACHABLE executed!" > messages are and what this message in particular means? The full > error message is the following: > > UNREACHABLE executed! > 0 llc 0x0000000100936ae2 PrintStackTrace(void*) + 34 > 1 llc 0x0000000100937603

Hi, (Forward from cfe-commits, where some backend stuff has come up). This is an issue I've been thinking about quite a bit recently, and I agree that the biggest problem is the one below: > * The big thing still missing here is that there is no logic to check how many VFP registers have already been used for other arguments. When deciding whether to pass an argument as a homogeneous

Hi Tim, > So I've come to the conclusion that the real flaw is LLVM > not exposing enough information to the target-dependent > backend code for it to do the right thing. We also had this problem. You might find this patch useful as a starting point: http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-March/048266.html /Patrik Hägglund -----Original Message----- From: llvmdev-bounces

LLVM code base seems to be full of base/interface classes, which have methods like virtual SDValue LowerCall(SDValue Chain, SDValue Callee, CallingConv::ID CallConv, bool isVarArg, bool &isTailCall, const SmallVectorImpl<ISD::OutputArg> &Outs, const SmallVectorImpl<SDValue> &OutVals, const

On Wednesday 04 Apr 2012 13:27:07 Tim Northover wrote: > Putting that information in the InputArg/OutputArg and incorporating it the > CCAssignFn interface allows a more straightforward implementation in the > targets, in my view (for both our uses). It's also information that's > readily available when InputArg/OutputArgs are being constructed. In your > case: > >

On Apr 23, 2009, at 8:09 PM, Dan Gohman wrote: > Attached is a patch which significantly reworks how calls, incoming > arguments, and outgoing return values are lowered. It's a major > change, > affecting all targets, so I'm looking for feedback on the approach. > > The goal of the patch is to eliminate a bunch of awkward code, > eliminate some unnecessary

On Thu, Aug 8, 2013 at 3:59 PM, Tom Stellard <tom at stellard.net> wrote: > On Thu, Aug 08, 2013 at 01:51:53PM -0400, Justin Holewinski wrote: > > Good to know, thanks! > > > > Currently I'm just not declaring an i8 register class since we only have > > load/store/convert available for that type. This works fine for most > uses, > > but becomes a

On Thu, Aug 08, 2013 at 04:25:25PM -0400, Justin Holewinski wrote: > On Thu, Aug 8, 2013 at 3:59 PM, Tom Stellard <tom at stellard.net> wrote: > > > On Thu, Aug 08, 2013 at 01:51:53PM -0400, Justin Holewinski wrote: > > > Good to know, thanks! > > > > > > Currently I'm just not declaring an i8 register class since we only have > > >

It's been on the back-burner for awhile. I'll clean it up and post it for review soon. On Tue, Aug 27, 2013 at 7:48 PM, Tom Stellard <tom at stellard.net> wrote: > On Thu, Aug 08, 2013 at 04:25:25PM -0400, Justin Holewinski wrote: > > On Thu, Aug 8, 2013 at 3:59 PM, Tom Stellard <tom at stellard.net> wrote: > > > > > On Thu, Aug 08, 2013 at

Hello, I'm having trouble getting the function prototype of an ExternalSymbolSDNode inside TargetLowering::LowerCall(), this way i could get the original argument sizes before they're legalized into smaller parts. I need this sort of information because depending on the originaltypes of the arguments i need to use some regs or others. I tried using the isSplit flag in ArgFlagsTy but it

A change has just been committed that changes the interface for TargetLowering::LowerCallTo and TargetLowering::LowerCall. Instead of passing a mess of parameters to these functions, a new structure has been created that encapsulates these parameters. The motivation is that additional fields can be added to this structure (with appropriate changes to SelectionDAGBuilder for populating the new

On Fri, Sep 21, 2012 at 5:38 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Jun, I can reproduce this with "llc -mtriple=i386-linux-gnu", the crash > being > > Call result #3 has unhandled type i32 > UNREACHABLE executed at > /home/duncan/LLVM/llvm/lib/CodeGen/CallingConvLower.cpp:165! > ... >

Hi Job, > This issue is basically that I cannot find a way to distinguish two i16 > arguments from one i32. Is there a way to do this in LLVM? Preferably using > tablegen, of course:-) I think the property you want is "isSplit" (or, from the TableGen side CCIfSplit). This gets applied to the first of those i16s that are produced. Unfortunately I can't think of much you