search for: memop

This patch adds a feature to allow SSE memops to be unaligned on supported architectures. Mostly I want to see if the naming is reasonable. Supporting unaligned memops requires a bit twiddle on 10h processors. This patch makes the assumption that the OS sets the bit correctly. Comments? -Dave --------------...

...9;t need two > versions of each of the instructions. Doing this for everything > will require some work to make sure that the extra insert/extract > operators don't incur unnecessary copying, but that's also > something we'd like to do regardless. So then how does one do a memop intrinsic? Does it mean we can't match to the memop versions of instructions? -Dave

...de* LDW = CurDAG->getMachineNode(AVR::LDWRdPtr, SDLoc(N), VT, PtrVT, MVT::Other, LD->getBasePtr(), LD->getChain()); // Honestly, I have no idea what this does, but other memory // accessing instructions have something similar... MachineSDNode::mmo_iterator MemOp = MF->allocateMemRefsArray(1); MemOp[0] = cast<MemSDNode>(N)->getMemOperand(); cast<MachineSDNode>(LDW)->setMemRefs(MemOp, MemOp + 1); // Reshuffle LDW's results so that the first two match LOAD's result // type SDValue Unpack[] = { S...

...sions of each of the instructions. Doing this for everything >> will require some work to make sure that the extra insert/extract >> operators don't incur unnecessary copying, but that's also >> something we'd like to do regardless. > > So then how does one do a memop intrinsic? Does it mean we can't > match to the memop versions of instructions? Memory operands would be lowered to explicit loads and stores, which would be pattern-matched into memop instructions by instruction selection. Dan

...rtunately. >> The change requires that live interval analysis be able to determine >> whether and instruction is a load and whether an instruction writes to >> memory. > > Just use MI->mayLoad(), MI->mayStore(). Does this also account for arithmetic instructions with memops? These interfaces didn't exist in 2.9. > [And live interval analysis shouldn't be involved in remat these days.] Ok, I'm working off 2.9 so I'll have to update for trunk. That's no problem. >> The remat code itself identifies load instructions and checks to see &g...

