Perhaps we need these fixes? https://patchwork.kernel.org/patch/8175541/ On 3 March 2017 at 18:06, Dibyendu Majumdar <mobile@xxxxxxxxxxxxxxx> wrote: > On 3 March 2017 at 07:37, Dibyendu Majumdar <mobile@xxxxxxxxxxxxxxx> wrote: >> On 3 March 2017 at 05:24, Luc Van Oostenryck >> <luc.vanoostenryck@xxxxxxxxx> wrote: >>> This should fox the problems of mixed types in casts. >>> Without much testing but should be essentialy OK. >>> >>> CC: Dibyendu Majumdar <mobile@xxxxxxxxxxxxxxx> >>> --- >>> sparse-llvm.c | 40 +++++++++++++++++++++++++++++++++++----- >>> 1 file changed, 35 insertions(+), 5 deletions(-) >>> >>> diff --git a/sparse-llvm.c b/sparse-llvm.c >>> index edd0615ec..92ad26845 100644 >>> --- a/sparse-llvm.c >>> +++ b/sparse-llvm.c >>> @@ -763,6 +763,8 @@ static void output_op_phi(struct function *fn, struct instruction *insn) >>> static void output_op_ptrcast(struct function *fn, struct instruction *insn) >>> { >>> LLVMValueRef src, target; >>> + LLVMTypeRef dtype; >>> + LLVMOpcode op; >>> char target_name[64]; >>> >>> src = insn->src->priv; >>> @@ -773,15 +775,31 @@ static void output_op_ptrcast(struct function *fn, struct instruction *insn) >>> >>> assert(!symbol_is_fp_type(insn->type)); >>> >>> - target = LLVMBuildBitCast(fn->builder, src, insn_symbol_type(fn->module, insn), target_name); >>> + dtype = insn_symbol_type(fn->module, insn); >>> + switch (LLVMGetTypeKind(LLVMTypeOf(src))) { >>> + case LLVMPointerTypeKind: >>> + op = LLVMBitCast; >>> + break; >>> + case LLVMIntegerTypeKind: >>> + op = LLVMIntToPtr; >>> + break; >>> + default: >>> + assert(0); >>> + } >>> >>> + target = LLVMBuildCast(fn->builder, op, src, dtype, target_name); >>> insn->target->priv = target; >>> } >>> >>> static void output_op_cast(struct function *fn, struct instruction *insn, LLVMOpcode op) >>> { >>> LLVMValueRef src, target; >>> + LLVMTypeRef dtype; >>> char target_name[64]; >>> + unsigned int width; >>> + >>> + if (is_ptr_type(insn->type)) >>> + return output_op_ptrcast(fn, insn); >>> >>> src = insn->src->priv; >>> if (!src) >>> @@ -791,11 +809,23 @@ static void output_op_cast(struct function *fn, struct instruction *insn, LLVMOp >>> >>> assert(!symbol_is_fp_type(insn->type)); >>> >>> - if (insn->size < LLVMGetIntTypeWidth(LLVMTypeOf(src))) >>> - target = LLVMBuildTrunc(fn->builder, src, insn_symbol_type(fn->module, insn), target_name); >>> - else >>> - target = LLVMBuildCast(fn->builder, op, src, insn_symbol_type(fn->module, insn), target_name); >>> + dtype = insn_symbol_type(fn->module, insn); >>> + switch (LLVMGetTypeKind(LLVMTypeOf(src))) { >>> + case LLVMPointerTypeKind: >>> + op = LLVMPtrToInt; >>> + break; >>> + case LLVMIntegerTypeKind: >>> + width = LLVMGetIntTypeWidth(LLVMTypeOf(src)); >>> + if (insn->size < width) >>> + op = LLVMTrunc; >>> + else if (insn->size == width) >>> + op = LLVMBitCast; >>> + break; >>> + default: >>> + assert(0); >>> + } >>> >>> + target = LLVMBuildCast(fn->builder, op, src, dtype, target_name); >>> insn->target->priv = target; >>> } >>> >> >> >> This doesn't quite work. The problem is that in op_cast, the pointer >> is being cast to int, but subsequent operations expect a pointer. >> > > The problem occurs in this sequence: > > ptrcast.64 %r26 <- (64) %r20 > add.64 %r27 <- %r26, %r23 > cast.64 %r28 <- (64) %r27 > store.64 %r28 -> 16[%arg1] > > The last cast finds that the instruction type in an integer and does a > cast to Integer, so that causes the store to fail as it expects a > pointer. > > Question in my mind is what is the result type of an add operation > when one of the arguments is a pointer? > > Regards > Dibyendu -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
