Too conservative in hardreg propagation pass?
Hi, In cprop_hardreg pass, function find_oldest_value_reg checks if oldest_regno is in same register class as original one by calling in_hard_reg_set_p. Won't this be too conservative, considering the rewriting of rtx is guarded by validate_change? For example on Thumb1, r12 <-- r0 r1 <-- r1 + r12 The r12/r0 have different register classes (HI_REG/LO_REG), thus prevents r12 in the addition from being propagated by r0. Any suggestions? Thanks very much. -- Best Regards.
Primary and secondary sysroot?
Deal all, We have a version of GCC coming as additional toolchain for several supported Linux distros. Moreover, package we are shipping also contains modified glibc and some other libraries. In this situation, applications built with this compiler should first logically use its own sysroot, but in case when a header/library from host's sysroot is needed - fallback to the default "/usr" sysroot. I think this could be accomplished by providing two sysroots - one primary, and secondary - to complement it for the rest of things. Looks like currently gcc only supports a single setting for TARGET_SYSTEM_ROOT. Do you see any other options regarding this issue? Thanks, - Dima.
PR 55171 4.6 Backport
Hello,
Would it be possible to have fix for PR 55171 backported to 4.6 branch?
I am having an issue with the attached test case not working using
MinGW-w64 GCC 4.6.3 64-bit.
Thanks.
Regards,
Jonathan
class Base {
public:
virtual ~Base() { }
};
class Derived : public Base
{
public:
Derived();
private:
int *num;
};
Derived::Derived() :
num(new int(123))
{
int x = 0;
++x;
}
int main(int argc, char *argv[])
{
Derived d;
return 0;
}
/* GDB stack test case
* g++ -g test.cpp
* gdb a.exe
* (gdb) break 19
* (gdb) run
* (gdb) where
* #0 Derived::Derived (this=0x22fd50) at test.cpp:19
* #1 0x in ?? ()
*/
Re: PR 55171 4.6 Backport
Hi, I am a bit in doubt that the fix of PR 55171 will help you for 64-bit. The patch modifies thunk-code for 32-bit "thiscall" calling-convention. So it can't affect 64-bit code path. Kai
VUSE ops on return statements that return a GIMPLE reg?
Hello,
Consider this test case:
-- 8<
int a;
__attribute__((__noinline__,__noclone__,__pure__))
int use (int b)
{
return b * 2 + 4 + a;
}
int foo (int b, int c, int d)
{
int res, r = 0;
res = use (b);
if (c)
r = res;
return r;
}
-- 8<
I would expect the "res = use(b)" statement to be sinkable, but this
doesn't happen. There are strange VOPs on the return statements, even
though they return a GIMPLE register, AFAICT:
use (int b)
{
int a.0;
int _2;
int _3;
int _6;
:
_2 = b_1(D) + 2;
_3 = _2 * 2;
# VUSE <.MEM_4(D)>
a.0_5 = a;
_6 = _3 + a.0_5;
# VUSE <.MEM_4(D)>
return _6;
}
foo (int b, int c, int d)
{
int r;
:
# VUSE <.MEM_2(D)>
r_4 = use (b_3(D));
if (c_5(D) != 0)
goto ;
else
goto ;
:
goto ;
:
:
# r_1 = PHI <0(5), r_4(3)>
# VUSE <.MEM_2(D)>
return r_1;
}
Why are those VUSEs there?
Ciao!
Steven
Re: VUSE ops on return statements that return a GIMPLE reg?
On Mon, 7 Jan 2013, Steven Bosscher wrote:
> Hello,
>
> Consider this test case:
>
> -- 8<
> int a;
> __attribute__((__noinline__,__noclone__,__pure__))
> int use (int b)
> {
> return b * 2 + 4 + a;
> }
>
> int foo (int b, int c, int d)
> {
> int res, r = 0;
> res = use (b);
> if (c)
> r = res;
> return r;
> }
> -- 8<
>
> I would expect the "res = use(b)" statement to be sinkable, but this
> doesn't happen. There are strange VOPs on the return statements, even
> though they return a GIMPLE register, AFAICT:
>
> use (int b)
> {
> int a.0;
> int _2;
> int _3;
> int _6;
> :
> _2 = b_1(D) + 2;
> _3 = _2 * 2;
> # VUSE <.MEM_4(D)>
> a.0_5 = a;
> _6 = _3 + a.0_5;
> # VUSE <.MEM_4(D)>
> return _6;
> }
>
> foo (int b, int c, int d)
> {
> int r;
> :
> # VUSE <.MEM_2(D)>
> r_4 = use (b_3(D));
The issue is the VUSE here - it's a "load" (reads global memory)
and thus we do not consider sinking it.
> if (c_5(D) != 0)
> goto ;
> else
> goto ;
> :
> goto ;
> :
> :
> # r_1 = PHI <0(5), r_4(3)>
> # VUSE <.MEM_2(D)>
> return r_1;
> }
>
> Why are those VUSEs there?
They are there to properly represent the fact that stores to
global memory are kept live by the return stmt. This enables
more sinking of stores (heh) and facilitates memory analysis
that looks for things used by function exit points (simply
walk the VUSE -> VDEF chain).
Richard.
Re: code hoisting with CCmode condition codes
On 01/06/2013 01:11 PM, Alan Lehotsky wrote: > Do I need to do something like change my define_expand for addsi3 to be > something like > > > [ (parallel [ (clobber:CCmode (reg:CCmode CCREG)) > (set:SI (match_operand:SI 0 "" "") > (plus:SI (match_operand::SI 1 "" "" ) > (match_operand:SI 2 "" > "")))])] > > So that there's an explicitly stated dependency that would prevent motioning > before the use in the jump_insn? Yes. (With the note that SETs appear first in parallels, with CLOBBERs last.) r~
Build error in genconstants.c
Hello Everyone, I am getting the following error when I tried to build the trunk (revision 194999) on my SuSE machine (Linux 2.6.32.29-0.3-default x86_64). I just did the standard configure (../src_directory/configure --prefix=<>). It looks like some syscall functions on my machine seem to not like the system.h that is available with GCC. Is there anything I can do to fix this? Any help is greatly appreciated! Thanks, Balaji V. Iyer. make[3]: Leaving directory `/export/users/gcc-svn/b-trunk-gcc/libdecnumber' make[3]: Entering directory `/export/users/gcc-svn/b-trunk-gcc/gcc' g++ -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../trunk-gcc/gcc -I../../trunk-gcc/gcc/build -I../../trunk-gcc/gcc/../include -I../../trunk-gcc/gcc/../libcpp/include -I/export/users/gcc-svn/b-trunk-gcc/./gmp -I/export/users/gcc-svn/trunk-gcc/gmp -I/export/users/gcc-svn/b-trunk-gcc/./mpfr -I/export/users/gcc-svn/trunk-gcc/mpfr -I/export/users/gcc-svn/trunk-gcc/mpc/src -I../../trunk-gcc/gcc/../libdecnumber -I../../trunk-gcc/gcc/../libdecnumber/bid -I../libdecnumber -I../../trunk-gcc/gcc/../libbacktrace\ -o build/genconstants.o ../../trunk-gcc/gcc/genconstants.c In file included from /usr/include/sys/resource.h:25, from /usr/include/sys/wait.h:32, from ../../trunk-gcc/gcc/system.h:354, from ../../trunk-gcc/gcc/genconstants.c:29: /usr/include/bits/resource.h:127: error: declaration does not declare anything In file included from ../../trunk-gcc/gcc/genconstants.c:29: ../../trunk-gcc/gcc/system.h:446: error: declaration of C function âvoid* sbrk(int)â conflicts with /usr/include/unistd.h:1046: error: previous declaration âvoid* sbrk(intptr_t)â here In file included from ../../trunk-gcc/gcc/genconstants.c:29: ../../trunk-gcc/gcc/system.h:502: error: declaration of C function âconst char* strsignal(int)â conflicts with /usr/include/string.h:564: error: previous declaration âchar* strsignal(int)â here make[3]: *** [build/genconstants.o] Error 1 make[3]: Leaving directory `/export/users/gcc-svn/b-trunk-gcc/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/export/users/gcc-svn/b-trunk-gcc' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/export/users/gcc-svn/b-trunk-gcc' make: *** [all] Error 2
microblaze unroll loops optimization
Loop unrolling (-funroll-loops) for microblaze is ineffectual on the gcc
4.6/4.7/4.8 branches.
This previously worked on an out of tree gcc 4.1.2, and I believe the relevant
diff to be the use of UNSPEC_CMP and UNSPEC_CMPU to create two unique
instructions for signed_compare and unsigned_compare in microblaze's machine
description, which means that the iv_analyze_expr in loop-iv.c of the compare
instruction is unable to understand the expression.
Details follow below,
thanks,
David
Looking at the resultant (-fdump-rtl-loop2_unroll-slim) dump file from compiling
the following small example (extracted from larger benchmarking coremark);
void matrix_mul_const(signed int N, signed int *C,
signed short *A, signed short val) {
signed int i,j;
for (i=0; i 47)
Analyzing def of (reg:SI 99) in insn (insn 28 26 29 4 (set (reg:SI 99)
(unspec [
(reg/v:SI 87 [ N ])
(reg/v:SI 56 [ j ])
] 104)) core_matrix_min.c:6 66 {signed_compare}
(expr_list:REG_DEAD (reg/v:SI 87 [ N ])
(nil)))
(reg:SI 99) in insn (insn 28 26 29 4 (set (reg:SI 99)
(unspec [
(reg/v:SI 87 [ N ])
(reg/v:SI 56 [ j ])
] 104)) core_matrix_min.c:6 66 {signed_compare}
(expr_list:REG_DEAD (reg/v:SI 87 [ N ])
(nil)))
is not simple
Loop 2 is not simple.
where signed_compare is defined in microblaze.md as;
(define_insn "signed_compare"
[(set (match_operand:SI 0 "register_operand" "=d")
(unspec
[(match_operand:SI 1 "register_operand" "d")
(match_operand:SI 2 "register_operand" "d")] UNSPEC_CMP))]
""
"cmp\t%0,%1,%2"
[(set_attr "type" "arith")
(set_attr "mode" "SI")
(set_attr "length""4")])
During iv_analyze_expr in loop-iv.c, the expression RHS of this insn is
determined to be;
(gdb) call debug_rtx(rhs)
(unspec [
(reg/v:SI 87 [ N ])
(reg/v:SI 56 [ j ])
] 104)
meaning that GET_CODE (rhs) will be UNSPEC and no further analysis of the insn
is carried out.
Adjusting the signed_compare insn to the following;
(define_insn "signed_compare"
[(set (match_operand:SI 0 "register_operand" "=d")
(compare:SI (match_operand:SI 1 "register_operand" "d")
(match_operand:SI 2 "register_operand" "d")))]
""
"cmp\t%0,%1,%2"
[(set_attr "type" "arith")
(set_attr "mode" "SI")
(set_attr "length""4")])
I get much further through the unrolling analysis;
Analyzing operand (reg/v:SI 87 [ N ]) of insn (insn 28 26 29 4 (set (reg:SI 99)
(compare:SI (reg/v:SI 87 [ N ])
(reg/v:SI 56 [ j ]))) core_matrix_min.c:6 66 {signed_compare}
(expr_list:REG_DEAD (reg/v:SI 87 [ N ])
(nil)))
invariant (reg/v:SI 87 [ N ]) (in SI)
Analyzing operand (reg/v:SI 56 [ j ]) of insn (insn 28 26 29 4 (set (reg:SI 99)
(compare:SI (reg/v:SI 87 [ N ])
(reg/v:SI 56 [ j ]))) core_matrix_min.c:6 66 {signed_compare}
(expr_list:REG_DEAD (reg/v:SI 87 [ N ])
(nil)))
Analyzing def of (reg/v:SI 56 [ j ]) in insn (insn 26 25 28 4 (set
(reg/v:SI 56 [ j ])
(plus:SI (reg/v:SI 56 [ j ])
(const_int 1 [0x1]))) core_matrix_min.c:6 10 {addsi3}
(nil))
Analyzing operand (reg/v:SI 56 [ j ]) of insn (insn 26 25 28 4 (set
(reg/v:SI 56 [ j ])
(plus:SI (reg/v:SI 56 [ j ])
(const_int 1 [0x1]))) core_matrix_min.c:6 10 {addsi3}
(nil))
Analyzing (reg/v:SI 56 [ j ]) for bivness.
(reg/v:SI 56 [ j ]) + (const_int 1 [0x1]) * iteration (in SI)
Analyzing operand (const_int 1 [0x1]) of insn (insn 26 25 28 4 (set
(reg/v:SI 56 [ j ])
(plus:SI (reg/v:SI 56 [ j ])
(const_int 1 [0x1]))) core_matrix_min.c:6 10 {addsi3}
(nil))
invariant (const_int 1 [0x1]) (in VOID)
(reg/v:SI 56 [ j ]) in insn (insn 26 25 28 4 (set (reg/v:SI 56 [ j ])
(plus:SI (reg/v:SI 56 [ j ])
(const_int 1 [0x1]))) core_matrix_min.c:6 10 {addsi3}
(nil))
is (plus:SI (reg/v:SI 56 [ j ])
(const_int 1 [0x1])) + (const_int 1 [0x1]) * iteration (in SI)
Loop 2 is not simple.
;; Unable to prove that the loop rolls exactly once
The remaining issue appears to be that the loop is identified as being of type
'while (i-- < 10)' and goes to the 'fail' path in iv_number_of_iterations.
A previous out of tree microblaze port based on gcc 4.1.2 successfully unrolled
this loop, but its machine description had a very large instruction for
branch_compare which used a switch on all the codes of the comparison operator
(GTU,LEU,GEU,etc) to output asm instructions directly to compare and branch,
which would have made the loop analysis easier?
My question is, does this appear to be the correct approach to take to allowing
microblaze to unroll loops? (The use of UNSPEC in the signed_compare /
unsigned_compare appears to have been used to make the instructions unique, but
could be handled in a single instruction which ex
Re: Build error in genconstants.c
On Tue, 8 Jan 2013, Iyer, Balaji V wrote: Hello Everyone, I am getting the following error when I tried to build the trunk (revision 194999) on my SuSE machine (Linux 2.6.32.29-0.3-default x86_64). I just did the standard configure (../src_directory/configure --prefix=<>). It looks like some syscall functions on my machine seem to not like the system.h that is available with GCC. Is there anything I can do to fix this? Any help is greatly appreciated! This looks like http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55784 which was supposedly fixed by the use of $GMPINC, but your revision is recent enough to have the fix, so something is still wrong. Maybe look through config.log for the corresponding test? -- Marc Glisse
Re: Primary and secondary sysroot?
On Mon, Jan 7, 2013 at 2:47 AM, Dmitry Mikushin wrote: > > We have a version of GCC coming as additional toolchain for several > supported Linux distros. Moreover, package we are shipping also contains > modified glibc and some other libraries. In this situation, applications > built with this compiler should first logically use its own sysroot, but in > case when a header/library from host's sysroot is needed - fallback to the > default "/usr" sysroot. I think this could be accomplished by providing two > sysroots - one primary, and secondary - to complement it for the rest of > things. Looks like currently gcc only supports a single setting for > TARGET_SYSTEM_ROOT. Do you see any other options regarding this issue? You are correct: GCC only supports a single system root. But I think you can do what you want with appropriate -I and -L options, perhaps via the C_INCLUDE_PATH and LIBRARY_PATH environment variables. Ian
Missed ssa-copyrename optimization?
Hi,
For attached preprocessed file, dump file
lib_a-s_frexp.E.021t.copyrename1 contains gimple sequences like:
:
x_41 = x_8(D);
goto ;
:
if (ix_15 <= 1048575)
goto ;
else
goto ;
:
x_19 = x_8(D) * 1.8014398509481984e+16;
gh_u.value = x_19;
_21 = gh_u.parts.msw;
hx_22 = (__int32_t) _21;
gh_u ={v} {CLOBBER};
ix_24 = hx_22 & 2147483647;
*eptr_16(D) = -54;
:
# x_1 = PHI
# hx_2 = PHI
# ix_3 = PHI
_26 = *eptr_16(D);
_27 = ix_3 >> 20;
_28 = _27 + -1022;
_29 = _26 + _28;
*eptr_16(D) = _29;
hx.0_31 = (unsigned int) hx_2;
_32 = hx.0_31 & 2148532223;
_33 = _32 | 1071644672;
hx_34 = (__int32_t) _33;
sh_u.value = x_1;
hx.1_36 = (unsigned int) hx_34;
sh_u.parts.msw = hx.1_36;
x_38 = sh_u.value;
sh_u ={v} {CLOBBER};
x_40 = x_38;
:
# _4 = PHI
return _4;
I am not sure if phi node (_4, x_41, x_40) in basic block 8 should be
rename/partitioned into one partition.
Trunk does not do this rename/partition, which causing big regression
in code size on Thumb1.
BTW, the command line is:
arm-none-eabi-gcc -mthumb -mcpu=cortex-m0 -Os/-O2 ...
I noticed the behavior is intended by PR54200, but not sure how the
issue should be handled. Any suggestions?
--
Best Regards.
lib_a-s_frexp.E
Description: Binary data
