Francois Pichet
2013-Apr-15 21:02 UTC
[LLVMdev] 64-bit add using 2 32-bit operations, guarantee of stuck together?
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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130415/1d049b68/attachment.html>
Jakob Stoklund Olesen
2013-Apr-15 21:12 UTC
[LLVMdev] 64-bit add using 2 32-bit operations, guarantee of stuck together?
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?The register allocator expects to be able to insert spill code and copies between any instructions, except terminators. The only way around that is to use pseudo-instructions that are expanded after RA. /jakob
Quentin Colombet
2013-Apr-15 21:24 UTC
[LLVMdev] 64-bit add using 2 32-bit operations, guarantee of stuck together?
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/8defb8d0/attachment.html>
Francois Pichet
2013-Apr-15 21:37 UTC
[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>
Sam Parker
2013-Apr-16 05:09 UTC
[LLVMdev] 64-bit add using 2 32-bit operations, guarantee of stuck together?
Hi Jakob, If glue operands are used by the scheduler to keep instructions together, why can't the register allocator also do this? Regards, Sam On 15/04/2013 23:12, Jakob Stoklund Olesen wrote:> 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? > The register allocator expects to be able to insert spill code and copies between any instructions, except terminators. > > The only way around that is to use pseudo-instructions that are expanded after RA. > > /jakob > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Apparently Analagous Threads
- [LLVMdev] 64-bit add using 2 32-bit operations, guarantee of stuck together?
- [LLVMdev] 64-bit add using 2 32-bit operations, guarantee of stuck together?
- [LLVMdev] 64-bit add using 2 32-bit operations, guarantee of stuck together?
- [LLVMdev] 64-bit add using 2 32-bit operations, guarantee of stuck together?
- [LLVMdev] 64-bit add using 2 32-bit operations, guarantee of stuck together?