[LLVMdev] libcalls for shifts

Johannes Birgmeier e0902998 at student.tuwien.ac.at
Mon Jan 9 10:01:45 PST 2012


>> Yes, well, i64 is a legal type, that's how it is. However, i64s are
>> always stored in two 32-bit registers and in some cases need complicated
>> instruction patterns for easy things (such as add, sub and so on) that
>> basically simulate the i64 behaviour with a sequence of i32
>> instructions.
> I think you're misunderstanding what it means for a type to be "legal"
> on a target.  If you don't have a single i64 addition instruction on
> i64 registers, you shouldn't be marking i64 as a legal type.  You can
> custom-lower certain operations on i64 if there's some instruction
> sequence which is better than the default expansion.

I don't think so.
Single-instruction support for i64 exists in instructions such as 
storing and loading from memory and multiplication.
For other instructions, such as converting to and from other data types, 
division, remainder etc., libcalls exist.
Other instructions can and will be simulated by a sequence of i32 
instructions. I thought that a target supports a datatype when it can 
produce the correct semantics for all necessary operations on that 
datatype, regardless of whether single instructions exist for all 
operations on that datatype.

Should a developer refrain from using 64-bit values just because they 
don't fit into a single register, or because add takes three instead of 
one instruction? For most of the i64 operations, LLVM doesn't even know 
of a default expansion, and yet i64 is certainly not illegal because its 
semantics can be produced validly in a variety of ways. I have i64 
instruction patterns for add, single-instruction support for mul, custom 
lowering for sub, and a number of libcalls for other instructions.

But I've already found the right method in LegalizeDAG.cpp and will add 
support for shift libcalls, so thanks for your help :)

Regards,
Johannes



More information about the llvm-dev mailing list