search for: lowermemintrinsics

...rvatively uses the MinAlign() of the source & dest alignments as the alignment for the loads and stores. I suspect that we could do better by teaching the lowering that the source & dest can have different alignments. Note that, also, the createMem[Cpy|Move]Loop type functions used in the LowerMemIntrinsics pass are also now invoked with different source & dest alignments by LowerMemIntrinsics, rather than the same alignment for both, so these helpers will now be invoked with more information than they have in the past; I’m guessing that it’s possible they could do better with this information. Fo...

...gn() of the source & dest alignments as the > alignment for the loads and stores. I suspect that we could do better by > teaching the lowering that the source & dest can have different alignments. > >  Note that, also, the createMem[Cpy|Move]Loop type functions used in the > LowerMemIntrinsics pass are also now invoked with different source & dest > alignments by LowerMemIntrinsics, rather than the same alignment for both, so > these helpers will now be invoked with more information than they have in the > past; I’m guessing that it’s possible they could do better with this...

Good day all, I’ve spent a few days resurrecting the circa-2015 work on removing the explicit alignment argument (4th arg) from the @llvm.memcpy/memmove/memset intrinsics in favour of using the alignment attribute on the pointer args of calls to the intrinsic. This work was first proposed back in August 2015 by Lang Hames: http://lists.llvm.org/pipermail/llvm-dev/2015-August/089384.html (item

Hi all, For GlobalISel, we’re exploring options for implementing inlining optimizations for memcpy and friends. However, looking around the existing implementation, I don’t see anything that would particularly be problematic for us to do it at the IR level. The existing TLI hooks to specify how certain memcpy calls should be lowered doesn’t have anything too SelectionDAG specific, and an IR