Sebastian,
Here are, in addition, the numbers for compiling and
running HIRLAM with -ftree-loop-distribution (after applying your patch,
obviously).
There something weird going on with the count of the "loops not
vectorized" - every successfully vectorized loop gets an ad
Hello!
There something weird going on with the count of the "loops not
vectorized" - every successfully vectorized loop gets an additional
message:
note: not vectorized: vectorization may not beprofitable.
This is due to switching on vector cost model by default for x86.
BTW: Attached patc
On Dec 16, 2007, "Daniel Berlin" <[EMAIL PROTECTED]> wrote:
> There is no portion of the DWARF3 spec which requires you output
> information that is correct or useful. The same way the C standard
> does not require you to write correct programs, only valid ones, the
> DWARF3 spec does not require
On Dec 16, 2007, NightStrike <[EMAIL PROTECTED]> wrote:
> On 12/15/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
>> ... a good example of compliance with the GPL:
>>
>> 5. Conveying Modified Source Versions.
>>
>> a) The work must carry prominent notices stating that you modified
>> it, and giv
Uros Bizjak wrote:
note: not vectorized: vectorization may not beprofitable.
This is due to switching on vector cost model by default for x86.
Ah, but my hidden critique of the message was:
-ftree-vectorizer-verbose=2 should *only* tell us:
1. Which loops are vectorized.
2. Which are not
L.S.,
Recently, I've begun to bootstrap with make BOOT_CFLAGS="flags",
basically to get the run time libraries (libgfortran, libgomp) compiled
with -mcpu=native -mtune=native (the speed of the compiler doesn't
interest me that much).
However, I see that almost everything is compiled with -mc
> Uros Bizjak wrote:
>
> >> note: not vectorized: vectorization may not beprofitable.
> >
> > This is due to switching on vector cost model by default for x86.
>
> Ah, but my hidden critique of the message was:
> -ftree-vectorizer-verbose=2 should *only* tell us:
>
> 1. Which loops are vectorized.
Sebastian Pop wrote:
> I wrote:
rttov_aitosu.f90: In function 'rttov_aitosu':
rttov_aitosu.f90:4: error: definition in block 262 does not dominate use in
block 134
Worked around by compiling this file without -ftree-loop-linear
Could you verify that the attached patch fixes also this probl
On Wed, 12 Dec 2007, Dave Korn wrote:
> On 12 December 2007 12:14, Revital1 Eres wrote:
>
> > It seems that the pair m and I is missing (which indicate the memory =
> > constant instruction).
>
> So doesn't the question then become "Why isn't reload reloading the constant
> into a register"?
Ye
> Sebastian,
>
> Here are (attached) results for testing HIRLAM with and without
> -ftree-loop-linear.
>
> As you can see, the results are neutral: 4 loops fewer vectorized, but
> about 50 fewer recognized.
>
any chance you kept the dumps and can report which loops were not
vectorized/recognized
Here's a tentative patch to do that:
- removes the confusing printing "not vectorized: vectorization may not be
profitable" from REPORT_UNVECTORIZED_LOOPS
- instead print "vectorization may not be profitable" under a new verbosity
level REPORT_COST
- change (hopefully all) other cost-model printing
On Wed, 12 Dec 2007, a2220333 wrote:
> hi,
> I have been porting tic54x to gcc. I use gcc-4.2.2 version. I write some
> simplest c54x.h and c54x.c and a empty md, and I
I think the answer is right there
^^
> compil
Dorit Nuzman wrote:
any chance you kept the dumps and can report which loops were not
vectorized/recognized with -ftree-loop-linear (so we could see if these
represent missed vectorization opportunities?)
I haven't, but it wouldn't be too much effort do this.
I'll try stage 1 tonight - i.e.,
On Sun, 16 Dec 2007, Hans-Peter Nilsson wrote:
> On Wed, 12 Dec 2007, Dave Korn wrote:
>
> > On 12 December 2007 12:14, Revital1 Eres wrote:
> >
> > > It seems that the pair m and I is missing (which indicate the memory =
> > > constant instruction).
> >
> > So doesn't the question then become "W
On Dec 16, 2007 4:24 AM, Toon Moene <[EMAIL PROTECTED]> wrote:
> Here are, in addition, the numbers for compiling and
> running HIRLAM with -ftree-loop-distribution (after applying your patch,
> obviously).
>
> In short, almost 1900 more loops are vectorized, but that's of course
>
Hi,
How SSA inlining and default defs for uninitialized variables are supposed to
interact? Suppose you have the following situation
BB0 ...
| \
(ab) |BB1 s_2 = f(s_1(D))
| /
BB2 s_3 = PHI
in a function that gets inlined into a loop. The liveness of s_1(D) in BB0
w
On Sun, Dec 16, 2007 at 06:54:29PM +0100, Eric Botcazou wrote:
> How SSA inlining and default defs for uninitialized variables are supposed to
> interact? Suppose you have the following situation
>
> BB0 ...
> | \
> (ab) |BB1 s_2 = f(s_1(D))
> | /
> BB2 s_3 = PHI
>
>
> This sounds like PR31081.
Indeed, the C++ testcase is the exact translation of my Ada testcase. :-)
The problem seems to arise relatively often in Ada, I think the PR should be
made "critical".
--
Eric Botcazou
Toon Moene <[EMAIL PROTECTED]> writes:
> L.S.,
>
> Recently, I've begun to bootstrap with make BOOT_CFLAGS="flags",
> basically to get the run time libraries (libgfortran, libgomp)
> compiled with -mcpu=native -mtune=native (the speed of the compiler
> doesn't interest me that much).
>
> However,
On 12/16/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> On Dec 16, 2007, NightStrike <[EMAIL PROTECTED]> wrote:
>
> > On 12/15/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> >> ... a good example of compliance with the GPL:
> >>
> >> 5. Conveying Modified Source Versions.
> >>
> >> a) The work
Sebastian Pop wrote:
Wow! Thanks for the numbers. I guess from your message that there
were no ICEs or other problems with the loop distribution patch.
Exactly.
--
Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home:
On Sun, Dec 16, 2007 at 07:11:49PM +0100, Eric Botcazou wrote:
> > This sounds like PR31081.
>
> Indeed, the C++ testcase is the exact translation of my Ada testcase. :-)
>
> The problem seems to arise relatively often in Ada, I think the PR should be
> made "critical".
Yeah, to me this looks l
Please forgive me if this is off-topic:
I've written a simple test program with posix threads and a 'glibc'
attempt was detected.
The code:
-main.c---
#include
#include
#include
#include
#include
#include
#include
#include "stack.c"
/*
* THREAD EXPERIMENT
*
*
Dear GCC Developers/Users,
I am working on a port of a target backend to PISA architecture (a MIPS-IV like
ISA used by the SimpleScalar simulator). When compiling libgcc2 for __muldi3:
#ifdef L_muldi3
DWtype
__muldi3 (DWtype u, DWtype v)
{
const DWunion uu = {.ll = u};
const DWunion vv = {.l
Alexandre Oliva wrote:
>> Yes, please. I would very much like to see an abstract design
>> document on what you are trying to accomplish.
>
> Other than the ones I've already posted, here's one:
>
> http://dwarfstd.org/Dwarf3Std.php
>
> Seriously. There is a standard for this stuff.
That's
Why does it happen?
On Sun, Dec 16, 2007 at 07:20:37PM -0300, Lucas Prado Melo wrote:
> Why does it happen?
This list is for the development of GCC. Try gcc-help or some other
programming forum, please.
--
Daniel Jacobowitz
CodeSourcery
> It is obvious that you misunderstood what I want, and how intrusive
> the approach is.
>
Yes Alexandre, everyone who disagrees with you must not understand!
That's really the problem here.
None of us understand but you.
On Sun, Dec 16, 2007 at 08:12:07PM -0500, Daniel Berlin wrote:
> > It is obvious that you misunderstood what I want, and how intrusive
> > the approach is.
> >
>
> Yes Alexandre, everyone who disagrees with you must not understand!
> That's really the problem here.
> None of us understand but you.
On Dec 16, 2007, at 20:27, Joe Buck wrote:
I have some sympathy for going in Alexandre's direction, in that it
would be nice to have a mode that provided optimization as well as
accurate debugging. However, since preserving accurate debug
information
has a cost, I think it would be better to
30 matches
Mail list logo
