Re: A problem about loop store motion
On Wed, Feb 22, 2012 at 2:15 AM, Jiangning Liu wrote:
>
>
>> -Original Message-
>> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
>> Richard Guenther
>> Sent: Tuesday, February 21, 2012 6:19 PM
>> To: Jiangning Liu
>> Cc: gcc@gcc.gnu.org
>> Subject: Re: A problem about loop store motion
>>
>> On Tue, Feb 21, 2012 at 10:57 AM, Jiangning Liu
>> wrote:
>> >
>> >
>> >> -Original Message-
>> >> From: Richard Guenther [mailto:richard.guent...@gmail.com]
>> >> Sent: Tuesday, February 21, 2012 5:40 PM
>> >> To: Jiangning Liu
>> >> Cc: gcc@gcc.gnu.org
>> >> Subject: Re: A problem about loop store motion
>> >>
>> >> On Tue, Feb 21, 2012 at 9:54 AM, Jiangning Liu
>>
>> >> wrote:
>> >> >> The MEM form is more "canonical", so the loop SM machinery to
>> detect
>> >> >> equality should be adjusted accordingly. Alternatively you can
>> >> teach
>> >> >> PRE insertion to strip off the MEM if possible (though
>> >> >> fold_stmt_inplace should
>> >> >> arelady do this if possible).
>> >> >
>> >> > Richard,
>> >> >
>> >> > Thank you! You are right. I noticed on latest trunk the problem in
>> >> PRE was
>> >> > already fixed by invoking fold_stmt_inplace.
>> >> >
>> >> > Unfortunately for this small case, the latest trunk code still
>> can't
>> >> do SM
>> >> > for variable pos, because refs_may_alias_p(*D.4074_10, pos) is
>> true,
>> >> that
>> >> > is, pos has alias with l[pos].
>> >> >
>> >> > I think alias analysis should be able to know they don't have
>> alias
>> >> with
>> >> > each other, unless there is an assignment statement like "l=&pos;".
>> >> >
>> >> > Can alias analysis fix the problem?
>> >>
>> >> The problem is that 'pos' is marked TREE_ADDRESSABLE, so we think
>> >> its address got taken. 'l' points to any global possibly address-
>> taken
>> >> variable. It get's the TREE_ADDRESSABLE flag via PRE insertion
>> which
>> >> re-gimplifies the tree it creates which marks the variable as
>> >> addressable.
>> >>
>> >> I'll have a look.
>> >
>> > Terrific! :-) Could you please let me know when you have a patch to
>> fix
>> > this, because I want to double check the big case, and there might be
>> other
>> > hidden problems?
>>
>> PR52324, I am testing the following patch (in reality the gimplifier
>> should not
>> mark things addressable unless it itself makes them so, but frontends
>> are
>> broken, so we do that ... ugh).
>>
>
> Richard,
>
> Now trunk works for the big case as well. Thanks a lot for your quick fix.
>
> BTW, why can't we fix front-end directly?
front-end? You mean why we are marking things addressable in the
gimplifier? Because nobody went down and fixed all latent issues in
the frontends. Feel free to fix the fallout of
Index: gcc/gimplify.c
===
--- gcc/gimplify.c (revision 184460)
+++ gcc/gimplify.c (working copy)
@@ -4957,8 +4957,6 @@ gimplify_addr_expr (tree *expr_p, gimple
if (TREE_CODE (op0) == INDIRECT_REF)
goto do_indirect_ref;
- mark_addressable (TREE_OPERAND (expr, 0));
-
/* The FEs may end up building ADDR_EXPRs early on a decl with
an incomplete type. Re-build ADDR_EXPRs in canonical form
here. */
;)
> Thanks,
> -Jiangning
>
>> Index: gcc/gimplify.c
>> ===
>> --- gcc/gimplify.c (revision 184428)
>> +++ gcc/gimplify.c (working copy)
>> @@ -7061,15 +7061,20 @@ gimplify_expr (tree *expr_p, gimple_seq
>> ret = GS_OK;
>> break;
>> }
>> - ret = gimplify_expr (&TREE_OPERAND (*expr_p, 0), pre_p,
>> post_p,
>> - is_gimple_mem_ref_addr, fb_rvalue);
>> - if (ret == GS_ERROR)
>> - break;
>> + /* Avoid re-gimplifying the address operand if it is already
>> + in suitable form. */
>> + if (!is_gimple_mem_ref_addr (TREE_OPERAND (*expr_p, 0)))
>> + {
>> + ret = gimplify_expr (&TREE_OPERAND (*expr_p, 0), pre_p,
>> post_p,
>> + is_gimple_mem_ref_addr, fb_rvalue);
>> + if (ret == GS_ERROR)
>> + break;
>> + }
>> recalculate_side_effects (*expr_p);
>> ret = GS_ALL_DONE;
>> break;
>>
>> - /* Constants need not be gimplified. */
>> + /* Constants need not be gimplified. */
>> case INTEGER_CST:
>> case REAL_CST:
>> case FIXED_CST:
>
>
>
>
toplev.c: Question on __gnu_lto markers in .comm
toplev.c emits __gnu_lto markers to assembler:
/* Emit LTO marker if LTO info has been previously emitted. This is
used by collect2 to determine whether an object file contains IL.
We used to emit an undefined reference here, but this produces
link errors if an object file with IL is stored into a shared
library without invoking lto1. */
if (flag_generate_lto)
{
#if defined ASM_OUTPUT_ALIGNED_DECL_COMMON
ASM_OUTPUT_ALIGNED_DECL_COMMON (asm_out_file, NULL_TREE,
"__gnu_lto_v1",
(unsigned HOST_WIDE_INT) 1, 8);
#elif defined ASM_OUTPUT_ALIGNED_COMMON
ASM_OUTPUT_ALIGNED_COMMON (asm_out_file, "__gnu_lto_v1",
(unsigned HOST_WIDE_INT) 1, 8);
#else
ASM_OUTPUT_COMMON (asm_out_file, "__gnu_lto_v1",
(unsigned HOST_WIDE_INT) 1,
(unsigned HOST_WIDE_INT) 1);
#endif
...
Am I right that this is just used as marker for linker/lto1 to detect presence
and style of IL representation?
Background is as follows:
A trivial program, compiled for avr and without LTO, at the and of assembler
output there is
.ident "GCC: (GNU) 4.7.0 20120220 (experimental)"
whereas with the LTO there is:
.comm __gnu_lto_v1,1,1
.ident "GCC: (GNU) 4.7.0 20120220 (experimental)"
.global __do_clear_bss
avr only supports static linking.
The avr backend thinks that the symbol occupies space on the silicon and needs
to be allocated and initialized so that a part of the startup code is dragged
in which is not needed.
Is it always save to ignore __gnu_lto_* symbols when deciding which parts of
startup code are needed?
Thanks,
Johann
Re: toplev.c: Question on __gnu_lto markers in .comm
On Wed, Feb 22, 2012 at 12:19 PM, Georg-Johann Lay wrote:
> toplev.c emits __gnu_lto markers to assembler:
>
> /* Emit LTO marker if LTO info has been previously emitted. This is
> used by collect2 to determine whether an object file contains IL.
> We used to emit an undefined reference here, but this produces
> link errors if an object file with IL is stored into a shared
> library without invoking lto1. */
> if (flag_generate_lto)
> {
> #if defined ASM_OUTPUT_ALIGNED_DECL_COMMON
> ASM_OUTPUT_ALIGNED_DECL_COMMON (asm_out_file, NULL_TREE,
> "__gnu_lto_v1",
> (unsigned HOST_WIDE_INT) 1, 8);
> #elif defined ASM_OUTPUT_ALIGNED_COMMON
> ASM_OUTPUT_ALIGNED_COMMON (asm_out_file, "__gnu_lto_v1",
> (unsigned HOST_WIDE_INT) 1, 8);
> #else
> ASM_OUTPUT_COMMON (asm_out_file, "__gnu_lto_v1",
> (unsigned HOST_WIDE_INT) 1,
> (unsigned HOST_WIDE_INT) 1);
> #endif
>
> ...
>
> Am I right that this is just used as marker for linker/lto1 to detect presence
> and style of IL representation?
>
> Background is as follows:
>
> A trivial program, compiled for avr and without LTO, at the and of assembler
> output there is
>
> .ident "GCC: (GNU) 4.7.0 20120220 (experimental)"
>
> whereas with the LTO there is:
>
> .comm __gnu_lto_v1,1,1
> .ident "GCC: (GNU) 4.7.0 20120220 (experimental)"
> .global __do_clear_bss
>
> avr only supports static linking.
>
> The avr backend thinks that the symbol occupies space on the silicon and needs
> to be allocated and initialized so that a part of the startup code is dragged
> in which is not needed.
>
> Is it always save to ignore __gnu_lto_* symbols when deciding which parts of
> startup code are needed?
Yes.
We should transition away from emitting __gnu_lto_v1 (which is only used
if you do not use a linker plugin btw) for example by making collect2 use
simple-object from libiberty instead of invoking nm and friends.
Richard.
> Thanks,
>
> Johann
RE: spill failure after IF-CASE-2 transformation
>Not really. I think in dead_or_predicable you need to check in the > /* Try the NCE path if the CE path did not result in any changes. */ >block (I assume this is where we end up in this testcase) that none of >the live hard regs at the point where we are going to insert the insns >are in small register classes. small_register_classes_for_mode_p is >unfortunately not a good interface to answer that question. > >It looks like noce_get_condition probably didn't find the instruction >setting CC? Maybe you can paper over the problem for the moment by >making sure it does. The problem with noce_get_condition is that if the condition variable is a MODE_INT register it will return it and set earliest as the jump insn itself. I'm not sure why this is the case, but it seems like something we don't want to be doing in this situation. Is there a reasonable check that should be made to avoid noce_get_condition doing this? e.g. if the condition var is a reg and !small_register_classes_for_mode_p. Thanks, Stu
Re: Some confuse about the pass of the arguments by gcc
2012/2/22 James Courtier-Dutton :
> The order that function parameters are evaluated is undefined. Therefore it
> is wise to ensure that no matter what order they are evaluated, the result
> should be the same. It is the ++ that breaks it in this case. Didn't you get
> a compiler warning?
Yes you are right. gcc -Wall indeed get the warning.
operation on 'a' may be undefined [-Wsequence-point]
Thanks for you reminder.
Let me know ,If we want the result we want ,we should do the precision
logic design .
> On Feb 21, 2012 3:19 PM, "嘉谟" wrote:
>>
>> I do a experiments to check how gcc pass the arguments.
>> here is the code
>>
>> #include
>> int main(int argc , char *argv[]){
>>int a=3;
>>int b=3;
>>int c=3;
>>printf("%d %d\n",++a+c,a+c);
>>printf("%d %d\n",++b,b);
>>return 0;
>> }
>>
>> the anwer is
>>
>> 8 7
>> 4 4
>>
>> the piece of assembly language: gcc 4.6.2
>>
>>movl$3, 28(%esp)
>>movl$3, 24(%esp)
>>movl$3, 20(%esp)
>>movl20(%esp), %eax
>>movl28(%esp), %edx
>>leal(%edx,%eax), %ecx
>>addl$1, 28(%esp)
>>movl20(%esp), %eax
>>movl28(%esp), %edx
>>addl%eax, %edx
>>movl$.LC0, %eax
>>movl%ecx, 8(%esp)
>>movl%edx, 4(%esp)
>>movl%eax, (%esp)
>>callprintf
>>addl$1, 24(%esp)
>>movl$.LC0, %eax
>>movl24(%esp), %edx
>>movl%edx, 8(%esp)
>>movl24(%esp), %edx
>>movl%edx, 4(%esp)
>>movl%eax, (%esp)
>>callprintf
>>
>> In the first case , gcc first compute the a+c to %ecx ,and pass it
>> stack , the compute ++a+c to %edx ,so the answer is 8 7
>>
>> In the second case , why it didn't do the same thing like
>> compute b=3 and pass it to stack ,then compute ++b and pass it to
>> stack .to the result 4 3. However it first
>> addl$1, 24(%esp) ==> b+1 I think it compute the expression
>> b+1. the pass it to stack . the b which now is 4 and was passed to
>> stack.
>>
>> I was wondering why gcc handle the same mode in two ways.
>>
>> Is there some errors I had made ?
>> In my opinion ,for the reason of the concept of consistent ,it may be
>> 8 8
>> 4 4
>>
>> thank you advance
Re: spill failure after IF-CASE-2 transformation
On 02/22/2012 01:23 PM, Henderson, Stuart wrote: > The problem with noce_get_condition is that if the condition variable > is a MODE_INT register it will return it and set earliest as the jump > insn itself. I'm not sure why this is the case, but it seems like > something we don't want to be doing in this situation. Is there a > reasonable check that should be made to avoid noce_get_condition > doing this? e.g. if the condition var is a reg and > !small_register_classes_for_mode_p. Make an exception for BImode and small_register_classes_for_mode_p (BImode). Bernd
RE: spill failure after IF-CASE-2 transformation
>Make an exception for BImode and small_register_classes_for_mode_p
>(BImode).
Thanks Bernd.
Would this be acceptable:
diff --git a/gcc/ifcvt.c b/gcc/ifcvt.c
index 8d81c89..e4e13ab 100644
--- a/gcc/ifcvt.c
+++ b/gcc/ifcvt.c
@@ -2295,7 +2295,9 @@ noce_get_condition (rtx jump, rtx *earliest, bool
then_else_reversed)
cond = XEXP (SET_SRC (set), 0);
tmp = XEXP (cond, 0);
- if (REG_P (tmp) && GET_MODE_CLASS (GET_MODE (tmp)) == MODE_INT)
+ if (REG_P (tmp) && GET_MODE_CLASS (GET_MODE (tmp)) == MODE_INT
+ && (GET_MODE (tmp) != BImode
+ || !targetm.small_register_classes_for_mode_p (BImode)))
{
*earliest = jump;
Re: spill failure after IF-CASE-2 transformation
On 02/22/2012 05:15 PM, Henderson, Stuart wrote:
>> Make an exception for BImode and small_register_classes_for_mode_p
>> (BImode).
>
> Thanks Bernd.
>
> Would this be acceptable:
>
> diff --git a/gcc/ifcvt.c b/gcc/ifcvt.c
> index 8d81c89..e4e13ab 100644
> --- a/gcc/ifcvt.c
> +++ b/gcc/ifcvt.c
> @@ -2295,7 +2295,9 @@ noce_get_condition (rtx jump, rtx *earliest, bool
> then_else_reversed)
>
>cond = XEXP (SET_SRC (set), 0);
>tmp = XEXP (cond, 0);
> - if (REG_P (tmp) && GET_MODE_CLASS (GET_MODE (tmp)) == MODE_INT)
> + if (REG_P (tmp) && GET_MODE_CLASS (GET_MODE (tmp)) == MODE_INT
> + && (GET_MODE (tmp) != BImode
> + || !targetm.small_register_classes_for_mode_p (BImode)))
> {
>*earliest = jump;
I think this is a fairly reasonable minimal fix. For 4.8 we could
experiment whether to always do this, regardless of s_r_c_f_m_p.
Ok if bootstrapped and tested on a primary target (i.e. linux) and
tested on Blackfin.
Bernd
Re: Some confuse about the pass of the arguments by gcc
On 22 February 2012 13:34, 嘉谟 wrote:
> 2012/2/22 James Courtier-Dutton :
>> The order that function parameters are evaluated is undefined. Therefore it
>> is wise to ensure that no matter what order they are evaluated, the result
>> should be the same. It is the ++ that breaks it in this case. Didn't you get
>> a compiler warning?
>
> Yes you are right. gcc -Wall indeed get the warning.
> operation on 'a' may be undefined [-Wsequence-point]
>
> Thanks for you reminder.
> Let me know ,If we want the result we want ,we should do the precision
> logic design .
>>> #include
>>> int main(int argc , char *argv[]){
>>>int a=3;
>>>int b=3;
>>>int c=3;
>>>printf("%d %d\n",++a+c,a+c);
>>>printf("%d %d\n",++b,b);
>>>return 0;
>>> }
I sure exactly what you are asking for, but a version of the above
that will be portable and defined is:
#include
int main(int argc , char *argv[]){
int a=3;
int b=3;
int c=3;
printf("%d %d\n",++a+c,a+c);
printf("%d %d\n",++b,b);
return 0;
}
Re: Some confuse about the pass of the arguments by gcc
On 22 February 2012 19:05, James Courtier-Dutton wrote:
> On 22 February 2012 13:34, 嘉谟 wrote:
>> 2012/2/22 James Courtier-Dutton :
>>> The order that function parameters are evaluated is undefined. Therefore it
>>> is wise to ensure that no matter what order they are evaluated, the result
>>> should be the same. It is the ++ that breaks it in this case. Didn't you get
>>> a compiler warning?
>>
>> Yes you are right. gcc -Wall indeed get the warning.
>> operation on 'a' may be undefined [-Wsequence-point]
>>
>> Thanks for you reminder.
>> Let me know ,If we want the result we want ,we should do the precision
>> logic design .
>
#include
int main(int argc , char *argv[]){
int a=3;
int b=3;
int c=3;
printf("%d %d\n",++a+c,a+c);
printf("%d %d\n",++b,b);
return 0;
}
>
Send button fired accidentally before I had finished.
I am not sure exactly what you are asking for, but a version of the above
that will be portable and defined is:
#include
int main(int argc , char *argv[]){
int a=3;
int b=3;
int c=3;
int tmp1, tmp2, tmp3, tmp4;
tmp1 = ++a+c;
tmp2 = a+c;
printf("%d %d\n",tmp1, tmp2);
tmp3 = ++b;
tmp4 = b;
printf("%d %d\n", tmp3, tmp4);
return 0;
}
Re: Simulator testing for sh and sh64
Hi! This is about sh and sh64 GDB sim testing for the whole toolchain. (I also do have sh4a hardware available, where testing is working fine.) Kaz, could you please have a look whether this looks basically sane, that my assumptions and the results I'm getting are about right, etc.? On Wed, 22 Feb 2012 09:39:29 -0700, Kevin Buettner wrote: > On Wed, 22 Feb 2012 15:52:03 +0100 > Thomas Schwinge wrote: > > > How do you configure the toolchain's components for the sim testing? > > I use --target=sh-elf . > > When it comes time to run the tests, do: > > make check RUNTESTFLAGS="--target_board=sh-sim" OK, that matches what I'm doing (simple enough), and that works for me, too. With all-current sources (CVS HEAD, svn trunk, Git master, as appropriate), I get 707 unexpected failures in g++ testing (a lot of execution tests, as it seems), 204 in gcc, 434 in gdb (I'm currently working on improving that), 41 in ld (seems that some test harness problem is involved; get a lot of: ``sh-elf-ld: cannot find sh-unknown.o: No such file or directory''), 322 in libstdc++, 3 in newlib. So far, so good. > > And, any quick suggestion for a sh64 sim testing configuration, too? My > > attempt so far only results in a series of SIGILL... Kaz, is my understanding correct, that I simply use sh64-elf as target, and again the sh-sim board? Should I be setting a specific CPU when configuring GCC, or any other customization? Building all-current sources comes to a halt as follows: /scratch/tschwing/FM_sh64-elf/obj/gcc-first-mainline-0-sh64-elf-i686-pc-linux-gnu/./gcc/xgcc -B/scratch/tschwing/FM_sh64-elf/obj/gcc-first-mainline-0-sh64-elf-i686-pc-linux-gnu/./gcc/ -B/scratch/tschwing/FM_sh64-elf/install/sh64-elf/bin/ -B/scratch/tschwing/FM_sh64-elf/install/sh64-elf/lib/ -isystem /scratch/tschwing/FM_sh64-elf/install/sh64-elf/include -isystem /scratch/tschwing/FM_sh64-elf/install/sh64-elf/sys-include --sysroot=/scratch/tschwing/FM_sh64-elf/install/sh64-elf -g -O2 -ml -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -mieee -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -mieee -I. -I. -I../../.././gcc -I/scratch/tschwing/FM_sh64-elf/src/gcc-mainline/libgcc -I/scratch/tschwing/FM_sh64-elf/src/gcc-mainline/libgcc/. -I/scratch/tschwing/FM_sh64-elf/src/gcc-mainline/libgcc/../gcc -I/scratch/tschwing/FM_sh64-elf/src/gcc-mainline/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o _powisf2.o -MT _powisf2.o -MD -MP -MF _powisf2.dep -DL_powisf2 -c /scratch/tschwing/FM_sh64-elf/src/gcc-mainline/libgcc/libgcc2.c /scratch/tschwing/FM_sh64-elf/src/gcc-mainline/libgcc/libgcc2.c: In function '__powisf2': /scratch/tschwing/FM_sh64-elf/src/gcc-mainline/libgcc/libgcc2.c:1779:1: error: unrecognizable insn: (insn 10 9 11 3 (set (reg:SI 162 [ D.2769 ]) (abs:SI (reg/v:SI 168 [ m ]))) /scratch/tschwing/FM_sh64-elf/src/gcc-mainline/libgcc/libgcc2.c:1770 -1 (nil)) /scratch/tschwing/FM_sh64-elf/src/gcc-mainline/libgcc/libgcc2.c:1779:1: internal compiler error: in extract_insn, at recog.c:2123 Stepping back to using the 4.5 GCC branch and otherwise all-current sources, it compiles, and I get 76 unexpected failures in g++ (a lot of ``ld: section .stack loaded at [0008,00080003] overlaps section .text loaded at [1060,000ec0bf]''), 119 in gcc, 41 in ld, 1185 in libstdc++ (the section overlap issue again, it seems), 3 in newlib, and GDB testing totally breaks down: I'm receiving a lot of ``Program received signal SIGILL, Illegal instruction''; from a quick investigation, it seems that GDB is patching the breakpoints at addresses that are 2 bytes offset from where they meant to go. I'll have a look at this. Moving a bit forward by using the 4.6 GCC branch and otherwise all-current sources, it compiles, and the test results look similar to GCC 4.5's. This means, for sh-elf sim testing, we have a bit too many failures in GCC and GDB, and some ld test harness issue. For sh64-elf we have a GCC trunk ICE, some section overlap issue, and even more GDB issues. Grüße, Thomas pgp9mRku0FfBJ.pgp Description: PGP signature
Re: GCC: OpenMP posix pthread
Hi, thank you for your reply. So I cannot use the Helgrind tool without disabling the futexes. Do you know if exist a open source thread analyzer? Thank you
Re: Simulator testing for sh and sh64
Thomas Schwinge wrote: > This is about sh and sh64 GDB sim testing for the whole toolchain. (I > also do have sh4a hardware available, where testing is working fine.) > Kaz, could you please have a look whether this looks basically sane, that > my assumptions and the results I'm getting are about right, etc.? You are right, I think. > Kaz, is my understanding correct, that I simply use sh64-elf as target, > and again the sh-sim board? Should I be setting a specific CPU when > configuring GCC, or any other customization? I used sh64-sim board for sh64-elf. sh64-sim.exp baseboard can be seen in http://lists.gnu.org/archive/html/dejagnu/2008-02/msg00056.html > This means, for sh-elf sim testing, we have a bit too many failures in > GCC and GDB, and some ld test harness issue. For sh64-elf we have a GCC > trunk ICE, some section overlap issue, and even more GDB issues. Yep. About sh64, I had used sh64-linux as my testing target, but unfortunately that real sh64 system stopped working after the earthquake. Regards, kaz
