search for: add_32_dx_dx

...ould operate on DAGs so you still get the benefit of SDNode CSE, etc. Scheduling and register allocation happen later. Let me clarify. Write "generic" instructions, i.e. those that use / def DR32, with patterns. So right after isel, all the DAG nodes will be of the dx variant, e.g. ADD_32_dx_dx. Also write AR instruction variants such as ADDA_32_dx. These do not have patterns so they aren't used during selection. Add a post pass to replace load / store operands by replacing them with identical nodes except for the "correct" opcodes. I think this mechanism will work....

...works on address registers only so I'm going to need both instructions in my instruction set. These are the two problematic definitions; by themselves they produce the intented effect. AR is the address register class, DR32 is the data register class (no overlap): // 32-bit add DR->DR def ADD_32_dx_dx : I<(outs DR32:$dst), (ins DR32:$src1, DR32:$src2), "add.l $src2, $dst", [(set DR32:$dst, (add DR32:$src2, DR32:$src1))]>; // 32-bit add DR->AR def ADDA_32_dx : I<(outs AR:$dst), (ins AR:$src1, DR32:$src2), "adda.l $src2, $dst", [(set AR:$dst, (add AR:$src1, DR32:$s...

...ons down the line would be to make more sophisticated > patterns that select to instructions that operate on the right > register classes from the start, or to have a custom machine > instruction pass similar to x86's operand folding which could swap > instructions (say from ADD_32_dx_dx to ADDA_32_dx) and perform the > kind of "ripple up" that you described, eliminating unnecessary > register to register copies along the way. > > -- > Christopher Lamb > > > > _______________________________________________ > LLVM Developers mailing list...

...Gs so you still get the benefit of SDNode CSE, > etc. Scheduling and register allocation happen later. > > Let me clarify. Write "generic" instructions, i.e. those that use / > def DR32, with patterns. So right after isel, all the DAG nodes will > be of the dx variant, e.g. ADD_32_dx_dx. Also write AR instruction > variants such as ADDA_32_dx. These do not have patterns so they > aren't used during selection. Add a post pass to replace load / store > operands by replacing them with identical nodes except for the > "correct" opcodes. > > I think this...

...location. Some options down the line would be to make more sophisticated patterns that select to instructions that operate on the right register classes from the start, or to have a custom machine instruction pass similar to x86's operand folding which could swap instructions (say from ADD_32_dx_dx to ADDA_32_dx) and perform the kind of "ripple up" that you described, eliminating unnecessary register to register copies along the way. -- Christopher Lamb -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-de...

On 9/21/07, Christopher Lamb <christopher.lamb at gmail.com> wrote: > ISel patterns are matched against DAGs before register allocation. So you > are correct that ISel patterns can't take into account register classes. The > register classes in the patterns are a selection constraint for the register > allocator if that instruction is chosen, not a constraint on choosing

On 9/24/07, Evan Cheng <evan.cheng at apple.com> wrote: > I am going to suggest something shocking. :) Since you will end up writing a > bunch of target specific code anyway, you might a well write a target > specific pass that change generic instructions into data register variant > ones when necessary. Hi Evan, wouldn't this generate fairly terrible code if each address

...#39;m going to need both > instructions in my instruction set. > > These are the two problematic definitions; by themselves they produce > the intented effect. AR is the address register class, DR32 is the > data register class (no overlap): > > // 32-bit add DR->DR > def ADD_32_dx_dx : I<(outs DR32:$dst), (ins DR32:$src1, DR32:$src2), > "add.l $src2, $dst", [(set DR32:$dst, (add DR32:$src2, DR32:$src1))]>; > > // 32-bit add DR->AR > def ADDA_32_dx : I<(outs AR:$dst), (ins AR:$src1, DR32:$src2), "adda.l > $src2, $dst", [(set AR:$dst...

...the benefit of SDNode CSE, >> etc. Scheduling and register allocation happen later. >> >> Let me clarify. Write "generic" instructions, i.e. those that use / >> def DR32, with patterns. So right after isel, all the DAG nodes will >> be of the dx variant, e.g. ADD_32_dx_dx. Also write AR instruction >> variants such as ADDA_32_dx. These do not have patterns so they >> aren't used during selection. Add a post pass to replace load / store >> operands by replacing them with identical nodes except for the >> "correct" opcodes. >&g...