search for: xxxisellow

...function. (It used to be that in that case -msoft-float had no effect because those attributes where not preserved in the IL. ) Then if you run llc and say -soft-float, what happens is that the code generator will compile everything as soft-float, but the value of the following will be false in XXXISelLowering getTargetMachine().Options.UseSoftFloat When the constructor for XXXISelLowering is called, TM.Options.UseSoftFloat will be true. What is interesting is that code for "make check" won't have any of the new attributes there so it will work as before. I was seeing this behavi...

...be that in that case -msoft-float had no effect because those > attributes where not preserved in the IL. ) > > Then if you run llc and say -soft-float, what happens is that the code > generator will compile everything as soft-float, but the value of the > following will be false in XXXISelLowering > getTargetMachine().Options.UseSoftFloat > > When the constructor for XXXISelLowering is called, TM.Options.UseSoftFloat > will be true. > > What is interesting is that code for "make check" won't have any of the new > attributes there so > it will work a...

...the best way to do this? I see in the DAGBuilder it calls 'setValue' which adds to the map NodeMap[V] where V is the key and the passed in SDValue is the value but I'm not sure this is a good way to do it since these are local to SelectionDAGBuilder and the lowering needs to happen in XXXISelLowering.cpp. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160202/5cd67c89/attachment.html>

Hi, I wonder how the initial selection DAG is built in the backends. >From working backends I get: ----8<------- Initial selection DAG: BB#0 'main:' SelectionDAG has 18 nodes: ----8<------- >From my (not working) backend I get: ----8<------- Initial selection DAG: BB#0 'main:' SelectionDAG has 15 nodes: ----8<------- I miss three nodes and I wonder what do I have

...e -msoft-float had no effect because those >> attributes where not preserved in the IL. ) >> >> Then if you run llc and say -soft-float, what happens is that the code >> generator will compile everything as soft-float, but the value of the >> following will be false in XXXISelLowering >> getTargetMachine().Options.UseSoftFloat >> >> When the constructor for XXXISelLowering is called, TM.Options.UseSoftFloat >> will be true. >> >> What is interesting is that code for "make check" won't have any of the new >> attributes...

...ural regalloc. You don't have to formally specify calling convention. For example, ARM backend does not have a ARMCallingConv.td file, all the argument passing info are implicitly defined in the lowering code. To start, you should specify legal register files, legal operations, etc. See XXXISelLowering.cpp for examples. Evan > > > Any pointers to learn about this will be a great help. > Sanjiv > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/li...

Could anybody guide me what information do I need to know about my target in order to provide the target lowering info to the llvm DAG generator? We do not have any fixed registers for argument passing. Everything including the formal and actual arguments will take part in a global interprocedural regalloc. Any pointers to learn about this will be a great help. Sanjiv

MachineRegisterInfo is maintaining a list of live-out registers for the MachineFunction. It contains the return value registers, and is typically created by XXXISelLowering::LowerReturn(). Various passes after instruction selection need to look at this list to determine which physical registers are live in return blocks. Eventually, the register allocators copy these live-out registers onto the return instructions as implicit use operands. Passes after register...

...at gmail.com> wrote: > Thanks for the reply: > > So should LLVM continue to assume 8-bit byte addressing? It would be nice, > not only to us but potential future machines, to have a permanent fix to > this assumption? This sounds reasonable yes? > > Marking them as Custom in XXXISelLowering still produces error, the > pre-legalize phase is still going to opt to LD1 since it's not caring about > target-specifics. Then, again, we'll be stuck trying to undo the addressing. > > I see what you mean about the DAGCombiner, that's a two part solution, first > t...

...want to read S->b for example. The size of struct S is 64 bits, and seems LLVM treats it as i64. Below is the IR corresponding to S->b, IIRC. %0 = load i64, *i64 ptr, align 4; %1 = %0 lshr 8; %2 = %1 and 255; Our target doesn't support load i64, so we have following code in XXXISelLowering.cpp setOperationAction(ISD::LOAD, MVT::i64, Custom); Transform load i64 to load v2i32 during type legalization. During op legalization, load v2i32 is found unaligned (4 v.s. 8), so stack load/store instructions are generated. This is one problem. Besides of that, our target has bitset/b...

