[PATCH] D12946: Avoid pointer truncation by InstCombine with IntToPtr combining

[Mehdi AMINI via llvm-commits]

joker.eph added a comment.

In http://reviews.llvm.org/D12946#248378, @rampitec wrote:

> It should be possible, but spir producers will still produce address space 0, and then we can hardly fix all potential frontends.


I'm not sure why? 
If LLVM 3.x ships with code address spaces to fix this bug, then either the front-end supports this or it continues generates buggy code (just as now).

> Then again, code address space is still different and in most cases does not alias with data (except for jits and generally self modifying code).


I don't see how it contradicts what I said, on the opposite I think it justify completely having the ability to specify function address space.

> An implementation might create an address space for its code, though target knowledge will need to start with frontends, limiting acceptable inputs.


I'm not sure I understand what you mean here?
Address space are already an opaque contract with the target.

In http://reviews.llvm.org/D12946#248389, @rampitec wrote:

> BTW, even a single code address space is not a good solution. It might serve immediate need, but not good enough as a general abstraction.
>  Back in 286 times there were far and near functions and code pointers. So several code address spaces might be needed for some implementations.


Which is exactly the point of my previous comment: "being able to specify an address space on the function type". You could have one function in address space 0 and another in address space 1.


http://reviews.llvm.org/D12946