llvm dev - Apr 2013 - [LLVMdev] 64-bit add using 2 32-bit operations, guarantee of stuck together?

I really have to force them to stuck together otherwise the carry will just
not work.

How about wrapping the 2 instructions in a bundle?
Would that be a way?
http://llvm.org/docs/CodeGenerator.html#machineinstr-bundles


On Mon, Apr 15, 2013 at 5:24 PM, Quentin Colombet <qcolombet at
apple.com>wrote:
> Hi Francois,
>
> If you model the effect of your carry on the instructions, the scheduler
> (and the other backend passes) should ensure that nothing that affects the
> carry will be inserted between your two instructions (assuming they are
> issued with nothing affecting the carry in between in the first place).
> Therefore, you shouldn’t have to force them to be stuck together.
>
> If you still do, what Jakob proposed is what you are looking for.
>
> -Quentin
>
> On Apr 15, 2013, at 2:02 PM, Francois Pichet <pichet2000 at
gmail.com> wrote:
>
> Hi,
>
> Let's say we have a 32-bit architecture where 64-bit additions are done
> using 2 operations.
>
> Instructions are defined as follow in TableGen:
>    defm ADD64  : ALU32<"add", 1, 1, addc>;
>    defm ADD64C : ALU32<"addrc", 1, 2, adde>;
>
>
> Let's assume that the carry bit is implicit and that the 2 operations
must
> *always* be stuck together for the 64-bit add to work properly.
> Is there a default guarantee that nothing will ever be inserted between
> "add" and "addrc" or is there a flag/condition to set
somewhere to have
> that guarantee?
>
> Thanks
>
> _______________________________________________
> LLVM Developers mailing list
> 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/20130415/847f096b/attachment.html>

Using bundles here looks like a fragile way to handle that, IMHO.
Really, using a pseudo instruction seems the best approach for you.

For instance, you can match your add64 during isel with your pseudo instruction
and expand it just before emitting the assembly file (add a pass using the hook:
addPreEmitPass on your target).

-Quentin

On Apr 15, 2013, at 2:37 PM, Francois Pichet <pichet2000 at gmail.com>
wrote:
> 
> I really have to force them to stuck together otherwise the carry will just
not work.
> 
> How about wrapping the 2 instructions in a bundle?
> Would that be a way?
> http://llvm.org/docs/CodeGenerator.html#machineinstr-bundles
> 
> 
> On Mon, Apr 15, 2013 at 5:24 PM, Quentin Colombet <qcolombet at
apple.com> wrote:
> Hi Francois,
> 
> If you model the effect of your carry on the instructions, the scheduler
(and the other backend passes) should ensure that nothing that affects the carry
will be inserted between your two instructions (assuming they are issued with
nothing affecting the carry in between in the first place).
> Therefore, you shouldn’t have to force them to be stuck together.
> 
> If you still do, what Jakob proposed is what you are looking for.
> 
> -Quentin
> 
> On Apr 15, 2013, at 2:02 PM, Francois Pichet <pichet2000 at
gmail.com> wrote:
> 
>> Hi,
>> 
>> Let's say we have a 32-bit architecture where 64-bit additions are
done using 2 operations.
>> 
>> Instructions are defined as follow in TableGen:
>>    defm ADD64  : ALU32<"add", 1, 1, addc>;
>>    defm ADD64C : ALU32<"addrc", 1, 2, adde>;
>> 
>> 
>> Let's assume that the carry bit is implicit and that the 2
operations must *always* be stuck together for the 64-bit add to work properly.
>> Is there a default guarantee that nothing will ever be inserted between
"add" and "addrc" or is there a flag/condition to set
somewhere to have that guarantee?
>> 
>> Thanks
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> 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/20130415/4e477e97/attachment.html>

I agree.   Take a look at the ARM backend instructions which operate on 2x32-bit
registers as a 64 bit output.   Look at things marked TwoOperandAliasConstraint
in the tablegen files to see how they do this.

-Gordon

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Quentin Colombet
Sent: Monday, April 15, 2013 6:00 PM
To: Francois Pichet
Cc: LLVM Developers Mailing List
Subject: Re: [LLVMdev] 64-bit add using 2 32-bit operations, guarantee of stuck
together?

Using bundles here looks like a fragile way to handle that, IMHO.
Really, using a pseudo instruction seems the best approach for you.

For instance, you can match your add64 during isel with your pseudo instruction
and expand it just before emitting the assembly file (add a pass using the hook:
addPreEmitPass on your target).

-Quentin

On Apr 15, 2013, at 2:37 PM, Francois Pichet <pichet2000 at
gmail.com<mailto:pichet2000 at gmail.com>> wrote:



I really have to force them to stuck together otherwise the carry will just not
work.

How about wrapping the 2 instructions in a bundle?
Would that be a way?
http://llvm.org/docs/CodeGenerator.html#machineinstr-bundles


On Mon, Apr 15, 2013 at 5:24 PM, Quentin Colombet <qcolombet at
apple.com<mailto:qcolombet at apple.com>> wrote:
Hi Francois,

If you model the effect of your carry on the instructions, the scheduler (and
the other backend passes) should ensure that nothing that affects the carry will
be inserted between your two instructions (assuming they are issued with nothing
affecting the carry in between in the first place).
Therefore, you shouldn't have to force them to be stuck together.

If you still do, what Jakob proposed is what you are looking for.

-Quentin

On Apr 15, 2013, at 2:02 PM, Francois Pichet <pichet2000 at
gmail.com<mailto:pichet2000 at gmail.com>> wrote:

Hi,

Let's say we have a 32-bit architecture where 64-bit additions are done
using 2 operations.

Instructions are defined as follow in TableGen:
   defm ADD64  : ALU32<"add", 1, 1, addc>;
   defm ADD64C : ALU32<"addrc", 1, 2, adde>;


Let's assume that the carry bit is implicit and that the 2 operations must
*always* be stuck together for the 64-bit add to work properly.
Is there a default guarantee that nothing will ever be inserted between
"add" and "addrc" or is there a flag/condition to set
somewhere to have that guarantee?

Thanks

_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu>        
http://llvm.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/20130427/92b68826/attachment.html>