search for: memrefs

...>; ****************************** 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 sh...

> -----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, des...

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

On Jul 29, 2019, at 1:30 PM, Michael Kruse <llvmdev at meinersbur.de> wrote: >> Have you been following what is happening on the MLIR side of the world? It directly supports multi-dimensional arrays with both value and buffer semantics (e.g. load, store, and DMA operations). It is specifically focused on solving these sorts of problems, and is the current proposed direction for 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...

I've built a debug build of llvm 2.6, and llvm-gcc 2.6 for arm-elf with --enable-checking=yes. On the attached test 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*

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

Am Sa., 11. Jan. 2020 um 07:43 Uhr schrieb Renato Golin <rengolin at gmail.com >: > On Sat, 11 Jan 2020 at 00:34, Michael Kruse <llvmdev at meinersbur.de> wrote: > > Yes, as mentioned in the Q&A. Unfortunately VPlan is able to represent > > arbitrary code not has cheap copies. > > Orthogonal, but we should also be looking into implementing the cheap > copies

...nst adding parallel_do if it can help with transformations or > reduce the complexity of lowering. Please share the details in discourse as > a reply to the RFC or a separate thread. > > it looks like having OpenMP operations based on standard MLIR types and > operations (scalars and memrefs mainly) is the right way to go. > > This will definitely be the first version that we implement. But I do not > understand why we should restrict to only the standard types and > operations. To ease lowering and translation and to avoid adding OpenMP > operations to other dialects, I...

Hi all, Please review this patch. It's fixing PR3232 comment #8. Function bar from 2008-03-24-BitFiled-And-Alloca.c compiles to: %struct.Key = type { { i32, i32 } } ... define i32 @bar(i64 %key_token2) nounwind { entry: %key_token2_addr = alloca i64 ; <i64*> [#uses=2] %retval = alloca i32 ; <i32*> [#uses=2] %iospec =

...th transformations >>> or reduce the complexity of lowering. Please share the details in discourse >>> as a reply to the RFC or a separate thread. >>> >>> it looks like having OpenMP operations based on standard MLIR types and >>> operations (scalars and memrefs mainly) is the right way to go. >>> >>> This will definitely be the first version that we implement. But I do >>> not understand why we should restrict to only the standard types and >>> operations. To ease lowering and translation and to avoid adding OpenMP >...

Hi Evan, > LValue LV = EmitLV(lhs); > bool isVolatile = TREE_THIS_VOLATILE(lhs); > unsigned Alignment = expr_align(exp) / 8 > > It's using the alignment of the expression, rather than the 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().

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

...or reduce the complexity of lowering. Please share the >>>>> details in discourse as a reply to the RFC or a separate thread. >>>>> >>>>> it looks like having OpenMP operations based on standard MLIR types >>>>> and operations (scalars and memrefs mainly) is the right way to go. >>>>> >>>>> This will definitely be the first version that we implement. But I do >>>>> not understand why we should restrict to only the standard types and >>>>> operations. To ease lowering and translation...

I am new to LLVM, and I'm trying to compile llvm and llvm-gcc from subversion on a Solaris10/SPARC machine. I have already tried building llvm-2.4 on this machine, but it failed. I then tried the subversion sources (rev. # 65253 fro llvm and rev#65263 for llvm-gcc) and llvm at least builds correctly ( I however have not tried testing it!). I can execute binaries located in

any ideas what library has these symbols lang_eh_catch_all get_pointer_alignment validate_arglist i get these linker errors when trying to link llvm-gcc: make[1]: Entering directory `/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree' make[2]: Entering directory

Am Fr., 10. Jan. 2020 um 16:10 Uhr schrieb Renato Golin <rengolin at gmail.com>: > On Fri, 3 Jan 2020 at 11:27, Michael Kruse via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > 1. Candidate selection through cost function > > -------------------------------------------- > > Instead of needing to know which transformation is profitable before > >

Am Mi., 15. Jan. 2020 um 03:30 Uhr schrieb Renato Golin <rengolin at gmail.com>: > > I see it as an advantage in respect of adoption: It can be switched on and off without affecting other parts. > > That's not necessarily true. > > If we do like Polly, it is, but then the ability to reuse code is very > low and the time spent converting across is high. If we want to