When simplifying a call to a bitcast function, tighten up
authorDuncan Sands <baldrick@free.fr>
Sun, 1 Jun 2008 07:38:42 +0000 (07:38 +0000)
committerDuncan Sands <baldrick@free.fr>
Sun, 1 Jun 2008 07:38:42 +0000 (07:38 +0000)
commitf413cdfb0bd6cd47448e92ceb9614c9e94099b8c
tree52c1f3a91302ca6a119d84482743a4362ee6f14a
parentbdbb750afeb66f3c32aca479119867e44f1da60b
When simplifying a call to a bitcast function, tighten up
the conditions for performing the transform when only the
function declaration is available: no longer allow turning
i32 into i64 for example.  Only allow changing between
pointer types, and between pointer types and integers of
the same size.  For return values ptr -> intptr was already
allowed; I added ptr -> ptr and intptr -> ptr while there.
As shown by a recent objc testcase, changing the way
parameters/return values are passed can be fatal when calling
code written in assembler that directly manipulates call
arguments and return values unless the transform has no
impact on the way they are passed at the codegen level.
While it is possible to imagine an ABI that treats integers
of pointer size differently to pointers, I don't think LLVM
supports any so the transform should now be safe while still
being useful.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51834 91177308-0d34-0410-b5e6-96231b3b80d8
lib/Transforms/Scalar/InstructionCombining.cpp
test/Transforms/InstCombine/apint-call-cast-target.ll