Re: fragile test case ivopt_infer_2.c
On Wed, Jun 19, 2013 at 4:30 PM, Bin.Cheng wrote:
> On Wed, Jun 19, 2013 at 8:33 PM, Richard Biener
> wrote:
>> On Wed, Jun 19, 2013 at 12:35 PM, Bin.Cheng wrote:
>>> On Wed, Jun 19, 2013 at 4:43 PM, Richard Biener
>>> wrote:
On Wed, Jun 19, 2013 at 10:04 AM, Bin.Cheng wrote:
> Hi,
> For test case gcc.dg/tree-ssa/ivopt_inter_2.c
>
> #ifndef TYPE
> #define TYPE char*
> #endif
>
> extern char a[];
>
> /* Can not infer loop iteration from array -- exit test can not be
> replaced. */
> void foo (unsigned int i_width, TYPE dst)
> {
> unsigned long long i = 0;
> unsigned long long j = 0;
> for ( ; j < i_width; )
> {
> *dst = a[i];
> dst++;
> i += 2;
> j += 1;
> }
> }
>
> /* { dg-final { scan-tree-dump-times "Replacing" 0 "ivopts"} } */
> /* { dg-final { cleanup-tree-dump "ivopts" } } */
>
> It checks whether the test is eliminated by address iv candidate,
> which is fragile.
> Giving the ivopt dump file :
>
> foo (unsigned int i_width, char * dst)
> {
> long long unsigned int j;
> long long unsigned int i;
> long long unsigned int _4;
> char _9;
> long long unsigned int _18;
>
> :
> _18 = (long long unsigned int) i_width_7(D);
> if (_18 != 0)
> goto ;
> else
> goto ;
>
> :
>
> :
> # j_21 = PHI
> _9 = MEM[symbol: a, index: j_21, step: 2, offset: 0B];
> MEM[base: dst_5(D), index: j_21, offset: 0B] = _9;
> j_13 = j_21 + 1;
> if (j_13 < _18)
> goto ;
> else
> goto ;
>
> :
> goto ;
>
> :
>
> :
> return;
> }
>
> It's possible to have "if (j_13 < _18)" eliminated into "if (j_13 !=
> _18)", and the case would fail because of dump message "Replacing exit
> test: if (j_13 < _18)"
>
> Same story for ivopt_mult_3.c
>
> Any idea how it should be handled?
Probably by checking for the real issue - I suppose at some point
the number of iterations was infered to be zero or one.
> If I was right, this case is intended to test the exit test "j_13 <
> _18" cannot be replaced by using the array address, i.e., something
> like "a_XXX != YYY". Why it is fragile is because the exit test might
> be replaced by "j_13 != _18". In this case, the use is eliminated by a
> candidate has same iv->base/step as the use itself.
>
> It's possible to dump additional information like "if (j_13 < _18)
> eliminated into if (j_13 !=> _18) because of candidate with same
> base/step" , thus we can check this valid elimination in test case.
> Any advice?
Yes, more precise dumping could help this case, too. Or scan that
the exit test does not look like &a <> ...
Richard.
> Hi Tom, since you adapted the test case, I am ccing you for some comments too.
>
> Thanks.
> bin
Re: Compiling GCC under Cygwin
Hi Angelo, well, the DOS-style path only caused a warning in the configure step, so I assumed it was okay. It was not apparently. Building out-of-source is an instruction I must have missed. So, I tried again. The problem I reported before has gone, but I still get a file permission problem later on. I have not been able to solve it, even though my laptop is now connected to the domain, I have instructed the build process to use my home directory and I have set umask to - all suggestions I found or was told they might solve the problem. If anyone knows what to do about it, I would very much like to hear about it. My Google foo is failing me in unearthing a definite solution, I am afraid. Regards, Arjen 2013/6/19 Angelo Graziosi : > Ciao Arjen, > > Il 19/06/2013 21.01, Arjen Markus ha scritto: > >> >> As for the build experiment itself: >> - I downloaded the 4.8.1 source >> - I configured the Makefiles with this command: >> ./configure --prefix=d:/gcc-src/gcc > > > Hmm... Cygwin doesn't like the path in the DOS style, "d:/...". At least it > should be "/cygdrive/d/...". In any case "--prefix=PATH" is for where the > resulting GCC binaries will be installed, not where is the GCC source.. > > If I remember correctly, the build should be done in a separate directory, > > $ mkdir build_gcc > $ cd build_gcc > $ WHERE_IS/gcc-src/configure --prefix=PATH --enable-languages=c,c++,fortran > [...] > > I would suggest to follow the section "Configuration and compiling" in > > http://gcc.gnu.org/wiki/GFortranSource > > and the links therein... > > > >> If I understand the issue correctly, I can probably get rid of it >> tomorrow - as then the >> laptop will be connected to the proper domain. > > > Good luck... :) > > > Ciao, > Angelo. >
Re: Loop induction variable optimization question
> why (and where) did ivopts decide to move the post-increments above the > usages in the first loop? It looks rather like the transformation described next to tree-ssa-loop-ivopts.c/adjust_iv_update_pos.
Re: Compiling GCC under Cygwin
On 20 June 2013 11:00, Arjen Markus wrote: > Hi Angelo, > > well, the DOS-style path only caused a warning in the configure step, > so I assumed it was okay. > It was not apparently. Building out-of-source is an instruction I must > have missed. It's documented here http://gcc.gnu.org/install/configure.html and here http://gcc.gnu.org/wiki/FAQ#configure and here http://gcc.gnu.org/wiki/InstallingGCC
Re: Compiling GCC under Cygwin
Il 20/06/2013 12.00, Arjen Markus ha scritto: So, I tried again. The problem I reported before has gone, but I still get a file permission problem later on. I have not been able to solve it, even though my laptop is now connected to the domain, I have instructed the build process to use my home directory and I have set umask to - all suggestions I found or was told they might solve the problem. Hmm... I think that GCC can be built (out of tree) akso offline, i.e. without any internet connection. You only need the source... Probably something is mis-installed or mis-configured in your system.. Have you tried to flag tese issues on Cygwin list? Perhaps there they have some ideas... Ciao, Angelo.
Re: Compiling GCC under Cygwin
Hi Angelo, well, contacting the Cygwin people is my next step. Regards, Arjen 2013/6/20 Angelo Graziosi : > Il 20/06/2013 12.00, Arjen Markus ha scritto: > >> So, I tried again. The problem I reported before has gone, but I still >> get a file permission problem later on. >> >> I have not been able to solve it, even though my laptop is now >> connected to the domain, I have instructed >> the build process to use my home directory and I have set umask to >> - all suggestions I found or >> was told they might solve the problem. > > > Hmm... I think that GCC can be built (out of tree) akso offline, i.e. > without any internet connection. You only need the source... > > Probably something is mis-installed or mis-configured in your system.. > > Have you tried to flag tese issues on Cygwin list? Perhaps there they have > some ideas... > > > Ciao, > Angelo. >
Re: Compiling GCC under Cygwin
Hi Jonathan, thanks - I did indeed overlook it ;). Regards, Arjen 2013/6/20 Jonathan Wakely : > On 20 June 2013 11:00, Arjen Markus wrote: >> Hi Angelo, >> >> well, the DOS-style path only caused a warning in the configure step, >> so I assumed it was okay. >> It was not apparently. Building out-of-source is an instruction I must >> have missed. > > It's documented here http://gcc.gnu.org/install/configure.html > and here http://gcc.gnu.org/wiki/FAQ#configure > and here http://gcc.gnu.org/wiki/InstallingGCC
Re: Compiling GCC under Cygwin
Hi Angelo, I found a reference to this sort of problems in the Cygwin FAQs, but this turned out to be a dead-end too. So I thought, I'd try MinGW/MSYS instead. It started off fairly well, however: - For some reason the gcc compiler did not like the /d/gcc-src/... path (from $srcdir) - it could not find the include file gmp-h.in. So I changed that to d:/gcc-src/... And that worked, until ... - the source file gen-fac.c was missing from the build directory for gmp. So I copied the various source files manually. And that worked, until ... - the assert.lo file was missing, which is necessary for libgmp. That file is nowhere in the build directory. So now I am definitely stuck. I can try to contact the Gygwin people and hope for the best. Or any of you might know the solution wrt MinGW. Regards, Arjen 2013/6/20 Arjen Markus : > Hi Angelo, > > well, contacting the Cygwin people is my next step. > > Regards, > > Arjen > > 2013/6/20 Angelo Graziosi : >> Il 20/06/2013 12.00, Arjen Markus ha scritto: >> >>> So, I tried again. The problem I reported before has gone, but I still >>> get a file permission problem later on. >>> >>> I have not been able to solve it, even though my laptop is now >>> connected to the domain, I have instructed >>> the build process to use my home directory and I have set umask to >>> - all suggestions I found or >>> was told they might solve the problem. >> >> >> Hmm... I think that GCC can be built (out of tree) akso offline, i.e. >> without any internet connection. You only need the source... >> >> Probably something is mis-installed or mis-configured in your system.. >> >> Have you tried to flag tese issues on Cygwin list? Perhaps there they have >> some ideas... >> >> >> Ciao, >> Angelo. >>
Re: Compiling GCC under Cygwin
Hi Arjen, Il 20/06/2013 21.41, Arjen Markus ha scritto: I found a reference to this sort of problems in the Cygwin FAQs, but this turned out to be a dead-end too. So I thought, I'd try MinGW/MSYS instead. It started off fairly well, however: - For some reason the gcc compiler did not like the /d/gcc-src/... path (from $srcdir) - it could not find the include file gmp-h.in. So I changed that to d:/gcc-src/... And that worked, until ... - the source file gen-fac.c was missing from the build directory for gmp. So I copied the various source files manually. And that worked, until ... - the assert.lo file was missing, which is necessary for libgmp. That file is nowhere in the build directory. So now I am definitely stuck. I can try to contact the Gygwin people and hope for the best. Or any of you might know the solution wrt MinGW. I don't use MinGW.. so I can't help much.. I would suggest to contact Cygwin/MinGW people explaining your problem/system. Ciao, Angelo.
Re: Loop induction variable optimization question
On Thu, 2013-06-20 at 03:16 -0700, Stephen Clarke wrote: > > why (and where) did ivopts decide to move the post-increments above the > > usages in the first loop? > > It looks rather like the transformation described next to > tree-ssa-loop-ivopts.c/adjust_iv_update_pos. Yes, that looks like the place. Unfortunately, at that point everything is controlled by the cost of the various IV choices and I think that is what I need to change. Just to explain what is happening, the MIPS ProAptiv chip has what is known as 'memory bonding' where two sequential 4 byte loads can be handled as one 8 byte load (if the alignment is right). So I want to keep all the loads in a sequence and with no intervening instructions in order to improve the chances of memory bonding happening. With a memcpy style loop and loop unrolling the IV optimization is changing my ideal loop: .L4: addiu $8,$8,8 lw $14,0($7) lw $13,4($7) lw $12,8($7) lw $11,12($7) lw $15,16($7) lw $24,20($7) lw $5,24($7) lw $25,28($7) addiu $7,$7,32 sw $14,0($3) sw $13,4($3) sw $12,8($3) sw $11,12($3) sw $15,16($3) sw $24,20($3) sw $5,24($3) sw $25,28($3) bne $8,$6,.L4 addiu $3,$3,32 into this: .L4: addiu $8,$8,8 lw $13,0($7) lw $12,4($7) lw $14,8($7) lw $15,12($7) lw $24,16($7) lw $5,20($7) lw $25,24($7) addiu $7,$7,32 sw $13,0($3) sw $12,4($3) sw $14,8($3) sw $15,12($3) sw $24,16($3) sw $5,20($3) sw $25,24($3) addiu $3,$3,32 lw $4,-4($7) bne $8,$6,.L4 sw $4,-4($3) And so I lose one of my bonding opportunities because of the lw/sw that are done after incrementing registers $7 and $3. I think what I need to fix this is a target specific way to modify the cost calculations before the IV variables are chosen. Steve Ellcey sell...@mips.com
build error in libgcc
A make clean followed by a make in the libgcc directory results in: ../../../../gcc/libgcc/config/i386/cpuinfo.c:23:25: fatal error: auto-target.h: No such file or directory #include "auto-target.h" Oh, the the old days, we'd just add a dependancy… If someone knows where to add just the right one… I ask, because there doesn't seem to be a single .h dependency anywhere…
Re: [PR43721] Failure to optimise (a/b) and (a%b) into single call
On 17/06/13 19:07, Richard Biener wrote:
On Mon, 17 Jun 2013, Kugan wrote:
Hi,
I am attempting to fix Bug 43721 - Failure to optimise (a/b) and (a%b) into
single __aeabi_idivmod call
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43721)
execute_cse_sincos tree level pass does similar cse so I attempted to use
similar approach here. Div/mod cse is not really using built-in functions
though at this level.
The issue with performing the transform at the same time as we
transform SINCOS is that the vectorizer will now no longer be able
to vectorize these loops. It would need to be taught how to
handle the builtin calls (basically undo the transformation, I don't
know of any ISA that can do vectorized combined div/mod). Which
means it should rather be done at the point we CSE reciprocals
(which also replaces computes with builtin target function calls).
Thanks Richard. Since execute_cse_reciprocals is handling reciprocals
only, I added another pass to do divmod. Is that OK?
For the case of div and mod operations, after CSE is performed, there isnt a
way to represent the resulting stament in gimple. We will endup with divmod
taking two arguments and returning double the size of one arguments in the
three address format (divmod will return reminder and quotient so the return
type is double the size of argument type).
Since GIMPLE_ASSIGN will result in type checking failure in this case, I
atempted use built-in functions (GIMPLE_CALL to represent the runtime library
call). Name for the function here is target specific and can be obtained from
sdivmod_optab so the builtin function name defined in tree level is not used.
I am not entirelt sure this is the right approach so I am attaching the first
cut of the patch to get your feedback and understand the right approach to
this problem.
If we don't want to expose new builtins to the user (I'm not sure we
want that), then using "internal functions" is an easier way to
avoid these issues (see gimple.h and internal-fn.(def|h)).
I have now changed to use internal functions. Thanks for that.
Generally the transform looks useful to me as it moves forward with
the general idea of moving pattern recognition done during RTL expansion
to an earlier place.
For the use of a larger integer type and shifts to represent
the modulo and division result I don't think that's the very best
idea. Instead resorting to a complex integer type as return
value looks more appealing (similar to sincos using cexpi here).
That way you also avoid the ugly hard-coding of bit-sizes.
I have changed it to use complex integers now.
+ if (HAVE_divsi3
+ || (GET_MODE_BITSIZE (TYPE_MODE (type)) != 32)
watch out for types whose TYPE_PRECISION is not the bitsize
of their mode. Also it should be GET_MODE_PRECISION here.
+ || !optab_libfunc (TYPE_UNSIGNED (type)? udivmod_optab :
sdivmod_optab,
+TYPE_MODE (type)))
targets that use a libfunc should also get this optimization, as
it always removes computations. I think the proper test is
for whether the target can do division and/or modulus without
using a libfunc, not whether there is a divmod optab/libfunc.
I guess best way to do is by defining a target hook and let the target
define the required behaviour. Is that what you had in mind?
I have attached a modified patch with these changes.
Others knowing this piece of the compiler better may want to comment
here, of course.
Thanks,
Richard.
Thanks,
Kugan
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index f030b56..3fae80e 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -11375,3 +11375,8 @@ It returns true if the target supports GNU indirect functions.
The support includes the assembler, linker and dynamic linker.
The default value of this hook is based on target's libc.
@end deftypefn
+
+@deftypefn {Target Hook} bool TARGET_COMBINE_DIVMOD (enum machine_mode @var{mode})
+This target hook returns @code{true} if the target provides divmod libcall operation for the machine mode @var{mode} and must be used to combine integer division and modulus operations. Return @code{false} otherwise.
+@end deftypefn
+
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index cc25fec..12974b1 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -11198,3 +11198,6 @@ memory model bits are allowed.
@hook TARGET_ATOMIC_TEST_AND_SET_TRUEVAL
@hook TARGET_HAS_IFUNC_P
+
+@hook TARGET_COMBINE_DIVMOD
+
diff --git a/gcc/internal-fn.c b/gcc/internal-fn.c
index b841abd..0db06f1 100644
--- a/gcc/internal-fn.c
+++ b/gcc/internal-fn.c
@@ -61,6 +61,62 @@ get_multi_vector_move (tree array_type, convert_optab optab)
return icode;
}
+/* Expand DIVMOD call STMT. */
+static void
+expand_DIVMOD (gimple stmt)
+{
+ tree type, lhs, arg0, arg1;
+ rtx op0, op1, res0, res1, target;
+ enum machine_mode mode, compute_mode;
+ rtx libval;
+ rtx libfunc = NULL_RTX;
+ bool is_unsigned;
+
+ lhs = gimple_call_lhs (stmt);
+ arg0 = gimple_call_arg (s
Re: There is a -Wenum-compare warning in gcc/c-family/array-notation-common.c
2013/6/16 Chung-Ju Wu : > Hi Balaji, > > I was building a native gcc with trunk r200117, > but I noticed the following code fragment cause -Wenum-compare warning: > > > [gcc/c-family/array-notation-common.c] > > 483 /* This function is used by C and C++ front-ends. In C++, additional > 484 tree codes such as TARGET_EXPR must be eliminated. These codes are > 485 passed into additional_tcodes and are walked through and checked. */ > 486 for (ii = 0; ii < vec_safe_length (i_list->additional_tcodes); ii++) > 487 if (TREE_CODE (*tp) == (enum rid)(*(i_list->additional_tcodes))[ii]) > 488 *walk_subtrees = 0; > > > /gcc-4.9.0/gcc/c-family/array-notation-common.c: In function > 'tree_node* find_inv_trees(tree_node**, int*, void*)': > /gcc-4.9.0/gcc/c-family/array-notation-common.c:487:68: warning: > comparison between 'enum tree_code' and 'enum rid' [-Wenum-compare] > if (TREE_CODE (*tp) == (enum rid)(*(i_list->additional_tcodes))[ii]) > ^ > Thanks, Balaji, I can see this warning is fixed with following patch: http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01217.html http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=200272 Best regards, jasonwucj
