gcc-ow...@gcc.gnu.org wrote on 11/12/2009 20:25:33:
> Allan Sandfeld Jensen
> Hi
>
> I hope someone can help me. I've been trying to write some tight
> integer loops
> in way that could be auto-vectorized, saving me to write assembler or
using
> specific vectorization extensions. Unfortunately
Hi, All,
I have noticed that the latest ports of GCC (e.g. i386) use a
pseudo-register (argp in i386) defined as fixed in FIXED_REGISTERS.
When I implement it similarly in msp430 port (instead of hardware
register r5, add a pseudo-register marked as fixed), GCC perfectly
work
For those who have been following my adventure in the world of IRA, or
just
want to take advantage of some of the time I've spent on this, here's a
detailed recap of my exploits and my current status (which I'm very
happy
with):
I initially thought IRA was calculating costs wrongly for our
archite
Hello,
> I unroll the following code one times in a gimpile pass.
Can you please post the flags you used and the full test?
I can try to reproduce this.
Thanks,
Revital
On Mon, Dec 14, 2009 at 2:08 PM, Revital1 Eres wrote:
> Hello,
>
>> I unroll the following code one times in a gimpile pass.
>
> Can you please post the flags you used and the full test?
> I can try to reproduce this.
insn 53 (set (mem/s:SF (reg:SI 234 [ ivtmp.51 ]) (reg:SF 245))
//reg245->a[i]
Hi,
I tried the "m*n example" with my prototype code generator for fully
parametric domains (which is not publicly available, yet) - sorry for
the delayed reply.
To be precise, the input is the iteration domain
0 <= j <= m-1
0 <= i <= n-1
for iterators j,i and scattering
k = j + m*i
(I bas
See here:
http://embed.cs.utah.edu/embarrassing/
There is a lot of data there. Please excuse bugs and other problems.
Feedback would be appreciated.
John Regehr
John Regehr writes:
> See here:
>
> http://embed.cs.utah.edu/embarrassing/
>
> There is a lot of data there. Please excuse bugs and other
> problems. Feedback would be appreciated.
>
I was a bit surprised by the icc results, because traditionally icc doesn't
have a good reputation for good co
I wonder if the original program was already broken or was this
something your conversion introduced?
Not sure about this specific case but I'm sure there's some of each.
I also noticed these testcases but decided to leave them in for now.
Obviously the code is useless, but it can still be int
On Mon, Dec 14, 2009 at 09:30:57AM -0700, John Regehr wrote:
> I also noticed these testcases but decided to leave them in for now.
> Obviously the code is useless, but it can still be interpreted according to
> the C standard, and code can be generated. Once you start going down the
> road of
This is the beta release of binutils 2.20.51.0.4 for Linux, which is
based on binutils 2009 1214 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been
On Mon, Dec 14, 2009 at 06:17:45PM +0100, Andi Kleen wrote:
> I personally feel that test cases that get optimized away are not
> very interesting.
Actually, I think they're very interesting - especially if they are
valid code, and one compiler optimizes them away, but the other
doesn't. You may
On Mon, Dec 14, 2009 at 5:30 PM, John Regehr wrote:
>> I wonder if the original program was already broken or was this
>> something your conversion introduced?
>
> Not sure about this specific case but I'm sure there's some of each.
>
> I also noticed these testcases but decided to leave them in f
Hello!
I noticed the following on ARM, GCC trunk -- didn't check yet whether it
is ARM-specific; may be a general issue.
Hacking out the forcing-off of emitting CFI statements in arm.c, I see
the following function prologue emitted (-O -g):
.text
.Ltext0:
.cfi_section
Ok, thanks for the feedback Andi. Incidentally, the LLVM folks seem to
agree with both of your suggestions. I'll re-run everything w/o frame
pointers and ignoring testcases where some compiler warns about use of
uninitialized local. I hate the way these warnings are not totally
reliable, but
My opinion is that code containing undefined behaviors is definitely
interesting, but probably it is interesting in a different way than
functions that are more meaningful.
If I have time I'll just separate out the testcases into two groups: one
containing functions that are more or less sensi
On Mon, Dec 14, 2009 at 12:36:00PM -0800, John Regehr wrote:
> My opinion is that code containing undefined behaviors is definitely
> interesting, but probably it is interesting in a different way than
> functions that are more meaningful.
Optimizations based on uninitialized variables make me v
Dear all,
I wanted to add an instruction via a builtin to allow users to take
advantage of some special instructions that are on my architecture.
However, the latency of the instruction is not 1 so I'll also need to
handle it in the rtx_costs function.
I had first tried to explain with the curre
Optimizations based on uninitialized variables make me very nervous.
If uninitialized memory reads are transformed into don't-cares, then
checking tools like valgrind will no longer see the UMR (assuming that
the lack of initialization is a bug).
Did I understand that icc does this? It seems lik
On Mon, Dec 14, 2009 at 04:46:59PM -0500, Jean Christophe Beyler wrote:
> My current solution:
>
> - Define a new rtl in rtl.def
Just use an unspec or unspec_volatile. You don't need a new RTL
operation.
> - Add the new rtl in the MD file and the generated assembly instruction
>
> However, the
On Mon, Dec 14, 2009 at 01:53:30PM -0800, John Regehr wrote:
> > Optimizations based on uninitialized variables make me very nervous.
> > If uninitialized memory reads are transformed into don't-cares, then
> > checking tools like valgrind will no longer see the UMR (assuming that
> > the lack of i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
undefined reference to `std::string::reserve(unsigned long long)'
Link of libgmpxx fails:
/bin/sh ./libtool --mode=link g++ -O2 -pedantic -m64 -mtune=k8 -o libgmpxx.la
- -rpath /home/rainer/tmp/install/lib -no-undefined -Wl,--export-all-symbols
-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
in libstdc++.la:
for i686-pc-mingw32:
dependency_libs='
-
-L/home/rainer/software/build/i686-pc/i686-pc/i686-pc/gcc-4.5.0/gcc-4.5.0/i686-pc-mingw32/libstdc++-v3/src
-
-L/home/rainer/software/build/i686-pc/i686-pc/i686-pc/gcc-4.5.0/gcc-4.5.0/i686-pc-mi
On Mon, Dec 14, 2009 at 5:04 PM, Daniel Jacobowitz wrote:
> On Mon, Dec 14, 2009 at 04:46:59PM -0500, Jean Christophe Beyler wrote:
>> My current solution:
>>
>> - Define a new rtl in rtl.def
>
> Just use an unspec or unspec_volatile. You don't need a new RTL
> operation.
I thought of that but t
On Mon, Dec 14, 2009 at 05:52:50PM -0500, Jean Christophe Beyler wrote:
> I thought of that but then how do I add the cost ? I also have another
> problem: there is a second instruction that would have the exact same
> signature if I use an unspec.
>
> Is there a solution for that and how do I han
Ivan Shcherbakov writes:
> I have noticed that the latest ports of GCC (e.g. i386) use a
> pseudo-register (argp in i386) defined as fixed in FIXED_REGISTERS.
> When I implement it similarly in msp430 port (instead of hardware
> register r5, add a pseudo-register marked as fi
Hi,
I have noticed a big performance decrease in one of my numerical codes
when switching from gcc 4.4 to gcc 4.5. A small test case is attached.
When compiling this test case with "gcc -O3 perf.c -lm -std=c99"
and executing the resulting binary, the CPU time with the head of
the 4.4 branch is ab
On Mon, Dec 14, 2009 at 3:50 PM, Martin Reinecke
wrote:
> Hi,
>
> I have noticed a big performance decrease in one of my numerical codes
> when switching from gcc 4.4 to gcc 4.5. A small test case is attached.
> When compiling this test case with "gcc -O3 perf.c -lm -std=c99"
> and executing the r
I would only be worried for cases where no warning is issued *and*
unitialized accesses are eliminated.
Yeah, it would be excellent if GCC maintained the invariant that for all
uses of uninitialized storage, either the compiler or else valgrind will
issue a warning.
We could test for violati
Bonjour,
Le premier MOTEUR DE RECHERCHE IMMOBILIER du Maroc. Toutes les
annonces immobilières du web marocain dans un SEUL site :
http://www.maskane.com/
Maskane, le Google de l'immobilier au Maroc, affiche des annonces
provenant de plusieurs sites immobiliers. Avec ce site, notre ambition
est
In previous a[],b[],c[] are global arrays,
while they are local arrays,GCC works well.
Thanks
2009/12/14 Revital1 Eres :
> Hello,
>
>> I unroll the following code one times in a gimpile pass.
>
> Can you please post the flags you used and the full test?
> I can try to reproduce this.
>
> Thanks,
John Regehr wrote:
I wonder if the original program was already broken or was this
something your conversion introduced?
Not sure about this specific case but I'm sure there's some of each.
I also noticed these testcases but decided to leave them in for now.
Obviously the code is useless, but
John Regehr wrote:
Optimizations based on uninitialized variables make me very nervous.
If uninitialized memory reads are transformed into don't-cares, then
checking tools like valgrind will no longer see the UMR (assuming that
the lack of initialization is a bug).
Well that's the way things ar
John Regehr wrote:
I would only be worried for cases where no warning is issued *and*
unitialized accesses are eliminated.
Yeah, it would be excellent if GCC maintained the invariant that for all
uses of uninitialized storage, either the compiler or else valgrind will
issue a warning.
I fin
34 matches
Mail list logo