...u don't have to formally specify calling convention. For example, > ARM backend does not have a ARMCallingConv.td file, all the argument > passing info are implicitly defined in the lowering code. > > To start, you should specify legal register files, legal operations, > etc. See XXXISelLowering.cpp for examples. > > Evan > > > > > > > Any pointers to learn about this will be a great help. > > Sanjiv > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.u...

We've got both an sqrtf and an expf opcode in our architecture. If I call sqrt() on the C side, I see the sqrtf opcode show up in the generated assembly. However, if I call exp() on the C side, I don't see the expf opcode show up on the generated assembly, I see a call to an exp function from libm. Here's what we've got in our TargetInstrinfo.td file for both of these

On Tue, Jun 7, 2016 at 1:57 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Tim, > > Currently, I have to do multiple things: > > 1) create some setLibcallNames in XXXISelLowering.cpp to generate correct > naming for RTLIBS. > 2) lower ISD down to an RTLIB for some calls (and then do solution 1 on > those to get correct names) These solve a related but different - CodeGen - problem. RTLIB libcalls are used when we're not able to select some IR instruction...

...r for 16 bit signed integer 17 movr2vr.dup vr3, r5 // duplicate r5 into vr3 18 vadd.s16 vr1, vr2, vr3, vpr0 // vpr0 has carry bits set now Each vector type has a different instruction sequence, because the bit mask and element type is different. I have tried to lower load/store for vpr in XXXISelLowering.cpp. But there is no guarantee that line 12 and line 18 would assign the same register for vpr0. vpr0 in line18 is an output and is not an input. And vpr0 in line 12 and line 18 is parallel in SelectionDAG graph. They are both output. I think I would try to define three pseudo instructions for...

...than, if any input NaN then return false fcmp.ne --> ordered not equal, if any input NaN then return true fcmp.ge --> ordered grater equal, if any input NaN then return false When FPU is not present I need to generate a library call, so I have added following code in LowerBR_CC function in XXXISelLowering.cpp const XXXSubtarget &STI = static_cast<const XXXSubtarget&> (DAG.getSubtarget()); XXXCC::CondCodes TCC; getFPCCtoXXCC(CC,TCC); TargetCC = DAG.getConstant(TCC, dl, MVT::i8); if (STI.useHardFloat()) { // if fcmp instruction i...

Tim, Are you referring to setLibcallName? That is target specific yes but there isn't RTLIB for most of the libm functions, for example, for acos this doesn't apply. Ideally what I would like is to create a libc with functions like acos called something like __xxx_acos that can still be recognized to be optimized. RTLIB is pretty limited but it works fine, I can just use

...rn false > fcmp.ne --> ordered not equal, if any input NaN then return true > fcmp.ge --> ordered grater equal, if any input NaN then return false > > When FPU is not present I need to generate a library call, > > so I have added following code in LowerBR_CC function in > XXXISelLowering.cpp > > const XXXSubtarget &STI = static_cast<const XXXSubtarget&> > (DAG.getSubtarget()); > XXXCC::CondCodes TCC; > getFPCCtoXXCC(CC,TCC); > TargetCC = DAG.getConstant(TCC, dl, MVT::i8); > if (STI.useHardFloat...

All, I just committed r185596 which removes some exception-related ISD opcodes. If you have an out-of-tree target that supports DWARF exception handling, that probably broke your build. Just delete these lines from your XXXISelLowering.cpp file: - setOperationAction(ISD::EHSELECTION, MVT::i32, Expand); - setOperationAction(ISD::EXCEPTIONADDR, MVT::i32, Expand); The lowering code for DWARF landing pads now only needs these parameters: setExceptionPointerRegister(X86::EAX); setExceptionSelectorRegi...

Hi, For my 32-bit architecture backend, I run into trouble because strcpy is converted into i64 store instructions, on which instruction selection fails. No i64 store is declared anywhere in my .td files or architecture backend, so I would assume that they are automatically converted into 2 i32 stores, but apparently, that is not the case. Do I need to add anything to my backend to have this

On Saturday, March 4, 2017, Ryan Taylor <ryta1203 at gmail.com> wrote: > Why you can't still expand it through MUL with a Custom lowering? Or am I > missing something? > > Yes we can but problem occurs when we know that it is shift with constant value than if we return ISD::MUL with constant imm operand than LLVM will convert it to SHL again because the constant will be