search for: emittargetcodeformemcpy

clang generates llvm.memcpy.* intrinsics for our port. Now we are linking a .bc version of the standard library. Do we have to include a version of these intrinsics in the .bc librrary? If yes, do we have some already written version? Or do we have to leave them for llc to convert them in to memcpy and then provide an binary version of lib with these functions ? - Sanjiv

Hi Tim, Thanks for your reply. That’s what I was afraid of. I will try on the cfe-list as you suggest though. The reason I want structs to be aligned/padded to 2 bytes is because my architecture only has 16 bit operations. I can read (sign and zero extended) and write (truncated) 8 bit data from/to memory, but all intermediate operations in registers are performed in 16 bit registers. This

...points where you can control how > memcpy is implemented. The function "findOptimalMemOpLowering" lets > you control the type used for the loads and stores, and > MaxStoresPerMemcpy controls when LLVM will call the real memcpy. If > you want even more control you can implement EmitTargetCodeForMemcpy > to do the whole thing. > > Cheers. > > Tim. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190513/17263825/attachment.html>

...ISD::FakeLoad64", SDTIntBinOp, [SDNPHasChain]>; def AArch64fakestore64 : SDNode<"AArch64ISD::FakeStore64", SDTIntBinOp, [SDNPHasChain]>; to AArch64ISD in AArch64ISelLowering.h below ISD::FIRST_TARGET_MEMORY_OPCODE: FakeLoad64, FakeStore64 in AArch64SelectionDAGInfo::EmitTargetCodeForMemcpy(): SmallVector<SDValue, 4> Ops; Ops.push_back(Chain); Ops.push_back(DAG.getNode(ISD::ADD, dl, MVT::i64, Src, DAG.getConstant(SrcOff, MVT::i64))); // Ops.push_back(SrcPtrInfo.getWithOffset(SrcOff)); Ops.push_back(DAG.getConstant(0, MVT::i64)); Loads[i]...

On Tue, Jul 30, 2013 at 01:14:16PM -0600, Dan wrote: > I'll try to run through the scenario: > > > 64-bit register type target (all registers have 64 bits). > > all 32-bits are getting promoted to 64-bit integers > > Problem: > > MUL on i32 is getting promoted to MUL on i64 > > MUL on i64 is getting expanded to a library call in compiler-rt > >

...s all MUL I32 to 64-bit, and I lose the ability to differentiate between what originally was a MUL on 64-bit and 32-bit values. Only thing that I have seen happen at DAG Selection is for lowering custom intrinsic functions like memcpy: ./Target/X86/X86SelectionDAGInfo.cpp:178:X86SelectionDAGInfo::EmitTargetCodeForMemcpy(SelectionDAG &DAG, Is there a general SelectionDAG conversion that can be made to happen before all type promotions? Again, even modifications in ISelDAGToDAG.cpp will be after type promotion in my understanding. On Tue, Jul 30, 2013 at 1:55 PM, Tom Stellard <tom at stellard.net> w...

I'll try to run through the scenario: 64-bit register type target (all registers have 64 bits). all 32-bits are getting promoted to 64-bit integers Problem: MUL on i32 is getting promoted to MUL on i64 MUL on i64 is getting expanded to a library call in compiler-rt the problem is that MUL32 gets promoted and then converted into a subroutine call because it is now type i64, even though