Re: What kind of data would be put into code section?
Hi R0b0t1,
Thanks for your reply!
That helps me a lot, and now I know it's a more complicated question
than I've thought.
I'm using GCC on X86_64, more specially, on linux x86_64. I also find
that when compiling with -O2, GCC will emits some data(like const
string or const int) into .text. I wonder if I could forbid this by
setting some GCC optimization options? I want to eliminate such data
in the code sections, and put them into data sections.
2017-06-28 12:40 GMT+08:00 R0b0t1 :
> On Tue, Jun 27, 2017 at 11:00 PM, Benxi Liu wrote:
>> Hello everyone,
>> I'm using GCC 5.4.0. I know that in some situations, GCC will put
>> data into .text section, to improve performance. I know one case is
>> jump table, but I'm still curious about other cases. What kind of data
>> will be put into executable sections? Is there any way to avoid this?
>> Any ideas?
>
> This is rather hard to answer because what .text and .data actually
> are depends very heavily on the target architecture. Except for very
> specific optimizations it doesn't matter. When it does, the compiler
> knows better than you.
>
> On von Neumann machines there is effectively no difference between
> .text and .data (or .bss) so the location of information is simply a
> nicety for the programmer. As far as optimizations go you could put
> data into .text when you need to ensure that it is very close in
> memory to the code that operates on it, but on modern machines
> instruction and data caches are separate. The vast majority of
> optimizations rely on reducing the number of comparisons and ensuring
> execution is as linear as possible. Where memory is located matters
> far less than what you are doing with it and how you are doing it.
>
> On Harvard architecture machines .text and .data are different and
> usually wildly so. Most simple microcontrollers treat .data in a
> special way - on the device it exists in the program memory, but the
> standard library loads it in to RAM at runtime. It is common to want
> more information available than can readily be loaded into memory.
> This is accomplished by marking the relevant variables with
> __attribute__((section(".rodata"))), __ATTR_PROGMEM__, PROGMEM, etc
> (implementation dependent). They must be swapped into and out of RAM
> manually using special instructions for reading the program memory.
> These instructions may have special forms for reading sequential
> blocks of memory, and the memory controller may perform best when
> reading sequentially. In these cases how you organize your data
> matters, but reading program memory with the relevant instructions is
> still separate (always, as far as I know) from the instruction fetcher
> that is always reading program memory for the processor, so there's no
> inherent benefit to interleaving code and data.
>
> R0b0t1.
GCC 6 branch now frozen for upcoming GCC 6.4 release
All changes require release manager approval. Thanks, Richard.
Re: What kind of data would be put into code section?
On 28/06/17 05:00, Benxi Liu wrote:
> I'm using GCC 5.4.0. I know that in some situations, GCC will put
> data into .text section, to improve performance. I know one case is
> jump table, but I'm still curious about other cases. What kind of data
> will be put into executable sections? Is there any way to avoid this?
> Any ideas?
On ARM, PC-relative loads have a fairly short range. So:
float d() {
return 3.141592653589;
}
d:
ldr s0, .LC0
ret
.align 2
.LC0:
.word 1078530011
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd.
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
GCC 6.4 Release Candidate available from gcc.gnu.org
A release candidate for GCC 6.4 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/6.4.0-RC-20170628/ and shortly its mirrors. It has been generated from SVN revision 249715. I have so far bootstrapped and tested the release candidate on x86_64-unknown-linux-gnu. Please test it and report any issues to bugzilla. If all goes well I'd like to release 6.4 on Tuesday, July 4th.
Question about IPA and ordering of terms
Hi All,
I noticed something weird with IPA and I'm wondering if it's a bug or not.
Given these two functions
double
check_d_pos (double x, double y)
{
return x * __builtin_copysign (1.0, y);
}
double
check_d_neg (double x, double y)
{
return __builtin_copysign (-1.0, y) * x;
}
and current trunk I get as expected the following GIMPLE tree
check_d_pos (double x, double y)
{
doubleD.31 D.3134;
_1 = copysignD.107 (1.0e+0, yD.3126);
D.3134 = xD.3125 * _1;
return D.3134;
}
check_d_neg (double x, double y)
{
doubleD.31 D.3136;
_1 = copysignD.107 (1.0e+0, yD.3130);
D.3136 = xD.3129 * _1;
return D.3136;
}
GIMPLE seems to have the invariant that all variables appear before anything
else? so it's correctly gimplified the functions in a manner
that makes them the same.
however by the time it gets to expand something odd has happend:
fix_loop_structure: fixing up loops for function
check_d_pos (doubleD.31 xD.3125, doubleD.31 yD.3126)
{
doubleD.31 x_3(D) = xD.3125;
doubleD.31 y_2(D) = yD.3126;
doubleD.31 _1;
doubleD.31 _4;
;; basic block 2, loop depth 0, freq 1, maybe hot
;;prev block 0, next block 1, flags: (NEW, REACHABLE, VISITED)
;;pred: ENTRY [100.0%] (FALLTHRU,EXECUTABLE)
_1 = copysignD.107 (1.0e+0, y_2(D));
_4 = _1 * x_3(D);
# VUSE <.MEM_5(D)>
return _4;
;;succ: EXIT [100.0%] (EXECUTABLE)
}
check_d_neg (doubleD.31 xD.3129, doubleD.31 yD.3130)
{
doubleD.31 x_1(D) = xD.3129;
doubleD.31 y_2(D) = yD.3130;
doubleD.31 D.3153;
doubleD.31 retval.2D.3143;
doubleD.31 _5;
doubleD.31 _6;
;; basic block 2, loop depth 0, freq 1, maybe hot
;;prev block 0, next block 1, flags: (NEW, REACHABLE)
;;pred: ENTRY [100.0%] (FALLTHRU)
_5 = copysignD.107 (1.0e+0, y_2(D));
_6 = x_1(D) * _5;
_7 = _6;
retval.2_3 = _7;
# VUSE <.MEM_4(D)>
return retval.2_3;
;;succ: EXIT [100.0%]
}
noticed it has swapped the order of the terms to the *. This re-ordering seems
to make it miss optimizations in expr.c e.g. expand_expr_real_2
which I think still rely on the invariant GIMPLE first introduced.
What's happening is that IPA decides that the functions are similar enough and
replaces the body of one of the functions with a call to the other:
check_d_neg (double x, double y)
{
double retval.2;
[100.00%] [count: INV]:
retval.2_3 = check_d_pos (x_1(D), y_2(D)); [tail call]
return retval.2_3;
}
check_d_pos (double x, double y)
{
double _1;
double _4;
[100.00%] [count: INV]:
_1 = __builtin_copysign (1.0e+0, y_2(D));
_4 = _1 * x_3(D);
return _4;
}
It then later decides to undo this and so generates a different order. Question
is, is this unexpected or should optimizations in expand be checking for
associativity?
Thanks,
Tamar
Re: Question about IPA and ordering of terms
On June 28, 2017 6:10:27 PM GMT+02:00, Tamar Christina
wrote:
>Hi All,
>
>I noticed something weird with IPA and I'm wondering if it's a bug or
>not.
>
>Given these two functions
>
>double
>check_d_pos (double x, double y)
>{
> return x * __builtin_copysign (1.0, y);
>}
>
>double
>check_d_neg (double x, double y)
>{
> return __builtin_copysign (-1.0, y) * x;
>}
>
>and current trunk I get as expected the following GIMPLE tree
>
>check_d_pos (double x, double y)
>{
> doubleD.31 D.3134;
>
> _1 = copysignD.107 (1.0e+0, yD.3126);
> D.3134 = xD.3125 * _1;
> return D.3134;
>}
>
>
>check_d_neg (double x, double y)
>{
> doubleD.31 D.3136;
>
> _1 = copysignD.107 (1.0e+0, yD.3130);
> D.3136 = xD.3129 * _1;
> return D.3136;
>}
>
>GIMPLE seems to have the invariant that all variables appear before
>anything else? so it's correctly gimplified the functions in a manner
>that makes them the same.
>
>however by the time it gets to expand something odd has happend:
>
>fix_loop_structure: fixing up loops for function
>check_d_pos (doubleD.31 xD.3125, doubleD.31 yD.3126)
>{
> doubleD.31 x_3(D) = xD.3125;
> doubleD.31 y_2(D) = yD.3126;
> doubleD.31 _1;
> doubleD.31 _4;
>
>;; basic block 2, loop depth 0, freq 1, maybe hot
>;;prev block 0, next block 1, flags: (NEW, REACHABLE, VISITED)
>;;pred: ENTRY [100.0%] (FALLTHRU,EXECUTABLE)
> _1 = copysignD.107 (1.0e+0, y_2(D));
> _4 = _1 * x_3(D);
> # VUSE <.MEM_5(D)>
> return _4;
>;;succ: EXIT [100.0%] (EXECUTABLE)
>
>}
>
>check_d_neg (doubleD.31 xD.3129, doubleD.31 yD.3130)
>{
> doubleD.31 x_1(D) = xD.3129;
> doubleD.31 y_2(D) = yD.3130;
> doubleD.31 D.3153;
> doubleD.31 retval.2D.3143;
> doubleD.31 _5;
> doubleD.31 _6;
>
>;; basic block 2, loop depth 0, freq 1, maybe hot
>;;prev block 0, next block 1, flags: (NEW, REACHABLE)
>;;pred: ENTRY [100.0%] (FALLTHRU)
> _5 = copysignD.107 (1.0e+0, y_2(D));
> _6 = x_1(D) * _5;
> _7 = _6;
> retval.2_3 = _7;
> # VUSE <.MEM_4(D)>
> return retval.2_3;
>;;succ: EXIT [100.0%]
>
>}
>
>noticed it has swapped the order of the terms to the *. This
>re-ordering seems to make it miss optimizations in expr.c e.g.
>expand_expr_real_2
>which I think still rely on the invariant GIMPLE first introduced.
>
>What's happening is that IPA decides that the functions are similar
>enough and replaces the body of one of the functions with a call to the
>other:
>
>check_d_neg (double x, double y)
>{
> double retval.2;
>
> [100.00%] [count: INV]:
> retval.2_3 = check_d_pos (x_1(D), y_2(D)); [tail call]
> return retval.2_3;
>
>}
>
>check_d_pos (double x, double y)
>{
> double _1;
> double _4;
>
> [100.00%] [count: INV]:
> _1 = __builtin_copysign (1.0e+0, y_2(D));
> _4 = _1 * x_3(D);
> return _4;
>
>}
>
>It then later decides to undo this and so generates a different order.
>Question is, is this unexpected or should optimizations in expand be
>checking for associativity?
It's expected. Once fully in SSA the canonical operand order is lower SSA name
versions first.
Richard.
>Thanks,
>Tamar
