summaryrefslogtreecommitdiff
path: root/test/CodeGen/X86/memcpy.ll
Commit message (Collapse)AuthorAge
* Convert CodeGen/*/*.ll tests to use the new CHECK-LABEL for easier ↵Stephen Lin2013-07-13
| | | | | | | | | | | debugging. No functionality change and all tests pass after conversion. This was done with the following sed invocation to catch label lines demarking function boundaries: sed -i '' "s/^;\( *\)\([A-Z0-9_]*\):\( *\)test\([A-Za-z0-9_-]*\):\( *\)$/;\1\2-LABEL:\3test\4:\5/g" test/CodeGen/*/*.ll which was written conservatively to avoid false positives rather than false negatives. I scanned through all the changes and everything looks correct. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186258 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix the root cause of PR15348 by correctly handling alignment 0 onChandler Carruth2013-02-25
| | | | | | | | | | | | | | | | | | | | | | | | memory intrinsics in the SDAG builder. When alignment is zero, the lang ref says that *no* alignment assumptions can be made. This is the exact opposite of the internal API contracts of the DAG where alignment 0 indicates that the alignment can be made to be anything desired. There is another, more explicit alignment that is better suited for the role of "no alignment at all": an alignment of 1. Map the intrinsic alignment to this early so that we don't end up generating aligned DAGs. It is really terrifying that we've never seen this before, but we suddenly started generating a large number of alignment 0 memcpys due to the new code to do memcpy-based copying of POD class members. That patch contains a bug that rounds bitfield alignments down when they are the first field. This can in turn produce zero alignments. This fixes weird crashes I've seen in library users of LLVM on 32-bit hosts, etc. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@176022 91177308-0d34-0410-b5e6-96231b3b80d8
* PR14896: Handle memcpy from constant string where the memcpy size is larger ↵Evan Cheng2013-01-10
| | | | | | than the string size. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172124 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix broken check lines.Benjamin Kramer2012-08-17
| | | | | | | | I really need to find a way to automate this, but I can't come up with a regex that has no false positives while handling tricky cases like custom check prefixes. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162097 91177308-0d34-0410-b5e6-96231b3b80d8
* Add a test for the miscompilation my recent ConstantDataArray patches ↵Chris Lattner2012-02-05
| | | | | | | | | introduced, to make sure we don't regress on it in the future. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149803 91177308-0d34-0410-b5e6-96231b3b80d8
* Add Mode64Bit feature and sink it down to MC layer.Evan Cheng2011-07-07
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@134641 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert r122955. It seems using movups to lower memcpy can cause massive ↵Evan Cheng2011-01-07
| | | | | | regression (even on Nehalem) in edge cases. I also didn't see any real performance benefit. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@123015 91177308-0d34-0410-b5e6-96231b3b80d8
* Use movups to lower memcpy and memset even if it's not fast (like corei7).Evan Cheng2011-01-06
| | | | | | | | | The theory is it's still faster than a pair of movq / a quad of movl. This will probably hurt older chips like P4 but should run faster on current and future Intel processors. rdar://8817010 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@122955 91177308-0d34-0410-b5e6-96231b3b80d8
* Re-implement r122936 with proper target hooks. Now getMaxStoresPerMemcpyEvan Cheng2011-01-06
| | | | | | | | etc. takes an option OptSize. If OptSize is true, it would return the inline limit for functions with attribute OptSize. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@122952 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert r122936. I'll re-implement the change.Evan Cheng2011-01-06
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@122949 91177308-0d34-0410-b5e6-96231b3b80d8
* r105228 reduced the memcpy / memset inline limit to 4 with -Os to avoid blowingEvan Cheng2011-01-06
| | | | | | | | | up freebsd bootloader. However, this doesn't make much sense for Darwin, whose -Os is meant to optimize for size only if it doesn't hurt performance. rdar://8821501 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@122936 91177308-0d34-0410-b5e6-96231b3b80d8
* fix PR6623: when optimizing for size, don't inline memcpy/memsetsChris Lattner2010-05-31
| | | | | | | | | | that are too large. This causes the freebsd bootloader to be too large apparently. It's unclear if this should be an -Os or -Oz thing. Thoughts welcome. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105228 91177308-0d34-0410-b5e6-96231b3b80d8
* upgrade and filecheckize this test.Chris Lattner2010-05-31
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105227 91177308-0d34-0410-b5e6-96231b3b80d8
* Add nounwind.Evan Cheng2010-04-05
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100482 91177308-0d34-0410-b5e6-96231b3b80d8
* Eliminate more uses of llvm-as and llvm-dis.Dan Gohman2009-09-08
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81290 91177308-0d34-0410-b5e6-96231b3b80d8
* Refactor the memcpy lowering for the x86 target.Rafael Espindola2007-09-28
The only generated code difference is that now we call memcpy when the size of the array is unknown. This matches GCC behavior and is better since the run time value can be arbitrarily large. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@42433 91177308-0d34-0410-b5e6-96231b3b80d8
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-14 19:01:00 +0000