This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RTL definition
"Fran Baena" <franbaena@gmail.com> writes:
>> By the way, RTL is not really machine-independent. The data
>> structures are machine independent. But the contents are not. You
>> can not, even in principle, take the RTL generated for one processor
>> and compile it on another processor.
>
> I thought that RTL represented something close to the target machine,
> but not machine-dependent. I firstly thought that the output of the
> middle-end was an RTL machine-independent representation, to which is
> applied a few low-optimization machine-independent passes, and after
> that is translated to a RTL machine-dependent to be applied other
> optimization passes.
RTL is created using named patterns in the MD file, so even the
creation process is machine-dependent. This is most obvious in the
use of unspec, but it is true in general.
> I read the rtl.def and rtl.h files, are very interesting, and i better
> understand the whole process. But reading the output files by debuggin
> options (-fdump-rtl-all) i have seen instructions like this:
>
> (insn 8 6 10 1 (set (mem/c/i:SI (plus:DI (reg/f:DI 54 virtual-stack-vars)
> (const_int -8 [0xfffffffffffffff8])) [0 a+0 S4 A64])
> (const_int 1 [0x1])) -1 (nil)
> (nil))
>
> Among the multiple questions that appears i have a particular one,
> what does "8 6 10 1" represents? Is it the "print format" defined in
> rtl.def?
8 is in the INSN uid. 6 is the previous INSN uid. 10 is the next
insn UID. 1 is the number of the basic block holding the insn. In
general RTL is printed according to the format in rtl.def. There are
a couple of exceptions; one of those exceptions is that field 4 of an
insn, INSN_LOCATOR, is only printed if it is present. See line 391 of
print-rtl.c.
Ian