Variable order and location within the section - optimization level dependent

Variable order and location within the section - optimization level dependent

[Janáček Jiří]

Hello all,

We have discussed the topic regarding the compiler flag  -fno-toplevel-reorder and relative stuff at the GCC ARM forum (https://answers.launchpad.net/gcc-arm-embedded/+question/237324).

GCC documentation (http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options) states:

"Do not reorder top-level functions, variables, and asm statements. Output them in the same order that they appear in the input file. When this option is used, unreferenced static variables are not removed. This option is intended to support existing code that relies on a particular ordering. For new code, it is better to use attributes."


The major question sounds - which attributes should be applied in such a case?

Many thanks in advance,
Best regards,
JiriJ

Re: Variable order and location within the section - optimization level dependent

[Ian Lance Taylor]

On Wed, Oct 16, 2013 at 4:25 AM, Janáček Jiří <jiri.janacek@skoda.cz> wrote:
>
> We have discussed the topic regarding the compiler flag  -fno-toplevel-reorder and relative stuff at the GCC ARM forum (https://answers.launchpad.net/gcc-arm-embedded/+question/237324).
>
> GCC documentation (http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options) states:
>
> "Do not reorder top-level functions, variables, and asm statements. Output them in the same order that they appear in the input file. When this option is used, unreferenced static variables are not removed. This option is intended to support existing code that relies on a particular ordering. For new code, it is better to use attributes."
>
>
> The major question sounds - which attributes should be applied in such a case?

Well, what are you trying to do?

There are various different things that people used to do based on
specific ordering in the source file.  One common use was to force
functions into particular sections by writing code like

asm (".section mysec");
int f() { return 0; }
asm (".text");

The way to do that without relying on -fno-toplevel-reorder is to use
an attribute for the function.

int f() __attribute__ ((section ("mysec")));
int f() { return 0; }

Ian

RE: Variable order and location within the section - optimization level dependent

[Janáček Jiří]

Hello Ian,

I do know this approach. I have created sections with the appropriate address ranges and located the variables into those sections by the below mentioned attribute.
If no optimization is turned on, then the order (means also the address offset of the variable) is correct.
If -O1 is turned on, the variables order within the section is exactly opposite.
If -O1 is turned on and the flag -fno-toplevel-reorder is turned on as well, then the order is equal to the requested one. But I would like to apply such a behavior (no reorder) just for some variables in some modules. Other modules should be optimized by -O1 level.
So I am curious which attributes can define this behavior.

Hope this clarifies that a bit.

Thanks,
JiriJ


-----Original Message-----
From: Ian Lance Taylor [mailto:iant@google.com] 
Sent: Wednesday, October 16, 2013 3:56 PM
To: Janáček Jiří
Cc: gcc-help@gcc.gnu.org
Subject: Re: Variable order and location within the section - optimization level dependent

On Wed, Oct 16, 2013 at 4:25 AM, Janáček Jiří <jiri.janacek@skoda.cz> wrote:
>
> We have discussed the topic regarding the compiler flag  -fno-toplevel-reorder and relative stuff at the GCC ARM forum (https://answers.launchpad.net/gcc-arm-embedded/+question/237324).
>
> GCC documentation (http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options) states:
>
> "Do not reorder top-level functions, variables, and asm statements. Output them in the same order that they appear in the input file. When this option is used, unreferenced static variables are not removed. This option is intended to support existing code that relies on a particular ordering. For new code, it is better to use attributes."
>
>
> The major question sounds - which attributes should be applied in such a case?

Well, what are you trying to do?

There are various different things that people used to do based on specific ordering in the source file.  One common use was to force functions into particular sections by writing code like

asm (".section mysec");
int f() { return 0; }
asm (".text");

The way to do that without relying on -fno-toplevel-reorder is to use an attribute for the function.

int f() __attribute__ ((section ("mysec"))); int f() { return 0; }

Ian

Re: Variable order and location within the section - optimization level dependent

[Ian Lance Taylor]

On Wed, Oct 16, 2013 at 7:06 AM, Janáček Jiří <jiri.janacek@skoda.cz> wrote:
>
> I do know this approach. I have created sections with the appropriate address ranges and located the variables into those sections by the below mentioned attribute.
> If no optimization is turned on, then the order (means also the address offset of the variable) is correct.
> If -O1 is turned on, the variables order within the section is exactly opposite.
> If -O1 is turned on and the flag -fno-toplevel-reorder is turned on as well, then the order is equal to the requested one. But I would like to apply such a behavior (no reorder) just for some variables in some modules. Other modules should be optimized by -O1 level.
> So I am curious which attributes can define this behavior.

Please don't top-post.  Thanks.

It sounds like you are saying that you want to have your global
variables appear in a specific order in a specific section.

There is no attribute that will make that happen.  Sorry.  The obvious
workaround would be to use a struct.

Ian

RE: Variable order and location within the section - optimization level dependent

[Janáček Jiří]

-----Original Message-----
From: Ian Lance Taylor [mailto:iant@google.com] 
Sent: Wednesday, October 16, 2013 4:30 PM
To: Janáček Jiří
Cc: gcc-help@gcc.gnu.org
Subject: Re: Variable order and location within the section - optimization level dependent

On Wed, Oct 16, 2013 at 7:06 AM, Janáček Jiří <jiri.janacek@skoda.cz> wrote:
>
> I do know this approach. I have created sections with the appropriate address ranges and located the variables into those sections by the below mentioned attribute.
> If no optimization is turned on, then the order (means also the address offset of the variable) is correct.
> If -O1 is turned on, the variables order within the section is exactly opposite.
> If -O1 is turned on and the flag -fno-toplevel-reorder is turned on as well, then the order is equal to the requested one. But I would like to apply such a behavior (no reorder) just for some variables in some modules. Other modules should be optimized by -O1 level.
> So I am curious which attributes can define this behavior.

Please don't top-post.  Thanks.

It sounds like you are saying that you want to have your global variables appear in a specific order in a specific section.

There is no attribute that will make that happen.  Sorry.  The obvious workaround would be to use a struct.

Ian

------------------

Hello Ian,

Right, the obvious solution is to apply a struct - originally I intended to avoid this way (there are some internal reasons for that).
IMHO the description of the "-fno-toplevel-reorder" flag (http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options) is a bit confusing - I mean especially this section: "For new code, it is better to use attributes.”

Thanks for your support,
JiriJ

Re: Variable order and location within the section - optimization level dependent

[Ian Lance Taylor]

On Thu, Oct 17, 2013 at 12:46 AM, Janáček Jiří <jiri.janacek@skoda.cz> wrote:
>
> Right, the obvious solution is to apply a struct - originally I intended to avoid this way (there are some internal reasons for that).
> IMHO the description of the "-fno-toplevel-reorder" flag (http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options) is a bit confusing - I mean especially this section: "For new code, it is better to use attributes.”

I understand that you found it confusing.  But I have to say, even on
re-reading and re-thinking, I think the statement is correct.  For new
code, it is better to use attributes.  I don't think that says or
implies that there is an attribute that means the same thing as
-fno-toplevel-reorder.

You've decided to follow a path that GCC does not support with
attributes.  That is your choice.  There are other approaches you
could use, that GCC does support directly, and for some reason they
won't work for you.  But fortunately there is a choice that works for
you: the -fno-toplevel-reorder option.  So it seems that all is well.

Ian

Re: Variable order and location within the section - optimization level dependent

[Fabian Cenedese]

At 09:02 17.10.2013 -0700, Ian Lance Taylor wrote:
>On Thu, Oct 17, 2013 at 12:46 AM, Janáček Jiří <jiri.janacek@skoda.cz> wrote:
>>
>> Right, the obvious solution is to apply a struct - originally I intended to avoid this way (there are some internal reasons for that).
>> IMHO the description of the "-fno-toplevel-reorder" flag (http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options) is a bit confusing - I mean especially this section: "For new code, it is better to use attributes.”
>
>I understand that you found it confusing.  But I have to say, even on
>re-reading and re-thinking, I think the statement is correct.  For new
>code, it is better to use attributes.  I don't think that says or
>implies that there is an attribute that means the same thing as
>-fno-toplevel-reorder.

I'll have to side with the OP here. We also use code that relies on the order
of the toplevel items so we need to use the no-reorder flag, no problem there.
So I was eagerly reading this thread to find other ways to achieve the same
result (there don't seem to be, that's okay).

However reading the documentation I find it hard to see any other meaning
than that "there are attributes that do the same as -fno-toplevel-reorder". If
there aren't any attributes for this precise case then what's this sentence
doing in the -fno-toplevel-reorder section?

>You've decided to follow a path that GCC does not support with
>attributes.  That is your choice.  There are other approaches you
>could use, that GCC does support directly, and for some reason they
>won't work for you.  But fortunately there is a choice that works for
>you: the -fno-toplevel-reorder option.  So it seems that all is well.

I think these approaches where one could use attributes to influence
the ordering should be mentioned here and also where it's not possible.
Otherwise people might start looking for these attributes that don't
exist (at least 2 people now :)

Besides the nitpicking: Thanks for a great product and the help on
this list (or elsewhere)

bye  Fabi

Re: Variable order and location within the section - optimization level dependent

[Ian Lance Taylor]

On Mon, Oct 21, 2013 at 2:46 AM, Fabian Cenedese <Cenedese@indel.ch> wrote:
>
> I'll have to side with the OP here. We also use code that relies on the order
> of the toplevel items so we need to use the no-reorder flag, no problem there.
> So I was eagerly reading this thread to find other ways to achieve the same
> result (there don't seem to be, that's okay).
>
> However reading the documentation I find it hard to see any other meaning
> than that "there are attributes that do the same as -fno-toplevel-reorder". If
> there aren't any attributes for this precise case then what's this sentence
> doing in the -fno-toplevel-reorder section?

Well, OK.  I just committed a patch to add "when possible," so the
sentence now reads "For new code, it is better to use attributes when
possible."


> I think these approaches where one could use attributes to influence
> the ordering should be mentioned here and also where it's not possible.
> Otherwise people might start looking for these attributes that don't
> exist (at least 2 people now :)

I don't know how to enumerate the cases because I don't know what
people use -fno-toplevel-reorder for.

I continue to believe that it is always possible to rework your code
using attributes.  For the OP's case a struct plus #define macros
would have addressed the case, until the code was very unusual.

Ian