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>