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

[Mekhanoshin, Stanislav via llvm-commits]

It should be possible, but spir producers will still produce address space 0, and then we can hardly fix all potential frontends. 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). An implementation might create an address space for its code, though target knowledge will need to start with frontends, limiting acceptable inputs.

Actually I do not see an ideal solution.

Stas



On September 17, 2015 4:05:44 PM Mehdi AMINI <mehdi.amini at apple.com> wrote:

> joker.eph added a comment.
>
> This is what I expected from the previous patch, it seems backed everywhere in LLVM that functions are in address space 0. I wonder if the solution would be not to add a "code address space" to the DataLayout but rather being able to specify an address space on the function type itself.
>
>
> ================
> Comment at: lib/Transforms/InstCombine/InstCombineCasts.cpp:1452
> @@ -1451,1 +1451,3 @@
> +      !CI.getType()->getPointerElementType()->isFunctionTy()) {
> +    // The size of a pointer to function is not defined by any DataLayout field
>      Type *Ty = DL.getIntPtrType(CI.getContext(), AS);
> ----------------
> Put the comment before the added condition maybe?
>
> ================
> Comment at: test/Transforms/InstCombine/combine-func-ptr.ll:5
> @@ +4,3 @@
> +;
> +; CHECK: trunc
> +
> ----------------
> Shouldn't it be at CHECK-NOT?
>
>
> Repository:
>   rL LLVM
>
> http://reviews.llvm.org/D12946