Coldfire doc glitch
Hi Richard, I found the following in my build logs, and thought it was worth reporting to you. Although I don't speak texinfo, the lines in questions are the ones introduced by your ColdFire 9/63 patch (commited as rev. 120713): perl /home/fxcoudert/gfortran_nightbuild/trunk/gcc/../contrib/texi2pod.pl /home/fxcoudert/gfortran_nightbuild/trunk/gcc/doc/invoke.texi > gcc.pod @table ended by @end multitable at line 10424 make[3]: [gcc.pod] Error 9 (ignored) Thanks, FX
Re: Scheduling an early complete loop unrolling pass?
On Tue, 6 Feb 2007, Dorit Nuzman wrote: > > Hi Richard, > > > > > ... > > However..., > > > > I have seen cases in which complete unrolling before vectorization > enabled > > constant propagation, which in turn enabled significant simplification of > > the code, thereby, in fact making a previously unvectorizable loop (at > > least on some targets, due to the presence of divisions, unsupported in > the > > vector unit), into a loop (in which the divisions were replaced with > > constants), that can be vectorized. > > > > Also, given that we are working on "SLP" kind of technology (straight > line > > code vectorization), which would make vectorization less sensitive to > > unrolling, I think maybe it's not such a bad idea after all... One option > > is to increase the default value of --param min-vect-loop-bound for now, > > and when SLP is incorporated, go ahead and schedule early complete > > unrolling. However, since SLP implementation may take some time > (hopefully > > within the time frame of 4.3 though) - we could just go ahead and > schedule > > early complete unrolling right now. (I can't believe I'm in favor of this > > idea, but that loop I was talking about before - improved by a factor > over > > 20x when early complete unrolling + subsequent vectorization were > > applied...) > > > > After sleeping on it, it actually makes a lot of sense to me to schedule > complete loop unrolling before vectorization - I think it would either > simplify loops (sometimes creating more opportunities for vectorization), > or prevent vectorization of loops we probably don't want to vectorize > anyhow, and even that - only temporarily - until we have straight-line-code > vectorization in place. So I'm all for it. Ok, I'll dig out the patches I had for this and will do some SPEC runs. As soon as I have time for this (no hurry necessary here I think). Thanks! Richard. -- Richard Guenther <[EMAIL PROTECTED]> Novell / SUSE Labs
Re: Scheduling an early complete loop unrolling pass?
Richard Guenther <[EMAIL PROTECTED]> wrote on 06.02.2007 11:19:15: > On Tue, 6 Feb 2007, Dorit Nuzman wrote: > > After sleeping on it, it actually makes a lot of sense to me to schedule > > complete loop unrolling before vectorization - I think it would either > > simplify loops (sometimes creating more opportunities for vectorization), > > or prevent vectorization of loops we probably don't want to vectorize > > anyhow, and even that - only temporarily - until we have straight-line-code > > vectorization in place. So I'm all for it. > > Ok, I'll dig out the patches I had for this and will do some SPEC > runs. As soon as I have time for this (no hurry necessary here I think). We have some benchmarks where complete unrolling of innermost loop expose an opportunity to vectorize an outer loop. Usually complete unrolling reveal some opportunities for constant propagation and dead code elimination, so, probably there is need to rerun ccp, store_cpp, dse and dce between complete unrolling and vectorizer. I would be glad to help with running of SPEC on PPC. -- Victor
Re: Scheduling an early complete loop unrolling pass?
Dorit Nuzman/Haifa/IBM wrote on 05/02/2007 21:13:40:
> Richard Guenther <[EMAIL PROTECTED]> wrote on 05/02/2007 17:59:00:
>
> > On Mon, 5 Feb 2007, Paolo Bonzini wrote:
> >
> > >
> > > > As we also only vectorize innermost loops I believe doing a
> > > > complete unrolling pass early will help in general (I pushed
> > > > for this some time ago).
> > > >
> > > > Thoughts?
> > >
> > > It might also hurt, though, since we don't have a basic block
vectorizer.
> > > IIUC the vectorizer is able to turn
> > >
> > > for (i = 0; i < 4; i++)
> > > v[i] = 0.0;
> > >
> > > into
> > >
> > > *(vector double *)v = (vector double){0.0, 0.0, 0.0, 0.0};
> >
> > That's true.
>
> That's going to change once this project goes in: "(3.2) Straight-
> line code vectorization" from http://gcc.gnu.
> org/wiki/AutovectBranchOptimizations. In fact, I think in autovect-
> branch, if you unroll the above loop it should get vectorized
> already. Ira - is that really the case?
The completely unrolled loop will not get vectorized because the code will
not be inside any loop (and our SLP implementation will focus, at least as
a first step, on loops).
The following will get vectorized (without permutation on autovect branch,
and with redundant permutation on mainline):
for (i = 0; i < n; i++)
{
v[4*i] = 0.0;
v[4*i + 1] = 0.0;
v[4*i + 2] = 0.0;
v[4*i + 3] = 0.0;
}
The original completely unrolled loop will get vectorized if it is
encapsulated in an outer-loop, like so:
for (j=0; j
Re: Scheduling an early complete loop unrolling pass?
Ira Rosen/Haifa/IBM wrote on 06/02/2007 11:49:17:
> Dorit Nuzman/Haifa/IBM wrote on 05/02/2007 21:13:40:
>
> > Richard Guenther <[EMAIL PROTECTED]> wrote on 05/02/2007 17:59:00:
> >
...
> >
> > That's going to change once this project goes in: "(3.2) Straight-
> > line code vectorization" from http://gcc.gnu.
> > org/wiki/AutovectBranchOptimizations. In fact, I think in autovect-
> > branch, if you unroll the above loop it should get vectorized
> > already. Ira - is that really the case?
>
> The completely unrolled loop will not get vectorized because the
> code will not be inside any loop (and our SLP implementation will
> focus, at least as a first step, on loops).
Ah, right... I wonder if we can keep the loop structure in place, even
after completely unrolling the loop - I mean the 'struct loop' in
'current_loops' (not the actual CFG), so that the "SLP in loops" would have
a chance to at least consider vectorizing this "loop". Zdenek - what do you
say?
thanks,
dorit
> The following will get vectorized (without permutation on autovect
> branch, and with redundant permutation on mainline):
>
> for (i = 0; i < n; i++)
> {
> v[4*i] = 0.0;
> v[4*i + 1] = 0.0;
> v[4*i + 2] = 0.0;
> v[4*i + 3] = 0.0;
> }
>
> The original completely unrolled loop will get vectorized if it is
> encapsulated in an outer-loop, like so:
>
> for (j=0; j {
> for (i = 0; i < 4; i++)
> v[i] = 0.0;
> v += 4;
> }
>
> Ira
Re: Scheduling an early complete loop unrolling pass?
On Tue, 6 Feb 2007, Dorit Nuzman wrote: > Ira Rosen/Haifa/IBM wrote on 06/02/2007 11:49:17: > > > Dorit Nuzman/Haifa/IBM wrote on 05/02/2007 21:13:40: > > > > > Richard Guenther <[EMAIL PROTECTED]> wrote on 05/02/2007 17:59:00: > > > > ... > > > > > > That's going to change once this project goes in: "(3.2) Straight- > > > line code vectorization" from http://gcc.gnu. > > > org/wiki/AutovectBranchOptimizations. In fact, I think in autovect- > > > branch, if you unroll the above loop it should get vectorized > > > already. Ira - is that really the case? > > > > The completely unrolled loop will not get vectorized because the > > code will not be inside any loop (and our SLP implementation will > > focus, at least as a first step, on loops). > > Ah, right... I wonder if we can keep the loop structure in place, even > after completely unrolling the loop - I mean the 'struct loop' in > 'current_loops' (not the actual CFG), so that the "SLP in loops" would have > a chance to at least consider vectorizing this "loop". Zdenek - what do you > say? Well, usually if it's not inside another loop it can't be performance critical ;) At least if there would be a setup cost for the vectorized variant. I don't think we need to worry about this case until a real testcase for this comes along. Richard. -- Richard Guenther <[EMAIL PROTECTED]> Novell / SUSE Labs
Add texi2pod.pl support for @multitable (was Re: Coldfire doc glitch)
"François-Xavier Coudert" <[EMAIL PROTECTED]> writes:
> I found the following in my build logs, and thought it was worth
> reporting to you. Although I don't speak texinfo, the lines in
> questions are the ones introduced by your ColdFire 9/63 patch
> (commited as rev. 120713):
>
> perl /home/fxcoudert/gfortran_nightbuild/trunk/gcc/../contrib/texi2pod.pl
> /home/fxcoudert/gfortran_nightbuild/trunk/gcc/doc/invoke.texi >
> gcc.pod
> @table ended by @end multitable at line 10424
> make[3]: [gcc.pod] Error 9 (ignored)
Ugh, thanks for the heads-up. This patch adds some rudimentary
support for @multitable. As far as I know, perldoc doesn't have
anything equivalent to multi-column tables, so I just treated them
as itemized lists and used ":" as a column separator. The gcc.1
rendering doesn't look as bad as you might think.
Tested by examining the gcc.1 output. OK to install?
Richard
contrib/
* texi2pod.pl: Handle @multitable.
Index: contrib/texi2pod.pl
===
--- contrib/texi2pod.pl (revision 121640)
+++ contrib/texi2pod.pl (working copy)
@@ -162,6 +162,8 @@ while(<$inf>) {
} elsif ($ended =~ /^(?:itemize|enumerate|[fv]?table)$/) {
$_ = "\n=back\n";
$ic = pop @icstack;
+ } elsif ($ended eq "multitable") {
+ $_ = "\n=back\n";
} else {
die "unknown command [EMAIL PROTECTED] $ended at line $.\n";
}
@@ -278,6 +280,12 @@ while(<$inf>) {
$endw = "enumerate";
};
+/[EMAIL PROTECTED]/ and do {
+ push @endwstack, $endw;
+ $endw = "multitable";
+ $_ = "\n=over 4\n";
+};
+
/^\@([fv]?table)\s+([EMAIL PROTECTED])/ and do {
push @endwstack, $endw;
push @icstack, $ic;
@@ -297,6 +305,16 @@ while(<$inf>) {
$_ = "";# need a paragraph break
};
+/[EMAIL PROTECTED](.*\S)\s*$/ and $endw eq "multitable" and do {
+ @columns = ();
+ for $column (split (/[EMAIL PROTECTED]/, $1)) {
+ # @strong{...} is used a @headitem work-alike
+ $column =~ s/[EMAIL PROTECTED](.*)}$/$1/;
+ push @columns, $column;
+ }
+ $_ = "\n=item ".join (" : ", @columns)."\n";
+};
+
/[EMAIL PROTECTED](.+)?$/ and do {
if (defined $1) {
# Entity escapes prevent munging by the <> processing below.
ICE in gcc/libgcc2.c:566
Hi list! First, I am not subscribed to this list, so please CC me on answers, thanks! I try to build gcc trunk (r121622) on x86_64/core2duo but I get an ICE. Thanks for any help in advance! Regards, Hanno ___ Build config: # ./xgcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /mnt/data/tmp/portage/dev-java/gcj-4.3.0_alpha20070202/work/gcc/configure --prefix=/usr/lib/gcj-4.3.0_alpha20070202 --libdir=/usr/lib/gcj-4.3.0_alpha20070202/lib64 --libexecdir=/usr/lib/gcj-4.3.0_alpha20070202/lib64 --with-gxx-include-dir=/usr/lib/gcj-4.3.0_alpha20070202/include/c++ --enable-languages=c,c++,java --enable-ssp --enable-libstdcxx-allocator=new --disable-static --disable-altivec --disable-gtktest --disable-glibtest --disable-multilib --disable-maintainer-mode --disable-libada --disable-libarttest --disable-libjava-multilib --disable-libmudflap --disable-libssp --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-libunwind-exceptions --enable-nls --without-included-gettext --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-java-awt=gtk --enable-plugin --disable-gconf-peer --with-java-home=/usr/lib/gcj-4.3.0_alpha20070202/jre Thread model: posix gcc version 4.3.0-alpha20070202 (experimental) (Gentoo 4.3.0_alpha20070202) ___ Build started with: make profiledbootstrap ___ Build error: make[4]: Leaving directory `/mnt/data/tmp/portage/dev-java/gcj-4.3.0_alpha20070202/work/build/x86_64-unknown-linux-gnu/libgcc' /mnt/data/tmp/portage/dev-java/gcj-4.3.0_alpha20070202/work/build/./gcc/xgcc -B/mnt/data/tmp/portage/dev-java/gcj-4.3.0_alpha20070202/work/build/./gcc/ -B/usr/lib/gcj-4.3.0_alpha20070202/x86_64-unknown-linux-gnu/bin/ -B/usr/lib/gcj-4.3.0_alpha20070202/x86_64-unknown-linux-gnu/lib/ -isystem /usr/lib/gcj-4.3.0_alpha20070202/x86_64-unknown-linux-gnu/include -isystem /usr/lib/gcj-4.3.0_alpha20070202/x86_64-unknown-linux-gnu/sys-include -O2 -mtune=nocona -march=nocona -pipe -g -msse3 -mfpmath=sse -O2 -O2 -O2 -mtune=nocona -march=nocona -pipe -g -msse3 -mfpmath=sse -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I/mnt/data/tmp/portage/dev-java/gcj-4.3.0_alpha20070202/work/gcc/libgcc -I/mnt/data/tmp/portage/dev-java/gcj-4.3.0_alpha20070202/work/gcc/libgcc/. -I/mnt/data/tmp/portage/dev-java/gcj-4.3.0_alpha20070202/work/gcc/libgcc/../gcc -I/mnt/data/tmp/portage/dev-java/gcj-4.3.0_alpha20070202/work/gcc/libgcc/../include -I/mnt/data/tmp/portage/dev-java/gcj-4.3.0_alpha20070202/work/gcc/libgcc/../libdecnumber -I../../libdecnumber -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c /mnt/data/tmp/portage/dev-java/gcj-4.3.0_alpha20070202/work/gcc/libgcc/../gcc/libgcc2.c \ -fvisibility=hidden -DHIDE_EXPORTS /mnt/data/tmp/portage/dev-java/gcj-4.3.0_alpha20070202/work/gcc/libgcc/../gcc/libgcc2.c: In function ‘__multi3’: /mnt/data/tmp/portage/dev-java/gcj-4.3.0_alpha20070202/work/gcc/libgcc/../gcc/libgcc2.c:566: internal compiler error: Speicherzugriffsfehler (segmentation fault) Please submit a full bug report, with preprocessed source if appropriate. See http://bugs.gentoo.org/> for instructions. make[3]: *** [_muldi3.o] Fehler 1 make[3]: Leaving directory `/mnt/data/tmp/portage/dev-java/gcj-4.3.0_alpha20070202/work/build/x86_64-unknown-linux-gnu/libgcc' make[2]: *** [all-stagefeedback-target-libgcc] Fehler 2 make[2]: Leaving directory `/mnt/data/tmp/portage/dev-java/gcj-4.3.0_alpha20070202/work/build' make[1]: *** [stagefeedback-bubble] Fehler 2 make[1]: Leaving directory `/mnt/data/tmp/portage/dev-java/gcj-4.3.0_alpha20070202/work/build' make: *** [profiledbootstrap] Fehler 2 ___ GDB info: Program received signal SIGSEGV, Segmentation fault. 0x0055e7a8 in count_pseudo (reg=71) at /mnt/data/tmp/portage/dev-java/gcj-4.3.0_alpha20070202/work/gcc/gcc/reload1.c:1636 1636 nregs = hard_regno_nregs[r][PSEUDO_REGNO_MODE (reg)]; (gdb) print r $2 = -1 (gdb) bt #0 0x0055e7a8 in count_pseudo (reg=71) at /mnt/data/tmp/portage/dev-java/gcj-4.3.0_alpha20070202/work/gcc/gcc/reload1.c:1636 #1 0x005668a3 in reload (first=0x2b5e06f1c980, global=1) at /mnt/data/tmp/portage/dev-java/gcj-4.3.0_alpha20070202/work/gcc/gcc/reload1.c:1673 #2 0x007a900b in global_alloc () at /mnt/data/tmp/portage/dev-java/gcj-4.3.0_alpha20070202/work/gcc/gcc/global.c:628 #3 0x007a4e61 in rest_of_handle_global_alloc () at /mnt/data/tmp/portage/dev-java/gcj-4.3.0_alpha20070202/work/gcc/gcc/global.c:2516 #4 0x005246c6 in execute_one_pass (pass=0xa98c60) at /mnt/data/tmp/portage/dev-java/gcj-4.3.0_alpha20070202/work/gcc/gcc/passes.c:1024 #5 0x0052490a in execute_pass_list (pass=0xa98c60) at /mnt/data/tmp/portage/dev-java/gcj-4.3.0_alpha20070202/work/gcc/gcc/passes.c:1075 #6 0x
Re: Add texi2pod.pl support for @multitable (was Re: Coldfire doc glitch)
On Tue, 6 Feb 2007, Richard Sandiford wrote: > Ugh, thanks for the heads-up. This patch adds some rudimentary > support for @multitable. As far as I know, perldoc doesn't have > anything equivalent to multi-column tables, so I just treated them > as itemized lists and used ":" as a column separator. The gcc.1 > rendering doesn't look as bad as you might think. > > Tested by examining the gcc.1 output. OK to install? OK. -- Joseph S. Myers [EMAIL PROTECTED]
False ‘noreturn’ function does return warnings
In an OS kernel functions that do not return are commonly used and
practically always their code is beyond gcc's ability to recognize
noreturn functions. A typical example would for example be the BUG()
function in Linux which is implemented as something like:
static inline void __attribute__((noreturn)) BUG(void)
{
__asm__ __volatile__("trap");
}
So the code doesn't return but gcc isn't able to figure that out and the
caring programmer trying to help gcc to do a better job by adding the
noreturn is punished with
warning: ‘noreturn’ function does return
There are other such situations in plain C. A common solution is to add
something like like while(1) - but that does generate code. Quite a bit
for frequently called or very small functions. This frequently makes the
use of noreturn functions unattractive. So two suggested solutions:
1) Burry the warning for good. The programmer has explicitly said
noreturn so if the function does return it's his problem.
2) Introduce a __builtin_unreached() builtin function which tells gcc that
it not being reached, ever and does not generate any code. This could
be used like:
static inline void __attribute__((noreturn)) BUG(void)
{
__asm__ __volatile__("trap");
__builtin_unreached();
}
It would even conveniently be usable in macros or conditionals.
Ralf
Re: Scheduling an early complete loop unrolling pass?
> Richard Guenther <[EMAIL PROTECTED]> wrote on 05/02/2007 18:16:05: > > > On Mon, 5 Feb 2007, Jan Hubicka wrote: > ... > > > Did you run some benchmarks? > > > > Not yet - I'm looking at the C++ SPEC 2006 benchmarks at the moment > > and using vectorization there seems to do a lot of collateral damage > > (maybe not measurable though). > > > > Interesting. In SPEC 2000 there is also a hot small loop in the only C++ > benchmark (eon), which get vectorized, and as a result degrades > performance. We really should not vectorize such loops, and the solution > is: > 1. FORNOW: use --param min-vect-loop-bound=2 (or some value greater than > 0). Well, if Tomas manage to post his patch, I think the eon case is dealt with there too (the loop is just internal loop to zero tiny vector or something like that as long as I can remember) Honza > 2. SOON: rely on the vectorizer to do the cost analysis and decide not to > vectorize such loops, using a cost model - this is in the works. > > dorit > > > Richard. > > > > -- > > Richard Guenther <[EMAIL PROTECTED]> > > Novell / SUSE Labs
Possible regression with gcc 4.1.2 RC
Hi,
I tried to compile glibc 2.3.6 and 2.4 for an e500 target using
gcc-4.1.2-20070128.
I applied the proposed patch for PR30370 go get gcc compiled.
Unfortunately, glibc compilation fails. After some testing, I was able
to create a small test program - see below. It turns out that the
problem was introduced into the 4.1 branch between 11/17/06 and
11/24/06. gcc-4.2-20070131 also fails.
I tried both "--with-cpu=8540" and "--enable-e500-double --with-cpu=8548"
configuration options. gcc compiled for other powerpc/ppc targets
appears to be ok.
Has anyone besides me seen this problem ?
Thanks,
Guenter
Test code is as follows. Compile with any option for -me500 to see the
resulting error. Failing code in glibc is atomic_increment() in
elf/dl-profile.c,
line 550.
---
#define testmacro(mem) \
({ \
__typeof (*(mem)) __val; \
__asm __volatile (" addi%0,%2,1\n"\
: "=&b" (__val), "=m" (*mem)\
: "b" (mem), "m" (*mem) \
: "cr0", "memory"); \
__val;\
})
struct teststruct1
{
int count;
} __attribute__ ((packed));
struct teststruct2
{
int count;
};
void testfunc (struct teststruct1 *s1, struct teststruct2 *s2)
{
int v;
testmacro(&v);// ok
testmacro(&s1->count);// fails
testmacro(&s2->count);// ok
}
--
Compiler output:
$ ppc-teak-linuxspe1-gcc -c testcc.c
testcc.c: In function 'testfunc':
testcc.c:26: error: output number 1 not directly addressable
testcc.c:26: warning: use of memory input without lvalue in asm operand
3 is deprecated
Re: gcc-4.1.2 RC1 build problem
Hello Paolo, all, * Paolo Bonzini wrote on Mon, Feb 05, 2007 at 10:30:41AM CET: > > >The macro $(SYSTEM_HEADER_DIR) is used in a double-quoted context, > >leading to nonportable "...`..."..."...`...", [...] > >Proposed untested patch. (I also haven't checked whether there are > >other instances of this issue in 'make install' code.) > > If you or anybody can test this (better on an affected system, but even > i686-pc-linux-gnu would be ok), ok for mainline and all affected release > branches. With the patch, the gcc-4.1.2-20070128 tarball passes configure --enable-languages=c && gmake && gmake install on alphaev67-dec-osf5.1, and fails without it. Thanks for the review. Please note I don't have write access. Cheers, Ralf
Re: [c++] switch ( enum ) vs. default statment.
On Jan 29, 2007, "Manuel López-Ibáñez" <[EMAIL PROTECTED]> wrote: > * You can add a return 0 or an exit(1) at the end of the function or > in a default label. Since in your case the code is unreachable, the > optimiser may remove it or it will never be executed. But this would generate additional code for no useful purpose. See Ralf Baechle's posting with Subject: False ‘noreturn’ function does return warnings. /me thinks it would make sense for us to add a __builtin_unreachable() that would indicate to GCC that no further action is needed from that point on. A command-line flag could then tell whether GCC should generate abort() for such cases, or take a more general "undefined behavior" approach without generating additional code to that end. Meanwhile, there's __builtin_trap() already, and Ralf might use that even to remove the asm volatile, and Paweł could use it in a default: label. It's still worse than a __builtin_assume(e == X || e == Y), but it's probably much simpler to implement. But then, __builtin_unreachable() might very well be implemented as __builtin_assume(0). -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: After GIMPLE...
On 1/31/07, Diego Novillo <[EMAIL PROTECTED]> wrote: Paulo J. Matos wrote on 01/31/07 11:26: > So, ideally, I would like just the gcc part until the first part of > the middleend where you have a 'no optimizations', language > independent AST of the source file. > OK, so you probably want to inject your pass right before pass_build_ssa Why before pass_build_ssa? (version 4.1.1) I've tried this but for some reason my pass is not called unless I use -On where n > 0. Well, I guess it is because my pass is inside pass_all_optimizations.sub. So I guess the right thing would be to have it run in all_passes, after pass_init_datastructures. Is it or is it not a good idea to have it here. Was there any special reason for you to suggest me to put it before pass_build_ssa, inside optimization passes? Cheers, Paulo Matos (in init_optimization_passes). All the facilities to traverse the IL and flowgraph described in the Tree SSA section of the internals manual should apply. -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK
Re: Scheduling an early complete loop unrolling pass?
Hello,
> Ira Rosen/Haifa/IBM wrote on 06/02/2007 11:49:17:
>
> > Dorit Nuzman/Haifa/IBM wrote on 05/02/2007 21:13:40:
> >
> > > Richard Guenther <[EMAIL PROTECTED]> wrote on 05/02/2007 17:59:00:
> > >
> ...
> > >
> > > That's going to change once this project goes in: "(3.2) Straight-
> > > line code vectorization" from http://gcc.gnu.
> > > org/wiki/AutovectBranchOptimizations. In fact, I think in autovect-
> > > branch, if you unroll the above loop it should get vectorized
> > > already. Ira - is that really the case?
> >
> > The completely unrolled loop will not get vectorized because the
> > code will not be inside any loop (and our SLP implementation will
> > focus, at least as a first step, on loops).
>
> Ah, right... I wonder if we can keep the loop structure in place, even
> after completely unrolling the loop - I mean the 'struct loop' in
> 'current_loops' (not the actual CFG), so that the "SLP in loops" would have
> a chance to at least consider vectorizing this "loop". Zdenek - what do you
> say?
I do not think this is a good idea -- making the structures inconsistent
just to "fix" a pass that can be easily fixed in other way.
Zdenek
> thanks,
> dorit
>
> > The following will get vectorized (without permutation on autovect
> > branch, and with redundant permutation on mainline):
> >
> > for (i = 0; i < n; i++)
> > {
> > v[4*i] = 0.0;
> > v[4*i + 1] = 0.0;
> > v[4*i + 2] = 0.0;
> > v[4*i + 3] = 0.0;
> > }
> >
> > The original completely unrolled loop will get vectorized if it is
> > encapsulated in an outer-loop, like so:
> >
> > for (j=0; j > {
> > for (i = 0; i < 4; i++)
> > v[i] = 0.0;
> > v += 4;
> > }
> >
> > Ira
Re: [c++] switch ( enum ) vs. default statment.
On Tue, Feb 06, 2007 at 04:44:50PM -0200, Alexandre Oliva wrote: > > * You can add a return 0 or an exit(1) at the end of the function or > > in a default label. Since in your case the code is unreachable, the > > optimiser may remove it or it will never be executed. > > But this would generate additional code for no useful purpose. > See Ralf Baechle's posting with Subject: False ‘noreturn’ function > does return warnings. > > /me thinks it would make sense for us to add a __builtin_unreachable() > that would indicate to GCC that no further action is needed from that > point on. A command-line flag could then tell whether GCC should > generate abort() for such cases, or take a more general "undefined > behavior" approach without generating additional code to that end. > > Meanwhile, there's __builtin_trap() already, and Ralf might use that > even to remove the asm volatile, and Paweł could use it in a default: > label. It's still worse than a __builtin_assume(e == X || e == Y), > but it's probably much simpler to implement. But then, > __builtin_unreachable() might very well be implemented as > __builtin_assume(0). The Linux/MIPS BUG() macro uses a break 512 instruction while __builtin_trap() generates a plain break that is break 0 instruction. Aside of that __builtin_trap() would be fine ... Ralf
Re: [c++] switch ( enum ) vs. default statment.
On 06/02/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote: On Jan 29, 2007, "Manuel López-Ibáñez" <[EMAIL PROTECTED]> wrote: > * You can add a return 0 or an exit(1) at the end of the function or > in a default label. Since in your case the code is unreachable, the > optimiser may remove it or it will never be executed. But this would generate additional code for no useful purpose. See Ralf Baechle's posting with Subject: False 'noreturn' function does return warnings. GCC already generates additional code even if no explicit 'default' or 'return' is added. :-/ See the original PR c++/28236. Cheers, Manuel.
Re: [c++] switch ( enum ) vs. default statment.
On Tue, Feb 06, 2007 at 08:00:29PM +, Ralf Baechle wrote: > On Tue, Feb 06, 2007 at 04:44:50PM -0200, Alexandre Oliva wrote: > > Meanwhile, there's __builtin_trap() already, and Ralf might use that > > even to remove the asm volatile, and Paweł could use it in a default: > > label. It's still worse than a __builtin_assume(e == X || e == Y), > > but it's probably much simpler to implement. But then, > > __builtin_unreachable() might very well be implemented as > > __builtin_assume(0). > > The Linux/MIPS BUG() macro uses a break 512 instruction while > __builtin_trap() generates a plain break that is break 0 instruction. > Aside of that __builtin_trap() would be fine ... __builtin_break_512() ?
Re: False ???noreturn??? function does return warnings
> In an OS kernel functions that do not return are commonly used and
> practically always their code is beyond gcc's ability to recognize
> noreturn functions. A typical example would for example be the BUG()
> function in Linux which is implemented as something like:
>
> static inline void __attribute__((noreturn)) BUG(void)
> {
> __asm__ __volatile__("trap");
> }
>
> So the code doesn't return but gcc isn't able to figure that out and the
> caring programmer trying to help gcc to do a better job by adding the
Well, sadly caring programmer won't get optimization he wants as after
inlining this attribute information becomes completely lost.
What about __builtin_trap?
It results in int 6 that might not be applicable, but adding some
control over it to i386 backend is definitly an option.
> noreturn is punished with
>
> warning: ???noreturn??? function does return
>
> There are other such situations in plain C. A common solution is to add
> something like like while(1) - but that does generate code. Quite a bit
> for frequently called or very small functions. This frequently makes the
> use of noreturn functions unattractive. So two suggested solutions:
>
> 1) Burry the warning for good. The programmer has explicitly said
>noreturn so if the function does return it's his problem.
>
> 2) Introduce a __builtin_unreached() builtin function which tells gcc that
>it not being reached, ever and does not generate any code. This could
>be used like:
>
> static inline void __attribute__((noreturn)) BUG(void)
> {
> __asm__ __volatile__("trap");
> __builtin_unreached();
This is bit dificult to do in general since it introduces new kind of
control flow construct. It would be better to express such functions
explicitely to GCC.
Honza
> }
>
> It would even conveniently be usable in macros or conditionals.
>
> Ralf
Re: After GIMPLE...
Paulo J. Matos wrote on 02/06/07 14:19: Why before pass_build_ssa? (version 4.1.1) It depends on the properties your pass requires. If you ask for PROP_cfg and PROP_gimple_any then you should schedule it after the CFG has been built, but if you need PROP_ssa, then you must be after pass_build_ssa which implies that your pass only gets enabled at -O1+.
how to avoid duplicate warnings
I am implementing -Wstrict-aliasing by catching simple cases in the frontend and more complex ones in the backend. The frontend mechanism is tree pattern matching. The backend one uses flow-sensitive points-to information. I want to avoid duplicate warnings. I thought of a few ways, but none seems perfect. Can you please advise which of the following I should choose, suggest alternatives, or let me know if a solution exists. 1. Save location info for the warnings issued in the frontend + have the backend check before issuing warnings. This would be simple, but it involves communication between frontend and backend. 2. Turn off frontend checking at -O2 and let the backend do all the work. This might affect the applicability of the warning, as the code may be simplified before it gets to the warning check (although the common case would be caught). 3. Make the backend skip cases that are likely to be warned by the frontend. This is finicky because complex expression trees in the frontend are distributed over multiple GIMPLE statements by the time they reach the check in the backend. 4. Just allow duplicates. The problem of duplicates is actually more general and should be solved (is it already?) in a generic way for all warnings, and not just for -Wstrict-aliasing. Even the backend alone will issue duplicate warnings, e.g., when inlining a function from a header file causes type punning at or around several call sites. This may happen in the same or in several .c files that may be processed together by the compiler/LTO. With -Wstrict-aliasing this may be more common than with some other warnings, because type punning sometimes involves set/get methods that are usually inlined. Thank you, Silvius
Re: how to avoid duplicate warnings
On Tue, Feb 06, 2007 at 01:53:44PM -0800, Silvius Rus wrote: > I am implementing -Wstrict-aliasing by catching simple cases in the > frontend and more complex ones in the backend. The frontend mechanism > is tree pattern matching. The backend one uses flow-sensitive points-to > information. > > I want to avoid duplicate warnings. I thought of a few ways, but none > seems perfect. Can you please advise which of the following I should > choose, suggest alternatives, or let me know if a solution exists. All strict-aliasing violations involve accessing an object as the wrong type. However, there are some objects that can be accessed as any type without a violation, e.g. the result of malloc (or, more generally, void* in C). If you have a way to flag an object as "can alias to anything" once you warn about an error, you won't get duplicate warnings. If the exact same location is accessed incorrectly at another point, then the user might fix the first message and then see the second one, but this still might be better than a cascade of repetitive complaints (particularly for a tricky cast in a macro, which is really one error even if used repetitively).
Re: how to avoid duplicate warnings
Silvius Rus <[EMAIL PROTECTED]> writes: > I want to avoid duplicate warnings. I thought of a few ways, but none > seems perfect. Can you please advise which of the following I should > choose, suggest alternatives, or let me know if a solution exists. It may work to set and check TREE_NO_WARNING on the offending CONVERT_EXPR/NOP_EXPR. Ian
Re: false 'noreturn' function does return warnings
Back in 2000 I wrote a really simple patch that caused gcc to treat an ASM_OPERANDS that clobbered "pc" as a control flow barrier, exactly for this problem. http://gcc.gnu.org/ml/gcc-patches/2000-01/msg00190.html I still think it was a good idea, but at the time it was received unenthusiastically. I especially think "just use __builtin_trap()" misses the mark - at least some variants of the Linux kernel's BUG() macro, for instance, want to stick annotations in the assembly stream, which you cannot do with __builtin_trap... zw
Re: false 'noreturn' function does return warnings
Zack Weinberg wrote: > Back in 2000 I wrote a really simple patch that caused gcc to treat an > ASM_OPERANDS that clobbered "pc" as a control flow barrier, exactly > for this problem. > > http://gcc.gnu.org/ml/gcc-patches/2000-01/msg00190.html > > I still think it was a good idea, but at the time it was received > unenthusiastically. I especially think "just use __builtin_trap()" > misses the mark - at least some variants of the Linux kernel's BUG() > macro, for instance, want to stick annotations in the assembly stream, > which you cannot do with __builtin_trap... I agree. Adding options to make __builtin_trap do different things (like generate an abort signal in user applications and something else in kernel mode) is pretty nasty. Linux is a favorite GNU kernel, but there are lots of other kernels out there, and this could get comlicated in a hurry. I think clobbering the PC is a reasonably good way to represent a control-flow barrier at user level. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: false 'noreturn' function does return warnings
"Zack Weinberg" <[EMAIL PROTECTED]> writes: > Back in 2000 I wrote a really simple patch that caused gcc to treat an > ASM_OPERANDS that clobbered "pc" as a control flow barrier, exactly > for this problem. > > http://gcc.gnu.org/ml/gcc-patches/2000-01/msg00190.html > > I still think it was a good idea, but at the time it was received > unenthusiastically. I especially think "just use __builtin_trap()" > misses the mark - at least some variants of the Linux kernel's BUG() > macro, for instance, want to stick annotations in the assembly stream, > which you cannot do with __builtin_trap... I think we should just introduce __builtin_unreachable(), as others have suggested. I think that is more consonant with our usual approach to these issues. I also think it would be good to have one option affecting it: turn __builtin_unreachable() into an abort(), or turn it into a "cannot be reached" marker. I think the former should be the default at -O0, the latter at -O1 and above. Note that a "cannot be reached" marker permits further optimization to delete code which leads up to it. Actually implementing that further optimization may call for adding appropriate warnings, probably controlled by -Wunreachable-code. Ian
Re: false 'noreturn' function does return warnings
On Tue, Feb 06, 2007 at 04:14:30PM -0800, Ian Lance Taylor wrote: > I also think it would be good to have one option affecting it: turn > __builtin_unreachable() into an abort(), or turn it into a "cannot be > reached" marker. I think the former should be the default at -O0, the > latter at -O1 and above. > > Note that a "cannot be reached" marker permits further optimization to > delete code which leads up to it. Actually implementing that further > optimization may call for adding appropriate warnings, probably > controlled by -Wunreachable-code. Ouch. In the case that motivated this discussion, the instruction that would immediately go before the __builtin_unreachable() is a trap instruction, but the compiler does not know that it traps. It would be very bad if the compiler eliminated the trap, since it is the presence of the trap that keeps the function from returning.
Re: false 'noreturn' function does return warnings
Joe Buck <[EMAIL PROTECTED]> writes: > On Tue, Feb 06, 2007 at 04:14:30PM -0800, Ian Lance Taylor wrote: > > I also think it would be good to have one option affecting it: turn > > __builtin_unreachable() into an abort(), or turn it into a "cannot be > > reached" marker. I think the former should be the default at -O0, the > > latter at -O1 and above. > > > > Note that a "cannot be reached" marker permits further optimization to > > delete code which leads up to it. Actually implementing that further > > optimization may call for adding appropriate warnings, probably > > controlled by -Wunreachable-code. > > Ouch. > > In the case that motivated this discussion, the instruction that would > immediately go before the __builtin_unreachable() is a trap instruction, > but the compiler does not know that it traps. It would be very bad > if the compiler eliminated the trap, since it is the presence of the > trap that keeps the function from returning. Well, a trap instruction would presumably be volatile. The compiler would not eliminate a volatile instruction. Ian
Re: false 'noreturn' function does return warnings
On Feb 6, 2007, at 5:06 PM, Joe Buck wrote: On Tue, Feb 06, 2007 at 04:14:30PM -0800, Ian Lance Taylor wrote: I also think it would be good to have one option affecting it: turn __builtin_unreachable() into an abort(), or turn it into a "cannot be reached" marker. I think the former should be the default at -O0, the latter at -O1 and above. Note that a "cannot be reached" marker permits further optimization to delete code which leads up to it. Actually implementing that further optimization may call for adding appropriate warnings, probably controlled by -Wunreachable-code. I have experience with this approach, it works well: http://llvm.org/docs/LangRef.html#i_unreachable In the case that motivated this discussion, the instruction that would immediately go before the __builtin_unreachable() is a trap instruction, but the compiler does not know that it traps. It would be very bad if the compiler eliminated the trap, since it is the presence of the trap that keeps the function from returning. Nothing with side effects before an 'unreachable' can be removed, including an asm. Consider if the asm called a no-return function. -Chris
