rtx structure

Bharati Bhole bharati.bhole@gmail.com
Mon Nov 6 14:24:00 GMT 2006


On 11/6/06, Andrew Haley <aph@redhat.com> wrote:
> Bharati Bhole writes:
>  > On 11/6/06, Andrew Haley <aph@redhat.com> wrote:
>  > > Bharati Bhole writes:
>  > >  > On 11/6/06, Andrew Haley <aph@redhat.com> wrote:
>  > >  > > Bharati Bhole writes:
>  > >  > >  > On 11/2/06, Andrew Haley <aph@redhat.com> wrote:
>  > >  > >  > > Bharati Bhole writes:
>  > >  > >  > >  > On 11/2/06, Daniel Berlin <dberlin@dberlin.org> wrote:
>  > >  > >  > >  > > > I want to know what part of rtx each field in this structure stores.
>  > >  > >  > >  > > > While tracing through gdb i tried to print the rtx, and i was not able
>  > >  > >  > >  > > > to understand that. Could u please explain me it with a sample RTX
>  > >  > >  > >  > > > that what value these fields have.
>  > >  > >  > >  > > >
>  > >  > >  > >  > >
>  > >  > >  > >  > > The macros used to access the rtl fields in rtl.h explain what part of
>  > >  > >  > >  > > each field they access and what they treat that object as.
>  > >  > >  > >  > >
>  > >  > >  > >  > > The definitions of rtl in rtl.def define what each portion of a piece
>  > >  > >  > >  > > of valid RTL is structured as.
>  > >  > >  > >  > > > Bharati.
>  > >  > >  > >  > > >
>  > >  > >  > >  > >
>  > >  > >  > >  >
>  > >  > >  > >  > I have gone through the structure but i still dont get it.
>  > >  > >  > >  > Could anybody please tell me, if the following insn is  a sample insn,
>  > >  > >  > >  > how will the rtx structure look like -
>  > >  > >  > >  >         (define_insn "subsi3_carry_zext"
>  > >  > >  > >  >         [(set (match_operand:DI 0 "register_operand" "=rm,r")
>  > >  > >  > >  >                  (zero_extend:DI
>  > >  > >  > >  >                (minus:SI (match_operand:SI 1 "register_operand" "0,0")
>  > >  > >  > >  >                           (plus:SI (match_operand:SI 3
>  > >  > >  > >  > "ix86_carry_flag_operator" "")
>  > >  > >  > >  >                               (match_operand:SI 2 "general_operand" "ri,rm")))))
>  > >  > >  > >  >           (clobber (reg:CC FLAGS_REG))]
>  > >  > >  > >  >        "TARGET_64BIT && ix86_binary_operator_ok (MINUS, SImode, operands)"
>  > >  > >  > >  >        "sbb{l}\t{%2, %k0|%k0, %2}"
>  > >  > >  > >  >       [(set_attr "type" "alu")
>  > >  > >  > >  >       (set_attr "pent_pair" "pu")
>  > >  > >  > >  >       (set_attr "mode" "SI")])
>  > >  > >  > >
>  > >  > >  > > But this isn't a simple insn, it's a machine description pattern.
>  > >  > >  > > These are described in Section 13, Machine Descriptions.
>  > >  > >
>  > >  > >  > Yes, this is a machine description pattern. In the genrecog.c file the
>  > >  > >  > .md file is read and from each insn the RTL template is filled in the
>  > >  > >  > RTX structure. So i want to know that how this insn ie the RTL teplate
>  > >  > >  > from this insn will be filled in the RTX structure. I mean what part
>  > >  > >  > of the template, each field of RTX structure will store? Could anybody
>  > >  > >  > please tell me that?
>  > >  > >
>  > >  > > Possibly, but it would be better for you to find out for yourself.
>  > >  > > Have you tried putting a breakpoint on make_insn_raw ?
>  > >
>  > >  > The project we are dealing with is related to RTL to ASM conversion
>  > >  > only. This make_insn_raw exists in emit-rtl.c. While debugging
>  > >  > genrecog i tried to print the RTX structure but didn't understand. So
>  > >  > please explain it to me for above insn.
>  > >
>  > > What, all of it?
>  > >
>  > > Show me the debug_rtx of the insn that was generated when you were
>  > > debugging.
>  > >
>  > > Andrew.
>  > >
>  >
>  > This is what i got when i traced through gdb and tried to print RTX structure.
>  >
>  >  desc = read_md_rtx (&pattern_lineno, &next_insn_code);
>  > (gdb) n
>  > 2745          if (desc == NULL)
>  > (gdb)
>  > 2748          switch (GET_CODE (desc))
>  > (gdb) p *desc
>  > $1 = {code = 154, mode = VOIDmode, jump = 0, call = 0, unchanging = 0,
>  > volatil = 0, in_struct = 0, used = 0,
>  >   frame_related = 0, return_val = 0, u = {fld = {{rt_int = 134674728,
>  > rt_uint = 134674728, rt_str = 0x806f928 "cpu",
>  >         rt_rtx = 0x806f928, rt_rtvec = 0x806f928, rt_type = 134674728,
>  > rt_addr_diff_vec_flags = {min_align = 40,
>  >           base_after_vec = 1, min_after_vec = 0, max_after_vec = 0,
>  > min_after_base = 1, max_after_base = 1,
>  >           offset_unsigned = 1, scale = 6}, rt_cselib = 0x806f928,
>  > rt_bit = 0x806f928, rt_tree = 0x806f928,
>  >         rt_bb = 0x806f928, rt_mem = 0x806f928, rt_reg = 0x806f928}},
>  > hwint = {134674728}}}
>
> p debug_rtx(desc)
>
>

(gdb) p *desc
$16 = {code = 136, mode = VOIDmode, jump = 0, call = 0, unchanging =
0, volatil = 0, in_struct = 0, used = 0,
  frame_related = 0, return_val = 0, u = {fld = {{rt_int = 134925076,
rt_uint = 134925076,
        rt_str = 0x80acb14 "fix_truncdfdi2", rt_rtx = 0x80acb14,
rt_rtvec = 0x80acb14, rt_type = 134925076,
        rt_addr_diff_vec_flags = {min_align = 20, base_after_vec = 1,
min_after_vec = 1, max_after_vec = 0,
          min_after_base = 1, max_after_base = 0, offset_unsigned = 0,
scale = 10}, rt_cselib = 0x80acb14,
        rt_bit = 0x80acb14, rt_tree = 0x80acb14, rt_bb = 0x80acb14,
rt_mem = 0x80acb14, rt_reg = 0x80acb14}}, hwint = {
      134925076}}}
(gdb) p debug_rtx(desc)
(define_expand ("fix_truncdfdi2")
     [
        (parallel [
                (set (match_operand:DI 0 ("nonimmediate_operand") (""))
                    (fix:DI (match_operand:DF 1 ("register_operand") (""))))
                (clobber (reg:CC 17 [0]))
            ])
    ] ("TARGET_80387 || (TARGET_64BIT && TARGET_SSE2)") ("{
  if (TARGET_64BIT && TARGET_SSE2)
   {
     rtx out = REG_P (operands[0]) ? operands[0] : gen_reg_rtx (DImode);
     emit_insn (gen_fix_truncdfdi_sse (out, operands[1]));
     if (out != operands[0])
        emit_move_insn (operands[0], out);
     DONE;
   }
}"))
$17 = void

Bharati.



More information about the Gcc-help mailing list