search for: memcpyinst

...rarchy. We have a preference for the first option, but would appreciate thoughts/opinions/discussion on the best way to insert the element atomic intrinsics into the hierarchy. For background, the relevant portion of the current hierarchy looks like: MemIntrinsic * MemSetInst * MemTransferInst ** MemCpyInst ** MemMoveInst Option 1) ------------- Do not add any new classes to the hierarchy. Instead, teach each class to recognize the unordered-atomic variant as belonging to the class (ex: element unordered-atomic memcpy is recognized as a MemCpyInst, MemTransferInst, and a MemIntrinsic), and add a qu...

...Option 2) ------------- Add separate classes to the hierarchy for each intrinsic. There are a few different ways that this could be organized (note: UA* = unordered-atomic version of intrinsic, to save typing): a) Completely disjoint hierarchy UAMemIntrinsic * UAMemSetInst * UAMemTransferInst ** UAMemCpyInst ** UAMemMoveInst MemIntrinsic * MemSetInst * MemTransferInst ** MemCpyInst ** MemMoveInst e) Multiple inheritance This is a variant on options 2b to 2d. To make it possible to easily use isa<> to query for whether or not a memory intrinsic is unordered-atomic or not we could add an interfac...

...%obit = extractvalue {i32, i1} %res, 1 br i1 %obit, label %overflow, label %normal* into an assembly file, and it works OK. And now, my question is "How to produce such a call instruction using the LLVM classes?" I have also noticed that LLVM provides some classes like "*MemCpyInst"* to wrap the "*llvm.memcpy"* Intrinsic. But other intrinsic functions such as *" **llvm.sadd.with.overflow"* I've mentioned above don't have the corresponding classes. How to deal with it? Anyone could help me? Thank you! -------------- next part -------------- An...

...e relative to the pointer. Each instruction takes several bytes, and I am trying to optimize for code size. The Q: What should I do to make the generated code more size-efficient (think `-Os`)? Current ideas, which may not include the best answer: - Store the data as-is in the IR, and use the `MemCpyInst` instead of the store when `get_default_data()` returns something big? - Add a custom -- or any available built-in -- pass to the output to transform the store instns to memcpy when appropriate? Thanks for any help, Boldizsar This message and any attachments are intended for the use of the addre...

...lloc") { > // ... > } > whereas with the malloc instruction raising/lowering pass, you would say > if (MallocInst *MI = dyn_cast<MallocInst>(I)) { Not true at all. Consider the "llvm/IntrinsicInst.h" header, which lets us write stuff like this, today: if (MemCpyInst *MCI = dyn_cast<MemCpyInst>(I)) MCI->getSource() MCI->getLength() ... The one advantage that mallocinst has over using an intrnisic is that instructions can have different return values in various parts of the program (e.g., you can write 'malloc int' instead of '(int...

On Fri, Oct 22, 2004 at 03:18:00PM +0200, Marc Ordinas i Llopis wrote: > I'm currently looking at LLVM as a possible back-end to a dynamic > programming system (in the tradition of Smalltalk) we are developing. Neat! > I have read most of the llvmdev archives, and I'm aware that some > things are 'planned' but not implemented yet. We are willing to > contribute

Hi everybody, I'm currently looking at LLVM as a possible back-end to a dynamic programming system (in the tradition of Smalltalk) we are developing. I have read most of the llvmdev archives, and I'm aware that some things are 'planned' but not implemented yet. We are willing to contribute the code we'll need for our project, but before I can start coding I'll have to

FWIW, +1 from me. Just one request on the implementation though. However we model these intrinsics and their properties (metadata, constants, etc), can we please abstract away those details the same way we have MemCpyInst which just wraps an IntrinsicInst? I think this would be very beneficial if we ever need to add more state, or change something about the underlying implementation, and not have to search all the code for ‘bool traps = cast<ConstantInt>(I->getOperand(1))->getZextValue()’ or whatever it...

----- Original Message ----- > From: "Chandler Carruth" <chandlerc at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov>, "Chandler Carruth" <chandlerc at gmail.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Friday, February 5, 2016 4:36:54 PM > Subject: Re: [llvm-dev] [RFC] FP Environment and Rounding mode

Hi Hal, > If you attach noalias metadata to the memcpy call, it will apply to both the source and destination; we don't have a way to differentiate. It might be true that if you attach both noalias and alias.scope metadata to the call, then querying the call against itself will return NoModRef, but that's really hacky (and, in part, wrong, because the destination still alias with