[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