search for: memref

...>; ****************************** Without getting into too much detail, all that the pattern is doing is combining the results of two 32 bit loads into a 64 bit value. The two loads can be packetized together. However, they are not being packetized together because they seem to be losing their MemRefs (i.e MI->memoperands_empty()) when lowered via this pattern. This causes the loads to be volatile and "unpacketizable". Is there no way to preserve or attach MemRefs to the LDriw instructions generated by way of a pattern in the InstrInfo.td file ? FWIW, the LDriw instruction is as s...

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Pranav Bhandarkar > Sent: Thursday, April 26, 2012 5:24 PM > To: llvmdev at cs.uiuc.edu > Subject: [LLVMdev] MemRefs in a Load Instruction > > Hi, > > On the hexagon target, I have written a following combiner pattern. > ********************************************* > > def: Pat<(i64 (or (i64 (shl (i64 (extloadi32 (i32 (add IntRegs:$src1, > > s11_2ExtPred:$offset1)))), >...

...es across llvm/clang. I’ll see what I can fix as I would like to get these to behave. There may be actual logic errors in some of these cases. >> Well this is fun. There is a long standing bug in the SelectionDAG tablegen matcher this has uncovered. Seems that ComplexPattern’s don’t track MemRefs. It probably (hopefully!) just causes downstream code to be conservative but its possible there’s real issues being hidden by this. >> >> The problematic code is something like ‘xop(load) -> X86XOPrm’ where the resulting X86XOP MachineInstr wouldn’t have an MachineMemOperand’s, de...

On Jul 25, 2019, at 7:20 AM, Michael Kruse via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Am Mi., 24. Juli 2019 um 16:13 Uhr schrieb Tim Northover > <t.p.northover at gmail.com>: … Siddharth’s original RFC <https://github.com/bollu/llvm-multidim-array-indexing-proposal/blob/master/RFC.md> ... >> Apart from all that, I'm pretty disappointed to see this as an

...see what I >> can fix as I would like to get these to behave. There may be actual >> logic errors in some of these cases. > Well this is fun. There is a long standing bug in the SelectionDAG > tablegen matcher this has uncovered. Seems that ComplexPattern’s > don’t track MemRefs. It probably (hopefully!) just causes downstream > code to be conservative but its possible there’s real issues being > hidden by this. > > The problematic code is something like ‘xop(load) -> X86XOPrm’ where > the resulting X86XOP MachineInstr wouldn’t have an > MachineM...

...rowed. > > I have been following MLIR and even pointed the flang team towards it > since this kind of access is more important in Fortran than in C/C++. Oh cool. > IMHO the issue is representation since LLVM-IR does not have the > primitives that MLIR has, specifically there is no Memref type that -- > in contrast to LLVM-IR pointer types are multi-dimensional, and -- in > contrast to LLVM-IR array types can have dependent and dynamic shape. > > Adding a MemRef type this would go quite deep into LLVM-IR > fundamentals. Do you think it would be worth it? That’s the...

...00 failures across llvm/clang. I’ll see what I can fix as I would like to get these to behave. There may be actual logic errors in some of these cases. Well this is fun. There is a long standing bug in the SelectionDAG tablegen matcher this has uncovered. Seems that ComplexPattern’s don’t track MemRefs. It probably (hopefully!) just causes downstream code to be conservative but its possible there’s real issues being hidden by this. The problematic code is something like ‘xop(load) -> X86XOPrm’ where the resulting X86XOP MachineInstr wouldn’t have an MachineMemOperand’s, despite being marked...

...case (which is g++.dg/expr/bitfield4.C from the GCC 4.2 testsuite) I get: $ cc1plus bitfield4.ii -emit-llvm-bc -o bitfield4.o -quiet cc1plus: /home/foad/svn/antix/toolchain/branches/w/foad/2757llvm26/toolchain/llvm/llvm-gcc/gcc/llvm-convert.cpp:999: llvm::Value* TreeToLLVM::Emit(tree_node*, const MemRef*): Assertion `(Result == 0 || (((enum tree_code) (((exp)->common.type))->common.code) == VOID_TYPE) || isa<VectorType>(ConvertType(((exp)->common.type))) || Result->getType() == ConvertType(((exp)->common.type))) && "Value has wrong type!"' failed. At thi...

N_conreq:entry { self->x=1; calledaddr=(struct xaddrf *)arg3; callingaddr=(struct xaddrf *)arg4; trace(calledaddr->link_id); tracemem(calledaddr->DTE_MAC.lsap_add, 80); trace(callingaddr->link_id); tracemem(callingaddr->DTE_MAC.lsap_add, 80); } 0 -> N_conreq 255

...there's no guarantee the high-level > dialects will be preserved until the vectorisation pass. I'd put loop optimizations earlier into the pipeline than vectorization. Where exactly is a phase ordering problem. I'd want to at least preserve multi-dimensional subscripts. Fortunately MemRef is a core MLIR construct and unlikely to be lowered before lowering to another representation (likely LLVM-IR). > And other > front-ends may not generate the same quality of annotations. > We may have to re-generate what we need anyway, so no point in waiting > all the front-ends to d...

...I think it is worth mentioning it in the “sequential code flow representation” in the RFC. This raises the following questions. 1. Which types are supported? Standard dialect types and FIR types? For example, what types are used for Fortran arrays used inside OpenMP regions? Is it std.memref OR Fortran array representation in FIR dialect (fir.array?) OR both? Note that Fortran has support for column major arrays. std.memref supports custom memory layouts. What custom layouts are supported? How would different non-scalar types in standard dialect be lowered to LLVM IR and passed to...

...LValue LV = EmitLV(Op); assert(!LV.isBitfield() && "Expected an aggregate operand!"); bool isVolatile = TREE_THIS_VOLATILE(Op); - unsigned Alignment = expr_align(Op) / 8; + unsigned Alignment = LV.getAlignment(); EmitAggregateCopy(Target, MemRef(LV.Ptr, Alignment, isVolatile), TREE_TYPE(exp)); @@ -5885,9 +5896,10 @@ LValue TreeToLLVM::EmitLV_DECL(tree exp) Value *Decl = DECL_LLVM(exp); if (Decl == 0) { if (errorcount || sorrycount) { - const PointerType *Ty = - PointerType::getUnqual(Conv...

...>> This raises the following questions. >> >> >> >> 1. >> >> Which types are supported? Standard dialect types and FIR types? >> >> >> For example, what types are used for Fortran arrays used inside OpenMP >> regions? Is it std.memref OR Fortran array representation in FIR dialect >> (fir.array?) OR both? Note that Fortran has support for column major >> arrays. std.memref supports custom memory layouts. What custom layouts are >> supported? >> >> >> How would different non-scalar types in st...

...e memory > object of LValue. can't you just use expr_align(lhs) instead? > The patch saves the alignment of the memory object in LValue returned > by EmitLV(). Please review it carefully as I am not entirely > comfortable hacking on llvm-gcc. :-) In the long run, LValue and MemRef should be merged, but that can wait until later I suppose. > + case LABEL_DECL: { > + Value *Ptr = TreeConstantToLLVM::EmitLV_LABEL_DECL(exp); > + return LValue(Ptr, DECL_ALIGN(exp) / 8); > + } > + case COMPLEX_CST: { > + Value *Ptr = TreeConstantToLLVM::EmitLV_COMPLE...

...erations. D. Because of (A), (B) and (C), it would be beneficial to have an omp. parallel_do operation which has semantics similar to other loop structures (may not be LoopLikeInterface) in MLIR. To me, it looks like having OpenMP operations based on standard MLIR types and operations (scalars and memrefs mainly) is the right way to go. Why not have omp.parallel_do operation with AffineMap based bounds, so as to decouple it from Value/Type similar to affine.for? 1. With the current design, the number of transformations / optimizations that one can write on OpenMP constructs would become limited a...

...>>>> >>>> 1. >>>> >>>> Which types are supported? Standard dialect types and FIR types? >>>> >>>> >>>> For example, what types are used for Fortran arrays used inside OpenMP >>>> regions? Is it std.memref OR Fortran array representation in FIR dialect >>>> (fir.array?) OR both? Note that Fortran has support for column major >>>> arrays. std.memref supports custom memory layouts. What custom layouts are >>>> supported? >>>> >>>> >>&gt...

...decnumber -I/local/space2/llvm_toolchain/llvm-2.5-objects/include -I/local/space2/llvm_toolchain/llvm-2.5/include ../../llvm-gcc-4.2/gcc/llvm-convert.cpp -o llvm-convert.o ../../llvm-gcc-4.2/gcc/llvm-convert.cpp: In member function 'bool TreeToLLVM::EmitBuiltinCall(tree_node*, tree_node*, const MemRef*, llvm::Value*&)': ../../llvm-gcc-4.2/gcc/llvm-convert.cpp:4387: error: 'getIntrinsicForGCCBuiltin' is not a member of 'llvm::Intrinsic' make[2]: *** [llvm-convert.o] Error 1 make[2]: Leaving directory `/local/space2/llvm_toolchain/llvm-gcc4.2-2.5-objects/gcc' make[1]:...

...yy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:2109: undefined reference to `lookup_type_for_runtime' libbackend.a(llvm-convert.o): In function `TreeToLLVM::EmitBuiltinCall(tree_node*, tree_node*, MemRef const*, llvm::Value*&)': /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree/gcc/../../llvm-gcc-4.2-2.7.source/gcc/llvm-convert.cpp:5944: undefined reference to `validate_arglist' /home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto...

...end. > > Not necessarily. We have discussed introducing dialect annotation to > MLIR during compile time from analysis passes that would basically do > what the front-end should have done. The argument is that MLIR has first-class expressions for multi-dimensional array accesses ("MemRef") while LLVM-IR does not. https://lists.llvm.org/pipermail/llvm-dev/2019-July/134063.html Both of them can have analyses to raise the abstraction to a multi-dimensional access ("delinearization"). > Conclusions? > > This was a long email, with too many proposals, so I do...

...ally does apply here, but I also think that pass-specific dependence analyses do not scale. > > I'd put loop optimizations earlier into the pipeline than vectorization. Where exactly is a phase ordering problem. I'd want to at least preserve multi-dimensional subscripts. Fortunately MemRef is a core MLIR construct and unlikely to be lowered before lowering to another representation (likely LLVM-IR). > > Many front-ends do that even before lowering to IR because of the > richer semantics of the AST, but it's also common for that to > introduce bugs down the line (don...