similar to: [LLVMdev] a target must have floating point support?

Hi, I tried out the new soft-float support from the mainline. Overall, it looks very nice and pretty clean. It is now extremely easy to add the soft-float support for your target. Just do not call addRegisterClass() for your FP types and they will be expanded into libcalls. But there are several minor things that would be still nice to have: a) It is not possible to express that: - f32 and

On Wed, 20 Dec 2006, Roman Levenstein wrote: > Overall, it looks very nice and pretty clean. It is now extremely easy > to add the soft-float support for your target. Just do not call > addRegisterClass() for your FP types and they will be expanded into > libcalls. Great. > a) It is not possible to express that: > - f32 and f64 are both illegal and therefore are mapped to

Does anybody know if there is some tool to convert from WHIRL to LLVM? maybe some project under development? a similar project? Thanks > > --- Duraid Madina <duraid at octopus.com.au> wrote: > > Date: Fri, 18 Mar 2005 12:45:54 +0900 > > From: Duraid Madina <duraid at octopus.com.au> > > To: ahs3 at fc.hp.com, LLVM Developers Mailing List <llvmdev at

I am trying to add an call to computeRegisterProperties in the ARM target. The problem is that, after adding it, llc fails with Assertion `isTypeLegal(MVT::f64) && "Target does not support FP?"' failed The assert is at TargetLowering.cpp:138. Why is FP required? Most ARMs don't have an FPU. Should I add a fake register class for MVT::f64? Thanks, Rafael

On Thu, 2004-12-30 at 11:14, Francisco Puentes wrote: > Hi, everybody: > Hi Francisco > > I am a beginner with LLVM, in fact today was the first day that I use it. Welcome! > > I have several questions about LLVM: If you haven't already, a good place to start is the Getting Started Guide, at http://llvm.cs.uiuc.edu/docs/GettingStarted.html > Can I use LLVM to

On Mon, Aug 5, 2013 at 2:25 PM, Tom Stellard <tom at stellard.net> wrote: > On Mon, Aug 05, 2013 at 02:09:58PM -0400, Francois Pichet wrote: > > On my target store/load of f32 or i32 are equivalents. > > Previously I had duplicate instructions def in .td to map f32 and i32 to > > the same opcode. > > > > I deleted all that and I instead tried a new approach

I'm having some troubles implementing vector support to our custom backend It seems that llvm cannot emulate shuffle with extracts, inserts and builds? I've enabled vector registers with addRegisterClass(MVT::v2i32, TCE::V2I32RegsRegisterClass); addRegisterClass(MVT::v2f32, TCE::V2F32RegsRegisterClass); and created patterns for most vector instructions, including insert, extract and

> >> d) Would it be possible with current implementation of soft-float > >> support to map f32/f64 to integer types smaller than i32, e.g. to > > >> i16? > >> I have the impression that it is not necessarily the case, since > it would require that f64 is split into 4 parts. > > > > Yes, this should be fine. > > > >> This

Hi Vasanth, Can you be a little more precise about what you mean by "dynamic optimization"? In one sense, neither LLVM nor Pin are dynamic optimization tools per se - LLVM is more of a compiler(-building) suite while Pin is an instrumentation toolkit. > 1. I should be able to run all the Spec 2000 and Spec 95 floating point > and integer benchmarks. LLVM will do this - if it

Hi Roman, > True. I'm working on the version of the linear scan based on Wimmer's > thesis. It supports live range splitting. I'd like to compare it with > yours. Do you have any good examples of those fairly large functions > that are just flat sequences of instructions, anywhere from 100 to > 10000+ in size??? You can find a couple attached to bug #1512, but I'm

On my target store/load of f32 or i32 are equivalents. Previously I had duplicate instructions def in .td to map f32 and i32 to the same opcode. I deleted all that and I instead tried a new approach (to simplify things) : setOperationAction(ISD::STORE, MVT::f32, Promote); AddPromotedToType(ISD::STORE, MVT::f32, MVT::i32); setOperationAction(ISD::LOAD, MVT::f32, Promote);

On Dec 20, 2006, at 2:06 PM, Roman Levenstein wrote: >> >> This will probably require a slightly more extensive patch to >> legalizer. The current mechanism assumes either 1->1 or 1->2 >> expansion. > > Exactly. This is what I meant with "more chellenging";) It is assumed > at several places that 1->1 or 2->2 expanstions are taking place. A

> >> d) Would it be possible with current implementation of soft-float >> support to map f32/f64 to integer types smaller than i32, e.g. to >> i16? >> I have the impression that it is not necessarily the case, since it >> would require that f64 is split into 4 parts. > > Yes, this should be fine. > >> This question is more about a theoretical

On Mon, Aug 05, 2013 at 02:09:58PM -0400, Francois Pichet wrote: > On my target store/load of f32 or i32 are equivalents. > Previously I had duplicate instructions def in .td to map f32 and i32 to > the same opcode. > > I deleted all that and I instead tried a new approach (to simplify things) : > > setOperationAction(ISD::STORE, MVT::f32, Promote); >

Hi, everybody: I am a beginner with LLVM, in fact today was the first day that I use it. I have several questions about LLVM: Can I use LLVM to compile several files (bytecode), scripts (char*) and link them with external libraries generating *only* one executable (all in memory)? Can I invoke externals functions from a guest (LLVM generated) code which exist in the host code (the code that

Are you marking i16 a legal type? In XXISelLowering.cpp, you should assign it a register class. e.g. addRegisterClass(MVT::i16, XX::i16RegisterClass) Evan On Feb 2, 2009, at 12:19 PM, Villmow, Micah wrote: > It seems that LLVM is converting all the 16 bit ints into 32 bit > ints. Is there a way I can tell LLVM that 16 bit ints are valid and > legal and not to do any conversions

Hi Chris, Thank you very much for your answer! It helps me to move in the right direction. When you explain it, it sounds rather easy. But I still have some tricky issues. This is either because I'm not so familiar with LLVM or because it is a bit underestimated how much LLVM legalizer/expander relay on expandable types to be integers (see my explanations below). --- Chris Lattner <sabre

On Fri, 17 Nov 2006, Roman Levenstein wrote: > I still have some questions about FP emulation for my embedded target. > To recap a bit: > My target only has integer registers and no hardware support for FP. FP > is supported only via emulation. Only f64 is supported. All FP > operations should be implemented to use i32 registers. ok > allocation. But anyway, I have an almost

Hi, I'm trying to emit FP_ROUND f64 -> f32 considering a mips target that only supports single float point operations. The problem is that f32 is considered legal on this target but f64 doesn't and the only way I can codegen this instruction is using setConvertAction(MVT::f64, MVT::f32, Expand), which issues a EmitStackConvert. What if I want a libcall instead? What should I do? The

Hi, I still have some questions about FP emulation for my embedded target. To recap a bit: My target only has integer registers and no hardware support for FP. FP is supported only via emulation. Only f64 is supported. All FP operations should be implemented to use i32 registers. Based on the fruitful discussions on this list I was already able to implement mapping of the FP operations to