Checking that multi-page allocations are permitted is unnecessary for PoD population operations. Instead, the (loop invariant) check added for addressing XSA-31 can be moved here. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/common/memory.c +++ b/xen/common/memory.c @@ -99,7 +99,8 @@ static void populate_physmap(struct memo

...----------------------------------===// // Dummy defs for writing generic patterns //===----------------------------------------------------------------------===// def SRCREGCLASS; def DSTREGCLASS; def MEMCLASS; def SRC1CLASS; def SRC2CLASS; def ADDRCLASS; def INTRINSIC; def TYPE; def INTTYPE; def MEMOP; // TYPE - The data type (f32 for SS, f64 for SD, etc.) // SRCREGCLASS - The source register class (VR128, FR32, etc.) // DSTREGCLASS - The destination register class // MEMCLASS - The memory classe (f32mem, f64mem, etc.) // SRC1CLASS - The first source object class (register or memory...

...gen modifications are totally fine, for the intrinsics just do: > > let Predicates = [HasSSE3] in { > def : Pat<(int_x86_sse3_hadd_ps (v4f32 VR128:$src1), VR128:$src2), > (HADDPSrr VR128:$src1, VR128:$src2)>; > def : Pat<(int_x86_sse3_hadd_ps (v4f32 VR128:$src1), (memop addr:$src2)), > (HADDPSrm VR128:$src1, addr:$src2)>; > ... > > and > > let Predicates = [HasAVX] in { > def : Pat<(int_x86_sse3_hadd_ps (v4f32 VR128:$src1), VR128:$src2), > (VHADDPSrr VR128:$src1, VR128:$src2)>; > def : Pat<(int_x86_sse3_...

...change requires that live interval analysis be able to determine >>> whether and instruction is a load and whether an instruction writes to >>> memory. >> >> Just use MI->mayLoad(), MI->mayStore(). > > Does this also account for arithmetic instructions with memops? These > interfaces didn't exist in 2.9. This is important because if mayLoad includes arithmetic instructions with source memops (which I assume it will), it is unsuitable for remat analysis. I don't think we want to remat general arithmetic quite yet. At least that's not the in...

...achineNode(AVR::LDWRdPtr, SDLoc(N), > VT, PtrVT, MVT::Other, > LD->getBasePtr(), LD->getChain()); > > // Honestly, I have no idea what this does, but other memory > // accessing instructions have something similar... > MachineSDNode::mmo_iterator MemOp = MF->allocateMemRefsArray(1); > MemOp[0] = cast<MemSDNode>(N)->getMemOperand(); > cast<MachineSDNode>(LDW)->setMemRefs(MemOp, MemOp + 1); > > // Reshuffle LDW's results so that the first two match LOAD's > result > // type &gt...

...n McInally <cameron.mcinally at nyu.edu> wrote: > On Wed, Nov 7, 2012 at 10:52 PM, Anitha Boyapati <anitha.boyapati at gmail.com> > wrote: > ... >> >> For the multiclass "fma4s", why is "mr" not inherited from "VEX_W" and >> "MemOp4" like those of "rm" or "rr" ? > > > Hey Anitha, > > The VEX.W bit is used to denote operand order. In other words, this bit > allows for a memop to be used as either the second or third source operand > of an FMA instruction, offering greater flexibili...

...interval analysis be able to determine >>>> whether and instruction is a load and whether an instruction writes to >>>> memory. >>> >>> Just use MI->mayLoad(), MI->mayStore(). >> >> Does this also account for arithmetic instructions with memops? These >> interfaces didn't exist in 2.9. > > This is important because if mayLoad includes arithmetic instructions > with source memops (which I assume it will), it is unsuitable for remat > analysis. I don't think we want to remat general arithmetic quite yet. > A...

...rsions too? 4) Your tablegen modifications are totally fine, for the intrinsics just do: let Predicates = [HasSSE3] in { def : Pat<(int_x86_sse3_hadd_ps (v4f32 VR128:$src1), VR128:$src2), (HADDPSrr VR128:$src1, VR128:$src2)>; def : Pat<(int_x86_sse3_hadd_ps (v4f32 VR128:$src1), (memop addr:$src2)), (HADDPSrm VR128:$src1, addr:$src2)>; ... and let Predicates = [HasAVX] in { def : Pat<(int_x86_sse3_hadd_ps (v4f32 VR128:$src1), VR128:$src2), (VHADDPSrr VR128:$src1, VR128:$src2)>; def : Pat<(int_x86_sse3_hadd_ps (v4f32 VR128:$src1), (memop addr:$src...

...gt;mayStore(). [And live interval analysis shouldn't be involved in remat these days.] > The remat code itself identifies load instructions and checks to see > whether it interferes with any instructions that write to memory. How does that affect compile time? > Finally, are MachineMemOperands guaranteed (modulo bugs, of course) to > be preserved at least through regalloc? They are preserved, but they are not 'guaranteed'. A load or store with missing memops should conservatively be treated as volatile, aliasing everything. /jakob

...en modifications are totally fine, for the intrinsics just do: > > let Predicates = [HasSSE3] in { > def : Pat<(int_x86_sse3_hadd_ps (v4f32 VR128:$src1), VR128:$src2), > (HADDPSrr VR128:$src1, VR128:$src2)>; def : > Pat<(int_x86_sse3_hadd_ps (v4f32 VR128:$src1), (memop addr:$src2)), > (HADDPSrm VR128:$src1, addr:$src2)>; ... > > and > > let Predicates = [HasAVX] in { > def : Pat<(int_x86_sse3_hadd_ps (v4f32 VR128:$src1), VR128:$src2), > (VHADDPSrr VR128:$src1, VR128:$src2)>; def : > Pat<(int_x86_sse3_hadd...

This patch synthesizes haddps/haddpd/hsubps/hsubpd instructions from floating point additions and subtractions of appropriate vector shuffles. To do this I introduced new x86 FHADD and FHSUB opcodes. These need to be wired up somehow in the .td file to the appropriate instructions. Since I have no idea how tablegen works I just hacked it in horribly. It works, but breaks support for the hadd

On Wed, Nov 7, 2012 at 10:52 PM, Anitha Boyapati <anitha.boyapati at gmail.com>wrote: ... > For the multiclass "fma4s", why is "mr" not inherited from "VEX_W" and > "MemOp4" like those of "rm" or "rr" ? > Hey Anitha, The VEX.W bit is used to denote operand order. In other words, this bit allows for a memop to be used as either the second or third source operand of an FMA instruction, offering greater flexibility. To conceptualize: VFMA...

Hi, A question from r162999 changes: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/X86InstrFMA.td?r1=162999&r2=162998&pathrev=162999 For the multiclass "fma4s", why is "mr" not inherited from "VEX_W" and "MemOp4" like those of "rm" or "rr" ? multiclass fma4s< > ... def mr : FMA4<opc, MRMSrcMem, (outs RC:$dst), (ins RC:$src1, x86memop:$src2, RC:$src3), !strconcat(OpcodeStr, "\t{$src3, $src2, $src1, $dst|$dst, $src1, $src2, $src3}&qu...

...Load returns false so that false negatives are possible. - Add a writesMemory member to TargetInstrInfo with a corresponding implementation in the XD86 target. The target implemenmtation is both a switch on store-type opcodes and a check to see whether a MachineInstr has write-type MachineMemOperands. The default implementation returns "false" but "true" might be a safer default (false positives). The remat code itself identifies load instructions and checks to see whether it interferes with any instructions that write to memory. Are isLoad and writesMemory reas...

...kfree(sgt); @@ -426,15 +426,12 @@ static void vb2_dc_put_userptr(void *buf_priv) struct page **pages; if (sgt) { - DEFINE_DMA_ATTRS(attrs); - - dma_set_attr(DMA_ATTR_SKIP_CPU_SYNC, &attrs); /* * No need to sync to CPU, it's already synced to the CPU * since the finish() memop will have been called before this. */ dma_unmap_sg_attrs(buf->dev, sgt->sgl, sgt->orig_nents, - buf->dma_dir, &attrs); + buf->dma_dir, DMA_ATTR_SKIP_CPU_SYNC); pages = frame_vector_pages(buf->vec); /* sgt should exist only if vector contains pages... *...