[LLVMdev] Incompatible types at call site
arushi987 at gmail.com
Tue Apr 5 11:57:03 PDT 2011
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
> inside the called function the 3rd value will contain rubbish. That's
> 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
I was just wondering what the logic was to infer when such conversions could
> 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.
>> 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
>> > %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>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev