summaryrefslogtreecommitdiffstats
path: root/llvm/lib
diff options
context:
space:
mode:
authorTobias Grosser <tobias@grosser.es>2015-09-29 06:44:38 +0000
committerTobias Grosser <tobias@grosser.es>2015-09-29 06:44:38 +0000
commit98b3ee50ffd76e4df6e9e83c7466a4410d81ea6d (patch)
treebd819da2241f8c42652c63d19fed86e0a2f9a0bf /llvm/lib
parentf51df5ba8c4512dbeb7828ac0c34f89177b551d6 (diff)
downloadbcm5719-llvm-98b3ee50ffd76e4df6e9e83c7466a4410d81ea6d.tar.gz
bcm5719-llvm-98b3ee50ffd76e4df6e9e83c7466a4410d81ea6d.zip
Codegen: Support memory accesses with different types
Every once in a while we see code that accesses memory with different types, e.g. to perform operations on a piece of memory using type 'float', but to copy data to this memory using type 'int'. Modeled in C, such codes look like: void foo(float A[], float B[]) { for (long i = 0; i < 100; i++) *(int *)(&A[i]) = *(int *)(&B[i]); for (long i = 0; i < 100; i++) A[i] += 10; } We already used the correct types during normal operations, but fall back to our detected type as soon as we import changed memory access functions. For these memory accesses we may generate invalid IR due to a mismatch between the element type of the array we detect and the actual type used in the memory access. To address this issue, we always cast the newly created address of a memory access back to the type of the memory access where the address will be used. llvm-svn: 248781
Diffstat (limited to 'llvm/lib')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud