search for: inputarg

...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=&quot...

...lc 0x000000010002d3d3 raise + 27 5 llc 0x000000010002d3e3 abort + 14 6 llc 0x0000000100a0a9e3 llvm::report_fatal_error(llvm::Twine const&) + 0 7 llc 0x00000001005df5f3 llvm::CCState::AnalyzeCallResult(llvm::SmallVectorImpl<llvm::ISD::InputArg> const&, bool (*)(unsigned int, llvm::MVT, llvm::MVT, llvm::CCValAssign::LocInfo, llvm::ISD::ArgFlagsTy, llvm::CCState&)) + 261 8 llc 0x00000001000b62ac llvm::MBlazeTargetLowering::LowerCallResult(llvm::SDValue, llvm::SDValue, llvm::CallingConv::ID, bool, llvm::SmallVector...

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

...CCCustom functions to access its special information (or, possibly, a CCIf with a cast). CCCustom<"TellCCStateAboutArg">, [...] CCIf<"cast<MyCCState>(State).isPointerArg()">, CCAssignToReg<[P1, P2]>>, 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: CCIf<"SourceTy-&...

...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="/") &...

...sigtramp + 2102528416 4 llc 0x0000000100936aa6 abort + 22 5 llc 0x000000010091551d llvm::llvm_unreachable_internal(char const*, char const*, unsigned int) + 381 6 llc 0x000000010058100e llvm::CCState::AnalyzeCallResult(llvm::SmallVectorImpl<llvm::ISD::InputArg> const&, bool (*)(unsigned int, llvm::EVT, llvm::EVT, llvm::CCValAssign::LocInfo, llvm::ISD::ArgFlagsTy, llvm::CCState&)) + 158 7 llc 0x000000010007319c llvm::TraxTargetLowering::LowerCallResult(llvm::SDValue, llvm::SDValue, llvm::CallingConv::ID, bool, llvm::SmallVectorIm...

...lc 0x000000010002d3d3 raise + 27 5 llc 0x000000010002d3e3 abort + 14 6 llc 0x0000000100a0a9e3 llvm::report_fatal_error(llvm::Twine const&) + 0 7 llc 0x00000001005df5f3 llvm::CCState::AnalyzeCallResult(llvm::SmallVectorImpl<llvm::ISD::InputArg> const&, bool (*)(unsigned int, llvm::MVT, llvm::MVT, llvm::CCValAssign::LocInfo, llvm::ISD::ArgFlagsTy, llvm::CCState&)) + 261 8 llc 0x00000001000b62ac llvm::MBlazeTargetLowering::LowerCallResult(llvm::SDValue, llvm::SDValue, llvm::CallingConv::ID, bool, llvm::SmallVector...

...0000000100936aa6 abort + 22 > 5 llc 0x000000010091551d > llvm::llvm_unreachable_internal(char const*, char const*, unsigned > int) + 381 > 6 llc 0x000000010058100e > llvm > ::CCState > ::AnalyzeCallResult(llvm::SmallVectorImpl<llvm::ISD::InputArg> > const&, bool (*)(unsigned int, llvm::EVT, llvm::EVT, > llvm::CCValAssign::LocInfo, llvm::ISD::ArgFlagsTy, llvm::CCState&)) > + 158 > 7 llc 0x000000010007319c > llvm::TraxTargetLowering::LowerCallResult(llvm::SDValue, > llvm::SDValue, llvm::Ca...

...irst case there's no indication of where a composite type begins and ends. The latter could be bludgeoned to mean "this is an HFA, put it in VFP regs", but it would be unspeakably ugly. I believe that if the LLVM original Type* pointer is exposed to TargetLowering (perhaps as part of InputArg/OutputArg), then LLVM itself can decide what to do with both Small Structures and HFAs in a sane manner: writing a front-end which adheres to the PCS would be much easier for any source language. The worry is the apparent layering violation by passing a Type* further down. But I'd argue that th...

...irst case there's no indication of where a composite type begins and ends. The latter could be bludgeoned to mean "this is an HFA, put it in VFP regs", but it would be unspeakably ugly. I believe that if the LLVM original Type* pointer is exposed to TargetLowering (perhaps as part of InputArg/OutputArg), then LLVM itself can decide what to do with both Small Structures and HFAs in a sane manner: writing a front-end which adheres to the PCS would be much easier for any source language. The worry is the apparent layering violation by passing a Type* further down. But I'd argue that th...

...LowerCall(SDValue Chain, SDValue Callee, CallingConv::ID CallConv, bool isVarArg, bool &isTailCall, const SmallVectorImpl<ISD::OutputArg> &Outs, const SmallVectorImpl<SDValue> &OutVals, const SmallVectorImpl<ISD::InputArg> &Ins, DebugLoc dl, SelectionDAG &DAG, SmallVectorImpl<SDValue> &InVals) const { assert(0 && "Not Implemented"); return SDValue(); // this is here to silence compiler errors } Why are these not pure virtual met...

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

...with the other. This would be a nice general solution instead of something specific to calls. Unrelated, but it would also be nice to make INLINEASM nodes have their own SDNode subclass someday instead of a bunch of magically indexed operands. Similar to Nate's recent shuffle change. InputArg/OutputArg should probably contain an ArgFlagsTy instead of inherit from it. I like the various -'s of random call lowering stuff from the .td files, this is great! -Chris

...a way to avoid that. I've been trying the approach of declaring an i8 register class and promoting the ops, but as Jim points out, this currently doesn't work in SelectionDAG. All I really need is a way to determine if the original type is i8, so I'm trying to thread this through ISD::InputArg. Doesn't seem to be too invasive, I'm putting together a patch now. > > It would be really nice if it were possible to mark a type as load/store > only, but I'm not sure how to begin implementing that. > > -Tom > > > > On Thu, Aug 8, 2013 at 1:37 PM, Jim Gr...

...I've been trying the approach of > declaring an i8 register class and promoting the ops, but as Jim points > out, this currently doesn't work in SelectionDAG. All I really need is a > way to determine if the original type is i8, so I'm trying to thread this > through ISD::InputArg. Doesn't seem to be too invasive, I'm putting > together a patch now. > Hi Justin, Were you able to finish writing this patch? I'm working on this problem now, and I am curious what your solution is. Thanks, Tom > > > > > It would be really nice if it were p...

...ng the approach of > > declaring an i8 register class and promoting the ops, but as Jim points > > out, this currently doesn't work in SelectionDAG. All I really need is a > > way to determine if the original type is i8, so I'm trying to thread this > > through ISD::InputArg. Doesn't seem to be too invasive, I'm putting > > together a patch now. > > > > Hi Justin, > > Were you able to finish writing this patch? I'm working on this problem > now, and I am curious what your solution is. > > Thanks, > Tom > > > &g...

...t flag in ArgFlagsTy but it only marks the first splitted argument piece, so it's not possible to know into how many pieces is the argument divided. So my question is how would i get this information or if it's possible to add for example the original size of the argument into the OutputArg/InputArg structs or the piece number if the argument is splitted. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110402/24d365ef/attachment.html>

...<SDValue> &InVals) const { SelectionDAG &DAG = CLI.DAG; DebugLoc &dl = CLI.DL; SmallVector<ISD::OutputArg, 32> &Outs = CLI.Outs; SmallVector<SDValue, 32> &OutVals = CLI.OutVals; SmallVector<ISD::InputArg, 32> &Ins = CLI.Ins; SDValue Chain = CLI.Chain; SDValue Callee = CLI.Callee; bool &isTailCall = CLI.IsTailCall; CallingConv::ID CallConv = CLI.CallConv; bool doesNotRet...

...e 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! > ... > llvm::CCState::AnalyzeCallResult(llvm::SmallVectorImpl<llvm::ISD::InputArg> > const&, bool (*)(unsigned int, llvm::MVT, llvm::MVT, > llvm::CCValAssign::LocInfo, llvm::ISD::ArgFlagsTy, llvm::CCState&)) + 284 > ... > > Please open a bug report. > thanks for clearing my doubt on the bug. but how can i open a bug report? simply report the bug in...

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