search for: dr32

...ly, ADD operates on anything but address registers and immediates, and ADDA 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,...

...hing but address registers and immediates, and > ADDA 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...

...the following error from LLVM -- # Machine code for function main: Post SSA Frame Objects: fi#0: size=4, align=4, at location [SP] Function Live Outs: %D0L BB#0: derived from LLVM BB %entry ADJCALLSTACKDOWN 6, %A7<imp-def>, %A7<imp-use> %vreg2<def> = COPY %A7; DR32:%vreg2 %vreg1<def> = COPY %vreg2; AR:%vreg1 DR32:%vreg2 MOVElim %vreg1<kill>, 0, 10; mem:ST4[<unknown>](align=2) AR:%vreg1 %vreg2<def,tied1> = ADDlqd %vreg2<tied0>, 4, %CCR<imp-def,dead>; DR32:%vreg2 %vreg3<def> = COPY %vreg2...

...the right value? No. I would suggest doing this as a instruction selection post pass. It would 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...

...No. I would suggest doing this as a instruction selection post pass. > It would 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 re...

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

On Sep 22, 2007, at 10:36 AM, Christopher Lamb <christopher.lamb at gmail.com > wrote: > > On Sep 22, 2007, at 4:05 AM, Andreas Fredriksson wrote: > >> 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

...doing this as a instruction selection post pass. >> It would 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 >&gt...