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