I give up.

I give up.

[Jonathan Wilson]

I cant find anything on google about the various RTL functions (like 
gen_rtx_UNSPEC).
I cant find anything in the GCC docs.
And I cant find anything in the source code for these specific functions (I 
cant even FIND their code)

I give up.

[Andrew Haley]

Jonathan Wilson writes:
 > I cant find anything on google about the various RTL functions (like 
 > gen_rtx_UNSPEC).
 > I cant find anything in the GCC docs.
 > And I cant find anything in the source code for these specific functions (I 
 > cant even FIND their code)

It's generated automagically from the .md file.  Look at
build/gcc/genrtl.h.

Andrew.

Re: I give up.

[Jonathan Wilson]

ok, that tells me where the code is.
But that still doesnt tell me what any of the 1000s of different functions 
that relate to RTL actually DO.

What I need to output is something like this:
mov rega, dword ptr ds:__tls_index
mov regb, dword ptr fs:__tls_array
mov regc, [rega+regb*4]
then to get the address itself (ready to insert into the instruction), you do:
dword ptr ds:var[regc]

rega,regb,regc are registers
var is the address of the thread-local variable relative to the start of 
the segment that it resides in (and of course will be modified by the 
linker when all the segments are combined)

BTW, pre-calculating the value for regc isnt possible (because __tls_index 
can be changed at any time)

I have looked in all the code, all the manuals, all the documentation and 
all the resources that turn up on google but I still cant figure out how to 
do what I need :(.

I suspect that, since its target specific, someone that knows the i?86 
backend is going to need to help me.

Re: I give up.

[Bernd Jendrissek]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Oct 22, 2003 at 06:55:06PM +0800, Jonathan Wilson wrote:
> I cant find anything on google about the various RTL functions (like 
> gen_rtx_UNSPEC).

gcc/rtl.def:

/* A machine-specific operation.
   1st operand is a vector of operands being used by the operation so that
     any needed reloads can be done.
   2nd operand is a unique value saying which of a number of machine-specific
     operations is to be performed.
   (Note that the vector must be the first operand because of the way that
   genrecog.c record positions within an insn.)
   This can occur all by itself in a PATTERN, as a component of a PARALLEL,
   or inside an expression.  */
DEF_RTL_EXPR(UNSPEC, "unspec", "Ei", 'x')

So an UNSPEC can be anything you want it to be.

> I cant find anything in the GCC docs.
> And I cant find anything in the source code for these specific functions (I 
> cant even FIND their code)

Such as... (yesterday) gen_rtx_REG?  That's in emit-rtl.c.  As for
gen_rtx_UNSPEC, I don't know.  Bear in mind that there are about a dozen
or so C files that are *generated* during the build.  Sometimes what
you're looking for is in there instead, or in the generator program.

Don't give up!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE/lnio/FmLrNfLpjMRAiKBAJ0ZxY41Eg5KpV3LI7wRWtwhPWqLAACfWXsJ
dIS+dcl+1mbyURkgMkExaDw=
=puZp
-----END PGP SIGNATURE-----

Re: I give up.

[Jonathan Wilson]

> Such as... (yesterday) gen_rtx_REG?  That's in emit-rtl.c.  As for
> gen_rtx_UNSPEC, I don't know.  Bear in mind that there are about a dozen
> or so C files that are *generated* during the build.  Sometimes what
> you're looking for is in there instead, or in the generator program.
I did finally find all the bits of code (for example in genrtl.c).
But all that has done is made me even more confused as to just WTF all 
these functions are actually for.

What I am looking for is a "guide to emitting RTL in GCC on i?86 
processors". Or if such a thing doesnt exist, someone out there who knows 
how to do what it is that I am trying to do and can tell me.
Because after staring at the code, the docs, the (in this case) usless 
google search results and the back-postings to this list, I am still no 
closer to figuring out how functions like gen_rtx_UNSPEC, gen_rtx_CONST, 
gen_reg_rtx, gen_subsi3, emit_insn, gen_rtx_SET and so on actually transfer 
to the x86 assembler instructions that appear in the output thats fed to 
GAS :'(

Normally, the usual response to "the docs, google and list archives" didnt 
help (when it comes to open source projects) is "go read the code".
However in this case, what is one supposed to do when you have already read 
the code and even that didnt help?

Re: I give up.

[Andrew Haley]

Jonathan Wilson writes:
 > > Such as... (yesterday) gen_rtx_REG?  That's in emit-rtl.c.  As for
 > > gen_rtx_UNSPEC, I don't know.  Bear in mind that there are about a dozen
 > > or so C files that are *generated* during the build.  Sometimes what
 > > you're looking for is in there instead, or in the generator program.
 > I did finally find all the bits of code (for example in genrtl.c).
 > But all that has done is made me even more confused as to just WTF all 
 > these functions are actually for.
 > 
 > What I am looking for is a "guide to emitting RTL in GCC on i?86 
 > processors". Or if such a thing doesnt exist, someone out there who knows 
 > how to do what it is that I am trying to do and can tell me.
 > Because after staring at the code, the docs, the (in this case) usless 
 > google search results and the back-postings to this list, I am still no 
 > closer to figuring out how functions like gen_rtx_UNSPEC, gen_rtx_CONST, 
 > gen_reg_rtx, gen_subsi3, emit_insn, gen_rtx_SET and so on actually transfer 
 > to the x86 assembler instructions that appear in the output thats fed to 
 > GAS :'(

Look at i386.c.  There's a ton of examples there, such as this one in
ix86_expand_epilogue :

	  rtx tmp, sa = EH_RETURN_STACKADJ_RTX;

	  if (frame_pointer_needed)
	    {
	      tmp = gen_rtx_PLUS (Pmode, hard_frame_pointer_rtx, sa);
	      tmp = plus_constant (tmp, UNITS_PER_WORD);
	      emit_insn (gen_rtx_SET (VOIDmode, sa, tmp));

	      tmp = gen_rtx_MEM (Pmode, hard_frame_pointer_rtx);
	      emit_move_insn (hard_frame_pointer_rtx, tmp);

	      emit_insn (gen_pro_epilogue_adjust_stack
			 (stack_pointer_rtx, sa, const0_rtx));
	    }
	  else
	    {
	      tmp = gen_rtx_PLUS (Pmode, stack_pointer_rtx, sa);
	      tmp = plus_constant (tmp, (frame.to_allocate
                                         + frame.nregs * UNITS_PER_WORD));
	      emit_insn (gen_rtx_SET (VOIDmode, stack_pointer_rtx, tmp));
	    }
	}

