public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* code gen for C string literals
@ 2011-02-12 20:20 kevin diggs
  2011-02-14  5:10 ` Ian Lance Taylor
  0 siblings, 1 reply; 8+ messages in thread
From: kevin diggs @ 2011-02-12 20:20 UTC (permalink / raw)
  To: gcc-help

Hi,

I would like to play with the code gcc generates for string literals.
Can someone point me to the relevant files and/or to some
documentation that describes the inner workings?

Thanks!

kevin

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: code gen for C string literals
  2011-02-12 20:20 code gen for C string literals kevin diggs
@ 2011-02-14  5:10 ` Ian Lance Taylor
  2011-02-14 16:43   ` kevin diggs
  0 siblings, 1 reply; 8+ messages in thread
From: Ian Lance Taylor @ 2011-02-14  5:10 UTC (permalink / raw)
  To: kevin diggs; +Cc: gcc-help

kevin diggs <diggskevin38@gmail.com> writes:

> I would like to play with the code gcc generates for string literals.
> Can someone point me to the relevant files and/or to some
> documentation that describes the inner workings?

The preprocessor turns a string literal into a CPP_STRING token.  The
parser turns that into a STRING_CST node in GENERIC.  The RTL expander
stores the string constant into the constant pool and works with a
symbol pointing to the address.

This and the various string literal optimizations are scattered across
various files.  Search for CPP_STRING and STRING_CST to see the kinds of
things that gcc does.

Ian

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: code gen for C string literals
  2011-02-14  5:10 ` Ian Lance Taylor
@ 2011-02-14 16:43   ` kevin diggs
  2011-02-14 17:47     ` Ian Lance Taylor
  0 siblings, 1 reply; 8+ messages in thread
From: kevin diggs @ 2011-02-14 16:43 UTC (permalink / raw)
  To: Ian Lance Taylor; +Cc: gcc-help

Hi,

Thanks for the reply.

I did manage to stumble across the gcc internals doc.

"in GENERIC"??? Is this the initial RTL output?

Assuming the size does not bust through a processors offset addressing
capabilities, something similar should be doable for accessing things
in any section (clustered section access optimization). I just figure
that string literals are far more common. Off the top of your head do
you know what I would search for for something like:

int im_a_global_int;

which would be treated similarly to a string literal (at least as far
as how it is accessed), right?

kevin

On Sun, Feb 13, 2011 at 11:00 PM, Ian Lance Taylor <iant@google.com> wrote:
>
> The preprocessor turns a string literal into a CPP_STRING token.  The
> parser turns that into a STRING_CST node in GENERIC.  The RTL expander
> stores the string constant into the constant pool and works with a
> symbol pointing to the address.
>
> This and the various string literal optimizations are scattered across
> various files.  Search for CPP_STRING and STRING_CST to see the kinds of
> things that gcc does.
>
> Ian
>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: code gen for C string literals
  2011-02-14 16:43   ` kevin diggs
@ 2011-02-14 17:47     ` Ian Lance Taylor
  2011-02-15 17:25       ` kevin diggs
  0 siblings, 1 reply; 8+ messages in thread
From: Ian Lance Taylor @ 2011-02-14 17:47 UTC (permalink / raw)
  To: kevin diggs; +Cc: gcc-help

kevin diggs <diggskevin38@gmail.com> writes:

> "in GENERIC"??? Is this the initial RTL output?

GENERIC is the name for the tree representation used by the C frontend.
Since a string literal only appears in an operand, STRING_CST is what
you will see in GIMPLE as well.

> Assuming the size does not bust through a processors offset addressing
> capabilities, something similar should be doable for accessing things
> in any section (clustered section access optimization). I just figure
> that string literals are far more common. Off the top of your head do
> you know what I would search for for something like:
>
> int im_a_global_int;
>
> which would be treated similarly to a string literal (at least as far
> as how it is accessed), right?

That's a very general question and I'm not sure just how to answer it.
At the GENERIC/GIMPLE level that is just a variable.  At the RTL level
it will turn into a memory address (a MEM).

Ian

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: code gen for C string literals
  2011-02-14 17:47     ` Ian Lance Taylor
@ 2011-02-15 17:25       ` kevin diggs
  2011-02-15 19:42         ` Ian Lance Taylor
  0 siblings, 1 reply; 8+ messages in thread
From: kevin diggs @ 2011-02-15 17:25 UTC (permalink / raw)
  To: Ian Lance Taylor; +Cc: gcc-help

On Mon, Feb 14, 2011 at 11:46 AM, Ian Lance Taylor <iant@google.com> wrote:
> kevin diggs <diggskevin38@gmail.com> writes:
>
>> "in GENERIC"??? Is this the initial RTL output?
>
> GENERIC is the name for the tree representation used by the C frontend.
> Since a string literal only appears in an operand, STRING_CST is what
> you will see in GIMPLE as well.
>
>> that string literals are far more common. Off the top of your head do
>> you know what I would search for for something like:
>>
>> int im_a_global_int;
>>
>> which would be treated similarly to a string literal (at least as far
>> as how it is accessed), right?
>
> That's a very general question and I'm not sure just how to answer it.
> At the GENERIC/GIMPLE level that is just a variable.  At the RTL level
> it will turn into a memory address (a MEM).
>
I am asking if there is something like STRING_CST that the frontend
will return for for global'ish (i.e. non-auto stuff that is found from
locations other than the stack) data items that I can similarly search
the code for.

