[LLVMdev] Incompatible types at call site

[Arushi Aggarwal]

Unoptimized IR


 %tmp63 = call %struct.TypHeader* (...)* bitcast (%struct.TypHeader*
(%struct.TypHeader*, i64, i64)* @Cyclotomic to %struct.TypHeader*
(...)*)(%struct.TypHeader* %tmp62, i64 %tmp24, i32 1) nounwind, !dbg !907 ;
<%struct.TypHeader*> [#uses=1]

Optimized IR


 %tmp63 = call%struct.TypHeader*
(%struct.TypHeader*, i64, i64)* @Cyclotomic (%struct.TypHeader* %tmp62, i64
%tmp24, i64 1) nounwind
<%struct.TypHeader*> [#uses=1]

The way InstCombine manages this, is (from InstCombineCalls.cpp:1039)

    if ((*AI)->getType() == ParamTy) {
      Args.push_back(*AI);
    } else {
      Instruction::CastOps opcode = CastInst::getCastOpcode(*AI,
          false, ParamTy, false);
      Args.push_back(Builder->CreateCast(opcode, *AI, ParamTy, "tmp"));
    }

When it asks for the castOpcode, it assumes both types are
unsigned(indicated by the false arguments).

Is it correct to assume this?

Thanks,
Arushi

On Tue, Apr 5, 2011 at 1:57 PM, Arushi Aggarwal <arushi987 at gmail.com> wrote:

>
>
> On Tue, Apr 5, 2011 at 1:44 PM, Duncan Sands <baldrick at free.fr> wrote:
>
>> Hi Arushi,
>>
>>
>>   %tmp63 = call %struct.TypHeader* (...)* bitcast (%struct.TypHeader*
>>> (%struct.TypHeader*, i64, i64)* @Cyclotomic to %struct.TypHeader*
>>> (...)*)(%struct.TypHeader* %tmp62, i64 %tmp24, i32 1) nounwind, !dbg !907
>>> ;
>>> <%struct.TypHeader*> [#uses=1]
>>>
>>> the 3rd parameter is now used in an srem statement. How do we know what
>>> value is
>>> used? Does this use decide whether the value is sign extended or zero
>>> extended?
>>>
>>
>> inside the called function the 3rd value will contain rubbish.  That's
>> because
>> the function takes an i64 parameter but via the bitcast you pretend it
>> takes an
>> i32 parameter, which is wrong.  This is not the correct way to pass an i32
>> to a
>> function that takes an i64.  Where did you get this IR from?
>>
>
> This is unoptimized IR, generated for a SPEC example.
>
> The optimized IR, converts this call to
>
>  %tmp63 = call%struct.TypHeader*
> (%struct.TypHeader*, i64, i64)* @Cyclotomic (%struct.TypHeader* %tmp62, i64
> %tmp24, i64 1) nounwind
> <%struct.TypHeader*> [#uses=1]
>
> I was just wondering what the logic was to infer when such conversions
> could be made.
>
>>
>> Ciao, Duncan.
>>
>> PS: It may not contain rubbish in practice, in particular probably the
>> lower 32
>> bits will have the "right" value, but nothing guarantees that.
>>
>>
>>> Arushi
>>>
>>> On Tue, Apr 5, 2011 at 1:35 AM, Duncan Sands <baldrick at free.fr
>>> <mailto:baldrick at free.fr>> wrote:
>>>
>>>    Hi Arushi,
>>>
>>>     > For a call like this,
>>>     >
>>>     > %tmp6 = call i32 (...)* bitcast (i32 (i8*, i8, i8**)* @ssplit to
>>> i32
>>>    (...)*)(i8*
>>>     > %tmp599, i32 46, i8** %domainv3) nounwind ; <i32>
>>>     >
>>>     > does the 2nd argument get zero extended or sign extended?
>>>
>>>    neither since it does not have the zext or sext attribute.
>>>
>>>    Ciao, Duncan.
>>>    _______________________________________________
>>>    LLVM Developers mailing list
>>>    LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>
>>> http://llvm.cs.uiuc.edu
>>>
>>>    http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110405/51ab00ac/attachment.html>