which generates code to adjust registers, read and write memory, and
so on.  emit_insn() pushes an insn into the insn stream, which is then
optimized and converted to assembler.

Segment registers are a bit tricky.

 > Normally, the usual response to "the docs, google and list archives" didnt 
 > help (when it comes to open source projects) is "go read the code".
 > However in this case, what is one supposed to do when you have already read 
 > the code and even that didnt help?

That's still true.

Andrew.

Grokking GCC [Was: Re: I give up.]

[Bernd Jendrissek]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Oct 22, 2003 at 09:11:35PM +0800, Jonathan Wilson wrote:
> >Such as... (yesterday) gen_rtx_REG?  That's in emit-rtl.c.  As for
> >gen_rtx_UNSPEC, I don't know.  Bear in mind that there are about a dozen
> >or so C files that are *generated* during the build.  Sometimes what
> >you're looking for is in there instead, or in the generator program.
> I did finally find all the bits of code (for example in genrtl.c).
> But all that has done is made me even more confused as to just WTF all 
> these functions are actually for.

I think I empathise with your predicament...

> What I am looking for is a "guide to emitting RTL in GCC on i?86 
> processors". Or if such a thing doesnt exist, someone out there who knows 
> how to do what it is that I am trying to do and can tell me.
> Because after staring at the code, the docs, the (in this case) usless 

... but I think the solution is to stare at the code a little (much)
longer.  I feel like only now, after 3 years of on-and-off looking and
lurking am I beginning to understand some of the pieces.  More
importantly, I feel I know which parts I can ignore as being "some
compiler guru obviously knows what's going on here; I don't, so I'll
just leave it".  Don't let my "3 years" quote discourage you: if I
didn't have a Real Job (tm) it'd probably be much, much less than that.

Oh, and BTW, actually *messing around* has helped me tremendously: I've
been working on a 16-bit x86 port with lots of tips and links from other
people.  A bit of a learning-through-immersion thing, I think.