Thanks!

kevin

P.S.:  If you would be so kind as to jot down a sentence or two as to
what GIMPLE (some other frontends' tree?) is and how it relates to
SIMPLE (C frontend tree representation) I would REALLY appreciate it!
Ditto for something called SSA?

> Ian
>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: code gen for C string literals
  2011-02-15 17:25       ` kevin diggs
@ 2011-02-15 19:42         ` Ian Lance Taylor
  2011-02-15 20:03           ` kevin diggs
  0 siblings, 1 reply; 8+ messages in thread
From: Ian Lance Taylor @ 2011-02-15 19:42 UTC (permalink / raw)
  To: kevin diggs; +Cc: gcc-help

kevin diggs <diggskevin38@gmail.com> writes:

> I am asking if there is something like STRING_CST that the frontend
> will return for for global'ish (i.e. non-auto stuff that is found from
> locations other than the stack) data items that I can similarly search
> the code for.

No.  Unless you count MEM.

> P.S.:  If you would be so kind as to jot down a sentence or two as to
> what GIMPLE (some other frontends' tree?) is and how it relates to
> SIMPLE (C frontend tree representation) I would REALLY appreciate it!
> Ditto for something called SSA?

GIMPLE is the representation used by the middle-end.  GENERIC is the
tree representation used by the C and C++ frontends, and also used by
GIMPLE for operands and types.  Both the C and C++ frontends extend
GENERIC with frontend specific tree codes; thus, both frontends use a
tree representation, and GENERIC is the shared subset of their tree
representations.

SIMPLE is a different intermediate representation used by a different
compiler, which influenced the designed of GENERIC and then GIMPLE used
by gcc.

SSA is a compiler optimization technique which heavily influences the
design of the intermediate representation.  See
http://en.wikipedia.org/wiki/Static_single_assignment_form .

Ian

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: code gen for C string literals
  2011-02-15 19:42         ` Ian Lance Taylor
@ 2011-02-15 20:03           ` kevin diggs
  2011-02-15 23:11             ` Ian Lance Taylor
  0 siblings, 1 reply; 8+ messages in thread
From: kevin diggs @ 2011-02-15 20:03 UTC (permalink / raw)
  To: Ian Lance Taylor; +Cc: gcc-help

Hi,

As always, thanks for the replies.

On Tue, Feb 15, 2011 at 11:25 AM, Ian Lance Taylor <iant@google.com> wrote:
> kevin diggs <diggskevin38@gmail.com> writes:
>
>
> GIMPLE is the representation used by the middle-end.

??? what is the relationship between GIMPLE and RTL, which at my VERY
EARLY understanding of what goes on under the hood I would have
thought was the middle-end representation? Is RTL "the back-end
representation" (my guess would have been asm though maybe that is the
output)?

>
> SSA is a compiler optimization technique which heavily influences the
> design of the intermediate representation.  See
> http://en.wikipedia.org/wiki/Static_single_assignment_form .
>
Is SSA new? i.e. in what gcc version did it start getting used?

Thanks!

kevin

> Ian
>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: code gen for C string literals
  2011-02-15 20:03           ` kevin diggs
@ 2011-02-15 23:11             ` Ian Lance Taylor
  0 siblings, 0 replies; 8+ messages in thread
From: Ian Lance Taylor @ 2011-02-15 23:11 UTC (permalink / raw)
  To: kevin diggs; +Cc: gcc-help

kevin diggs <diggskevin38@gmail.com> writes:

> On Tue, Feb 15, 2011 at 11:25 AM, Ian Lance Taylor <iant@google.com> wrote:
>> kevin diggs <diggskevin38@gmail.com> writes:
>>
>>
>> GIMPLE is the representation used by the middle-end.
>
> ??? what is the relationship between GIMPLE and RTL, which at my VERY
> EARLY understanding of what goes on under the hood I would have
> thought was the middle-end representation? Is RTL "the back-end
> representation" (my guess would have been asm though maybe that is the
> output)?

Yes, RTL is also a representation used by the middle-end.  RTL is much
more machine specific than GIMPLE.  The middle-end starts with the
conversion to GIMPLE.  It runs a bunch of general optimization passes.
Then the GIMPLE is converted to RTL.  Then comes a few more optimization
passes, then stuff like register allocation, instruction scheduling, and
final code generation.


>> SSA is a compiler optimization technique which heavily influences the
>> design of the intermediate representation.  See
>> http://en.wikipedia.org/wiki/Static_single_assignment_form .
>>
> Is SSA new? i.e. in what gcc version did it start getting used?

SSA was introduced into gcc in version 4.0.

Ian

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2011-02-15 21:38 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-02-12 20:20 code gen for C string literals kevin diggs
2011-02-14  5:10 ` Ian Lance Taylor
2011-02-14 16:43   ` kevin diggs
2011-02-14 17:47     ` Ian Lance Taylor
2011-02-15 17:25       ` kevin diggs
2011-02-15 19:42         ` Ian Lance Taylor
2011-02-15 20:03           ` kevin diggs
2011-02-15 23:11             ` Ian Lance Taylor

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).