llvm dev - Jan 2012 - [LLVMdev] libcalls for shifts

>> 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

Hi,

You're describing the exact same set of requirements for ARM - 64-bit loads
and stores (LDRD, STRD) and multiplications but not shifts, adds, subtracts
or anything else.

ARM uses 32-bits as the largest possible type, and legalizes everything down
to 32-bits. Why don't you do the same?

Cheers,

James 

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Johannes Birgmeier
Sent: 09 January 2012 18:02
To: LLVM Developers Mailing List
Subject: Re: [LLVMdev] libcalls for shifts

>> 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
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

> ARM uses 32-bits as the largest possible type, and legalizes 
everything down to 32-bits. Why don't you do the same?

Hmmm... I have fared very well until now except for the thing with the 
shift libcalls, which somehow don't work as expected when I switch on 
parallel instruction scheduling.

Cheers,
Johannes