> google search results and the back-postings to this list, I am still no 
> closer to figuring out how functions like gen_rtx_UNSPEC, gen_rtx_CONST, 
> gen_reg_rtx, gen_subsi3, emit_insn, gen_rtx_SET and so on actually transfer 
> to the x86 assembler instructions that appear in the output thats fed to 
> GAS :'(

AFAICT there's some heavy magic going on in GCC, practically having a
built-in LISP interpreter.  I think you generate that LISP-like RTL with
all those gen_rtx_* functions (that may themselves be generated), which
the "instruction recogniser" then matches to the patterns in the machine
description.  Those instruction patterns then specify what the assembly
output will be.

I'm not sure why you (think you) need to fret over all that RTL
generation if you just want to implement TLS on mingw?  Okay, a bit, but
I can't imagine it'd be all that much...

Oh, another hint I've found useful: this is all GPL'ed stuff.  Copy and
paste with gay abandon, then edit.  You can try to understand it all
later.  (Disclaimer: this is probably bad advice.)  Then fill in
asignment form(s).  There is no "their code/my code" dichotomy I
perceive in the evil proprietary software development world in which I
work.  :)

> Normally, the usual response to "the docs, google and list archives" didnt 
> help (when it comes to open source projects) is "go read the code".
> However in this case, what is one supposed to do when you have already read 
> the code and even that didnt help?

Oh, don't mean to sound arrogant, but have you tried "info gccint" (a
*separate* manual for GCC internals)?  Between it, the code and the
mailing list I don't find life too hard.  Women are much harder to hack.

Read the code some more, I think.  Repeat if necessary.

bernd
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE/lprG/FmLrNfLpjMRApaQAJ93SvXzNseCrqWo4gL2B/m6x/LDVACgpla6
UgeCJStzLfKRgBxajmit9Ew=
=nCeT
-----END PGP SIGNATURE-----

P.S. BTW, is all of Oz going nuts with Thugby like they are here in
South Africa?  What with the world cup being there and all...

Re: I give up.

[Mike Stump]

On Wednesday, October 22, 2003, at 03:55  AM, Jonathan Wilson wrote:
> I cant find anything on google about the various RTL functions (like 
> gen_rtx_UNSPEC).

google isn't quite the right tool for this.

> I cant find anything in the GCC docs.

