search for: hkultala

It seems some optimization pass converts some address computation add's into or's when it knows it's allowed due correct alignment. How do I turn this off keep the address calculations as adds?

...e, perhaps we can add the address space as another field to the MachineMemOperand. If the Value* gets cleared, at least that would still be available, and I cannot imagine any transformation that would cause the pointer address space to change. On Tue, Dec 11, 2012 at 2:52 PM, Heikki Kultala <hkultala at cs.tut.fi> wrote: > > On 11 Dec 2012, at 21:00, Justin Holewinski wrote: > > > I want to get some clarification on the exact semantics of the > MachineMemOperand attached to memory-touching instructions. From what I > understand, a MemSDNode has an associated MachineMem...

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 Thu, Sep 29, 2011 at 3:06 AM, Heikki Kultala <hkultala at iki.fi> wrote: > > > make[1]: Entering directory > `/home/hkultala26/src/llvm-trunk/llvm/tools/llvm-config' > llvm[1]: Regenerating LibDeps.txt.tmp > llvm[1]: Checking for cyclic dependencies between LLVM libraries. > find-cycles.pl: Circular dependency between *.a f...

On 29 Jan 2013, at 10:20, Tobias Grosser wrote: > On 01/28/2013 07:45 PM, Tanya Lattner wrote: >> I will be removing the list prefix "LLVMDev" from the subject line. If you are filtering by this, please use the list headers instead. >> >> If you have any questions, please let me know. > > Thanks Tanya, this makes the subject lines of the commits a lot more

On 25 Aug 2010, at 02:04, Silvio Ricardo Cordeiro wrote: > On Sun, Aug 15, 2010 at 10:04 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Aug 15, 2010, at 5:12 PM, Silvio Ricardo Cordeiro wrote: > > > Is there a way for me to collect statistics about the number of loads/stores added by the "linearscan" register allocator (just like can be done with

make[1]: Entering directory `/home/hkultala26/src/llvm-trunk/llvm/tools/llvm-config' llvm[1]: Regenerating LibDeps.txt.tmp llvm[1]: Checking for cyclic dependencies between LLVM libraries. find-cycles.pl: Circular dependency between *.a files: find-cycles.pl: libLLVMPTXAsmPrinter.a libLLVMPTXCodeGen.a libLLVMPTXDesc.a llvm[1]: Building...

On 11 Dec 2012, at 21:00, Justin Holewinski wrote: > I want to get some clarification on the exact semantics of the MachineMemOperand attached to memory-touching instructions. From what I understand, a MemSDNode has an associated MachineMemOperand and a MachineInstr can have zero or more attached MachineMemOperands. > > But what is the guarantee/constraint placed on

On Sun, Aug 15, 2010 at 10:04 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > > On Aug 15, 2010, at 5:12 PM, Silvio Ricardo Cordeiro wrote: > > > Is there a way for me to collect statistics about the number of > loads/stores added by the "linearscan" register allocator (just like can be > done with the "local" allocator)? I still haven't

I want to get some clarification on the exact semantics of the MachineMemOperand attached to memory-touching instructions. From what I understand, a MemSDNode has an associated MachineMemOperand and a MachineInstr can have zero or more attached MachineMemOperands. But what is the guarantee/constraint placed on optimization/codegen passes for maintaining the contents of a MachineMemOperand? In

On 5 Oct 2010, at 01:48, Evan Cheng wrote: > Please test if r115571 has fixed it. thanks a lot, I tested and 115571 fixed this. can it still be merged into 2.8 before release?

It seems LoopIdiomRecognizer pass recognizes one loop inside memSet as memset and replaces it with memset intrinsic, which might then be converted into memset call, resulting in infinite recursion. There is parameter -fno-builtins to prevent this, BUT when executing opt as "standalone", this parameter cannot be given to it, with default optimizations it executes the LoopIdiomRecognizer,

Our TCE backend (which is not in the official llvm repo) benefits greatly from information that which memory load/store is a spill generated by register allocation. These spill memory operation can never alias with other memory operations, and our own instruction scheduler can optimize much better with better alias information. I have created a code which adds marking these spill

I tried to add a isel pattern [(set I32Regs:$dest, (select (seteq I32Regs:$op1, I32Regs:$op1), I32Regs:$op3, I32Regs:$op4))] for my instruction. I get an error message "Could not infer all types in a pattern!" Above the error message it prints error message line containing the name of my op and (set I32Regs:i32:$dest, (select:i32 (setcc:{i1:i8:i16:i32:i64} I32Regs:i32:$op1,

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

I am a bit confused how the rematerialization works. It seems currently in our backend we get lots of code where some stack offset address is calculated, but this address is then spilled to stack, and loaded from stack later. This does not make sense, it would be better to just recalculate the address later, ie rematerialize the original stack offset calculation. But marking some instruction

...instruction which transports floating point immediate to a floating point register. def MOVF32fk : InstTCE<(outs F32Regs:$dst), (ins f32imm:$val), "$val -> $dst;", [(set F32Regs:$dst, (f32 imm:$val))]>; This causes an type contradiction: /home/hkultala26/src/devel/tce/src/applibs/LLVMBackend/plugin//TCEInstrInfo.td:109:1: error: In MOVF32fk: Type inference contradiction found, 'f32' needs to be integer def MOVF32fk : InstTCE<(outs F32Regs:$dst), (ins f32imm:$val), why? Why does llvm assume floating point immediate needs to be inte...

OpenCL defines half data type, and it seems clang accepts this and generates code for it. The backend support for operations with fp16 seems to be missing and it works (or should work?) by converting these to fp32 for the actual calculations? But I'm having problems with this. first I just tried to use fp16 data type, without any support in backend. This was expected to fail. I got

I have an operation which loads a 16 bit block of data as 2 8-bit elements, sign extends the both parts to 32 bits and stores the result into 64-bit vector register. How can I define the pattern for this? just using [(set V2I32Regs:$result, (sextloadv2i8 ADDRrr:$address))] gives me error that extloav2i8 is not defined. (the same principle works for scalar sextload) So I need to define it

On 10/30/2012 04:52 PM, Tim Northover wrote: > Hi Heikki, > >> just using [(set V2I32Regs:$result, (sextloadv2i8 ADDRrr:$address))] >> >> gives me error that extloav2i8 is not defined. > > I don't have a target to test this on, but looking at > include/llvm/Target/TargetSelectionDAG.td, there is an "sextloadvi8" > PatFrag, at least. I'd suggest