Read an memorize them all, that way, you will trivially know everything 
in them, and you won't have to find much.  Seriously though, M-x grep, 
then '\<unspec\>' doc/*.texi finds 6 hits in 1/2 second or less.  And 
from that, we can read up on unspec and what it does.  After you step 
around in code you want to work in, you start noticing things, like 
function that start with gen_ usually generate things, what what they 
generate is given by the rest of the name (and maybe in the arguments). 
  What you see this pattern, you will just know that gen_unspec 
generates an unspec, and a quick glace at the texi file tells you in 
rough terms what an unspec is.

Think of them as self-contained black boxes, into which the compiler 
doesn't peer.

> And I cant find anything in the source code for these specific 
> functions (I cant even FIND their code)

Standard technique 3:

Just fire up emacs, type M-x gdb, then gdb cc1, then set a breakpoint 
just before the area you are interested in, then type step and you can 
watch it go into the routine you're interested in. Emacs will just pull 
up the source code for you automagically.

handy gcc specific knowledge:

In time, you realize all source code is in gcc/*.[ch] gcc/config/*.[ch] 
gcc/config/*/*.[ch] and in the build directory in gcc/*.[ch], and that 
make TAGS will build an index for you, and M-. in emacs will take you 
to just about any of them, though not things in the build tree like 
gen_rtx_UNSPEC.

Re: I give up

[Phil Edwards]

On Fri, Dec 28, 2001 at 12:51:48AM -0600, Finny Merrill wrote:
> What in hell does this piece of greek mean? I have NO idea what it means, 
> it only happens when I compile in release mode, with all optimizations 
> turned on.
[an ICE occurs]
> 
> 99% sure it's an assembler error
> but that looks like LISP!!

Welcome to the guts of GCC.  I say that because GCC just puked its guts
onto your lap.  :-)

That's how GCC represents its internal state when the state needs to be
displayed on-screen, and yes, it was deliberately designed to resemble LISP.

It's not an assembler error because your build never made it that far; it's
an internal compiler error.  Normally GCC will print something useful like
"Internal Compiler Error" before printing the guts, but earlier versions
like the one that Red Hat shipped didn't always do so.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: I give up

[Jakub Jelinek]

On Fri, Dec 28, 2001 at 02:06:24AM -0600, Finny Merrill wrote:
> On Fri, 28 Dec 2001, Andris Pavenis wrote:
> 
> > On Friday 28 December 2001 08:51, Finny Merrill wrote:
> > > What in hell does this piece of greek mean? I have NO idea what it means,
> > > it only happens when I compile in release mode, with all optimizations
> > > turned on.
> > 
> > Which gcc version? 
> > 
> [griever@linux linux]$ gcc -v
> Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
> gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98)
> [griever@linux linux]$ 

Then you shouldn't report it to gcc mailing list, but to Red Hat instead.
Please file a bug at http://bugzilla.redhat.com/bugzilla/, include
preprocessed source and gcc options.  Thanks.

	Jakub

Re: I give up

[Andris Pavenis]

On Friday 28 December 2001 10:06, Finny Merrill wrote:
> On Fri, 28 Dec 2001, Andris Pavenis wrote:
> > On Friday 28 December 2001 08:51, Finny Merrill wrote:
> > > What in hell does this piece of greek mean? I have NO idea what it
> > > means, it only happens when I compile in release mode, with all
> > > optimizations turned on.
> >
> > Which gcc version?
>
> [griever@linux linux]$ gcc -v
> Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
> gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98)
> [griever@linux linux]$
>
> > Does the problem go away if command line options -fomit-frame-pointer
> > or/and (possibly some other one) is removed?
>
> Yes, omit-frame-pointer is the cause
>
> > If You're using gcc-3.0, 3.0.1 or 3.0.2 then please try gcc-3.0.3 as
> > earlier gcc-3.0.X versions had problems with option -fomit-frame-pointer
> > (PR#4529, PR#4763 and maybe some others in GCC GNATS database)

You may try to look whether it is possible to apply fix (one line only) to 
RedHat versions of GCC (I don't know as I'm not using RedHat distribution). 
See:

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=4529&database=gcc

for details.

Andris

Re: I give up

[Finny Merrill]

On Fri, 28 Dec 2001, Andris Pavenis wrote:

> On Friday 28 December 2001 08:51, Finny Merrill wrote:
> > What in hell does this piece of greek mean? I have NO idea what it means,
> > it only happens when I compile in release mode, with all optimizations
> > turned on.
> 
> Which gcc version? 
> 
[griever@linux linux]$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98)
[griever@linux linux]$ 

> Does the problem go away if command line options -fomit-frame-pointer
> or/and (possibly some other one) is removed?

Yes, omit-frame-pointer is the cause

> 
> If You're using gcc-3.0, 3.0.1 or 3.0.2 then please try gcc-3.0.3 as earlier
> gcc-3.0.X versions had problems with option -fomit-frame-pointer
> (PR#4529, PR#4763 and maybe some others in GCC GNATS database)
> 

Re: I give up

[Andris Pavenis]

On Friday 28 December 2001 08:51, Finny Merrill wrote:
> What in hell does this piece of greek mean? I have NO idea what it means,
> it only happens when I compile in release mode, with all optimizations
> turned on.

Which gcc version? 

Does the problem go away if command line options -fomit-frame-pointer
or/and (possibly some other one) is removed?

If You're using gcc-3.0, 3.0.1 or 3.0.2 then please try gcc-3.0.3 as earlier
gcc-3.0.X versions had problems with option -fomit-frame-pointer
(PR#4529, PR#4763 and maybe some others in GCC GNATS database)

>
> gcc -Dstricmp=strcasecmp -g -mpentiumpro -O6 -ffast-math -funroll-loops
> -fomit-frame-pointer -fexpensive-optimizations -fPIC -o
> releasei386-glibc/game/p_client.o -c ../game/p_client.c
> ../game/p_client.c: In function `ClientThink':
> ../game/p_client.c:1754: Insn does not satisfy its constraints:
> (insn:TI 1970 2078 1971 (parallel[
>             (set (mem:HI (plus:SI (reg:SI 6 ebp)
>                         (const_int -274 [0xfffffeee])) 0)
>                 (fix:HI (reg:SF 8 st(0))))
>             (clobber (mem:SI (plus:SI (reg:SI 6 ebp)
>                         (const_int -272 [0xfffffef0])) 0))
>             (clobber (mem:HI (plus:SI (reg:SI 6 ebp)
>                         (const_int -274 [0xfffffeee])) 0))
>             (clobber (reg:SI 6 ebp))
>         ] ) 97 {*fix_trunchi_1} (insn_list 1734 (insn_list:REG_DEP_ANTI
> 1961 (insn_list:REG_DEP_ANTI 567 (insn_list:REG_DEP_ANTI 559
> (insn_list:REG_DEP_ANTI 561 (insn_list:REG_DEP_ANTI 563
> (insn_list:REG_DEP_ANTI 1962 (insn_list:REG_DEP_ANTI 1821
> (insn_list:REG_DEP_ANTI 1824 (insn_list:REG_DEP_ANTI 576
> (insn_list:REG_DEP_ANTI 1705 (insn_list 1827 (insn_list:REG_DEP_ANTI 1704
> (insn_list:REG_DEP_ANTI 1964 (insn_list:REG_DEP_ANTI 1965
> (insn_list:REG_DEP_ANTI 1708 (insn_list:REG_DEP_ANTI 1710
> (insn_list:REG_DEP_ANTI 1966 (insn_list:REG_DEP_ANTI 1967
> (insn_list:REG_DEP_ANTI 1713 (insn_list:REG_DEP_ANTI 1727
> (insn_list:REG_DEP_ANTI 1968 (insn_list:REG_DEP_ANTI 1969
> (insn_list:REG_DEP_ANTI 1731 (insn_list:REG_DEP_ANTI 1733
> (nil))))))))))))))))))))))))))
>     (expr_list:REG_DEAD (reg:SF 8 st(0))
>         (nil)))
> ../game/p_client.c:1754: confused by earlier errors, bailing out
>
> 99% sure it's an assembler error
> but that looks like LISP!!

I give up

[Finny Merrill]

What in hell does this piece of greek mean? I have NO idea what it means, 
it only happens when I compile in release mode, with all optimizations 
turned on.

gcc -Dstricmp=strcasecmp -g -mpentiumpro -O6 -ffast-math -funroll-loops 
-fomit-frame-pointer -fexpensive-optimizations -fPIC -o 
releasei386-glibc/game/p_client.o -c ../game/p_client.c
../game/p_client.c: In function `ClientThink':
../game/p_client.c:1754: Insn does not satisfy its constraints:
(insn:TI 1970 2078 1971 (parallel[ 
            (set (mem:HI (plus:SI (reg:SI 6 ebp)
                        (const_int -274 [0xfffffeee])) 0)
                (fix:HI (reg:SF 8 st(0))))
            (clobber (mem:SI (plus:SI (reg:SI 6 ebp)
                        (const_int -272 [0xfffffef0])) 0))
            (clobber (mem:HI (plus:SI (reg:SI 6 ebp)
                        (const_int -274 [0xfffffeee])) 0))
            (clobber (reg:SI 6 ebp))
        ] ) 97 {*fix_trunchi_1} (insn_list 1734 (insn_list:REG_DEP_ANTI 
1961 (insn_list:REG_DEP_ANTI 567 (insn_list:REG_DEP_ANTI 559 
(insn_list:REG_DEP_ANTI 561 (insn_list:REG_DEP_ANTI 563 
(insn_list:REG_DEP_ANTI 1962 (insn_list:REG_DEP_ANTI 1821 
(insn_list:REG_DEP_ANTI 1824 (insn_list:REG_DEP_ANTI 576 
(insn_list:REG_DEP_ANTI 1705 (insn_list 1827 (insn_list:REG_DEP_ANTI 1704 
(insn_list:REG_DEP_ANTI 1964 (insn_list:REG_DEP_ANTI 1965 
(insn_list:REG_DEP_ANTI 1708 (insn_list:REG_DEP_ANTI 1710 
(insn_list:REG_DEP_ANTI 1966 (insn_list:REG_DEP_ANTI 1967 
(insn_list:REG_DEP_ANTI 1713 (insn_list:REG_DEP_ANTI 1727 
(insn_list:REG_DEP_ANTI 1968 (insn_list:REG_DEP_ANTI 1969 
(insn_list:REG_DEP_ANTI 1731 (insn_list:REG_DEP_ANTI 1733 
(nil))))))))))))))))))))))))))
    (expr_list:REG_DEAD (reg:SF 8 st(0))
        (nil)))
../game/p_client.c:1754: confused by earlier errors, bailing out

99% sure it's an assembler error
but that looks like LISP!!