Re: Incorrect bitfield aliasing with Tree SSA

[Eric Botcazou]

> Because it wouldn't be pruning it if the alias sets conflicted!

Well, just look at the first RTL dump for:

struct S { int i; };

int f (struct S *s, int *p)
{
  s->i = 0;
  *p = 1;
  return s->i;
}

and

package P is

  type S is record
i : Integer;
  end record;

  type SP is access all S;

  type IP is access all Integer;

  function f (s : SP; p : IP) return Integer;

end P;
package body P is

  function f (s : SP; p : IP) return Integer is
  begin
s.i := 0;
p.all := 1;
return s.i;
  end;

end P;

compiled at -O2 -gnatp -fno-tree-dominator-opts -fno-tree-store-ccp.


For the C testcase:

;; s->i = 0
(insn 7 6 0 t.c:5 (set (mem/s:SI (reg/v/f:DI 59 [ s ]) [3 .i+0 S4 
A32])
(const_int 0 [0x0])) -1 (nil))

;; *p = 1
(insn 8 7 0 t.c:6 (set (mem:SI (reg/v/f:DI 60 [ p ]) [3 S4 A32])
(const_int 1 [0x1])) -1 (nil))

;; return s->i
(insn 9 8 10 t.c:6 (set (reg:SI 62)
(mem/s:SI (reg/v/f:DI 59 [ s ]) [3 .i+0 S4 A32])) -1 (nil))

i.e. everything is accessed with the alias set of 'int'.


For the Ada testcase:

;; s->i = 0
(insn 7 6 0 p.adb:5 (set (mem/s/j:SI (reg/v/f:DI 59 [ s ]) [4 .i+0 
S4 A32])
(const_int 0 [0x0])) -1 (nil))

;; *p = 1
(insn 8 7 0 p.adb:6 (set (mem:SI (reg/v/f:DI 60 [ p ]) [2 S4 A32])
(const_int 1 [0x1])) -1 (nil))

;; return s->i
(insn 9 8 10 p.adb:6 (set (reg:SI 62)
(mem/s/j:SI (reg/v/f:DI 59 [ s ]) [4 .i+0 S4 A32])) -1 
(nil))

i.e. s->i is accessed with the alias set of 'S'.


Now put 'aliased' on the field

  type S is record
i : aliased Integer;
  end record;

and you get:

;; s->i = 0
(insn 7 6 0 p.adb:5 (set (mem/s:SI (reg/v/f:DI 59 [ s ]) [2 .i+0 S4 
A32])
(const_int 0 [0x0])) -1 (nil))

;; *p = 1
(insn 8 7 0 p.adb:6 (set (mem:SI (reg/v/f:DI 60 [ p ]) [2 S4 A32])
(const_int 1 [0x1])) -1 (nil))

;; return s->i
(insn 9 8 10 p.adb:6 (set (reg:SI 62)
(mem/s:SI (reg/v/f:DI 59 [ s ]) [2 .i+0 S4 A32])) -1 (nil))

like in C.  The discrepancy purely stems from DECL_NONADDRESSABLE_P.


> > I didn't invent it either, but everything is more or less documented.
>
> No, not really.

Yes, it is, that's how I've understood how this stuff works.

-- 
Eric Botcazou

Re: Incorrect bitfield aliasing with Tree SSA

[Eric Botcazou]

> > So if I have
> > struct foo {int x; float y; } bar;
> > int *pi;
> > float *pf;
> >
> > and mark X as "nonaddressable", I know that an assigment to *pi can't
> > affect bar.x.
>
> But if you add
>
> struct foo *foop = &bar.
>
> foop->x = 5.
>
> It can, even though we *claim* X is nonaddressable.

Which can what exactly?

-- 
Eric Botcazou

Re: Some thoughts about steerring commitee work

[Dorit Nuzman]

Tim Prince <[EMAIL PROTECTED]> wrote on 17/06/2007 04:15:56:

> [EMAIL PROTECTED] wrote:
> > On Sat, Jun 16, 2007 at 06:54:46PM +0300, Dorit Nuzman wrote:
> >>> There are quite a few known simple cases which vectorizer fails to
> >>> vectorize.
> >> by "known" you mean there are open missed-optimization PRs for them?
(if
> >>
> >
> > Yes, that is what I meant.
> >
> I'd be happy to file some PRs along this line, if there is interest.  C

yes, there is

> or C++, if there's more interest in that than in Fortran.  But, gfortran
> fails to vectorize more than 50% of the stuff I run into every day,
> including most everything which involves distinct sections of the same
> array or COMMON block.

I thought there was already a PR opened for this issue (probably by Toon),
but I can't find it :-(

thanks,
dorit

Re: Some thoughts about steerring commitee work

[Dorit Nuzman]

> H. J. Lu wrote:
>
> > Why don't we turn on vectorizer at -O3 or even -O2, depending on
> > ISA? I added -ftree-vectorize to BOOT_CFLAGS on x86-64. According to
> > -ftree-vectorizer-verbose=1, there are 82 loops vectorized in
> > gcc source. There are no regressions. There are not much changes
> > in bootstrap time as well as "make check" time.
>
> We have about two dozen cases of packages that break when
> -ftree-vectorize is used.  I'm sure there are several more as we tend to
> discourage such bug reports.
>

If you could take the time to find the reduced testcases and file PRs for
these, that would be most appreciated.

thanks,
dorit

> --
> dirtyepic salesman said this vacuum's guaranteed
>  gentoo org  it could suck an ancient virus from the sea
>   9B81 6C9F E791 83BB 3AB3  5B2D E625 A073 8379 37E8 (0x837937E8)
>

Re: I'm sorry, but this is unacceptable (union members and ctors)

[Martin Jambor]

On Sat, Jun 16, 2007 at 06:16:03PM -0700, michael.a wrote:
> 
> Any advice on compiling gcc? That is the chicken and egg problem. If I
> install a binary version of GCC, then use it to build and install a custom
> GCC (which I want to become the system wide GCC) ...then how is this
> commonly done? --of course I would like the non custom GCC to do any future
> rebuilds, so that is to say, I don't want the custom GCC installing over the
> initial "bootstrap" GCC (if this makes any sense at this point:)

I  believe that  what you  want to  do at  this stage  is use  the GCC
version that comes with your  distribution to compile and install your
custom  patched GCC  that you  configure with  some  unique "--prefix"
directory  (in your  home,  for  example) and  hack  the configure  or
Makefile files of  the project you want to compile with  it to use the
compiler in that directory.

The --disable-bootstrap  configure option may also be  handy until you
get the compiler right.

I   think  that   reading   through  http://gcc.gnu.org/install/   and
especially  http://gcc.gnu.org/install/configure.html may  save  you a
lot of questions and experiments, it certainly helped to set me up not
so long time ago.

HTH

Martin

Re: Incorrect bitfield aliasing with Tree SSA

[Richard Kenner]

> > struct foo {int x; float y; } bar;
> > int *pi;
> > float *pf;
> >
> > and mark X as "nonaddressable", I know that an assigment to *pi can't
> > affect bar.x.
> 
> But if you add
> 
> struct foo *foop = &bar.
> 
> foop->x = 5.
> 
> It can, even though we *claim* X is nonaddressable.

I don't follow.  It's still the case that

*pi = 10;

cannot change bar.x.  Making a pointer to the entire structure doesn't
change that.

> If you told me this is what you meant by "nonaddressable", i'd
> probably call you crazy.
> 
> It is most certainly addressable, because you can form the address of it.

I'd certainly have no problem replacing that name with a better one.
The Ada terminology is "aliased", but that seemed too obscure.  The name
doesn't refer to the machine-level concept of "address", but to the C
operator "&", which is normally called "address of".  DECL_NONADDRESSABLE_P
means you can't apply the C operator "&" to that field.

Re: Some thoughts about steerring commitee work

[Ira Rosen]

"Daniel Berlin" <[EMAIL PROTECTED]> wrote on 16/06/2007:

> On 6/16/07, Dorit Nuzman <[EMAIL PROTECTED]> wrote:
>
> > Do you have specific examples where SLP helps performance out of loops?
>
> hash calculations.
>
> For md5, you can get a 2x performance improvement by straight-line
> vectorizing it
> sha1 is about 2-2.5x
>
> (This assumes you do good pack/unpack placement using something like
> lazy code motion)
>
> See, for example, http://arctic.org/~dean/crypto/sha1.html
>
> (The page is out of date, the technique they explain where they are
> doing straight line computation of the hash in parallel, is exactly
> what SLP would provide out of loops)

I looked at the above page (and also at MD5 and SHA1 implementations). I
found only computations inside loops.
Could you please explain what exactly you refer to as SLP out of loops in
this benchmark?

Thanks,
Ira

Re: Some thoughts about steerring commitee work

[Paolo Bonzini]

Fortunately gcc 4.3 will have also faster compilation speed than 4.2 
even with the df infrastructure (which may be, and I hope, helps to 
improve the code finally).  That is because some work was done to speed 
up tree-SSA infrastructure (and Paolo Bonizini's frwprop) to improve the 
compilation speed.


Just something to point out: despite fwprop being often associated with 
me (in bug reports too ;-) it was the joint work of me and Steven 
Bosscher.  His name is at them top of the fwprop.c file for a reason, as 
his work, and SuSE/Novell's infrastructure, were invaluable.


Paolo

Re: I'm sorry, but this is unacceptable (union members and ctors)

[Ross Ridge]

Ross Ridge wrote:
>I completely disagree.  Standards should primarily standardize existing
>practice, not inventing new features.  New features should be created
>by people who actually want and will use the features, not by some
>disinterested committee.

Robert Dewar write:
>First of all, I think you mean uninterested and not disinterested,
>indeed the ideal is that all committee members *should* be disinterested,
>though this is not always the case.

Since it's essentially impossible to be impartial about a feature you
created, both senses of the word apply here.

>The history for C here does not apply to C++ in my opinion. Adding new
>features to a language like C++ is at this stage highly non-trivial in
>terms of getting a correct formal definition.

Most of GCC's long list of extensions to C are also implemented as
extensions to C++, so you've already lost this battle in GNU C++.
Trying to add new a new feature without an existing implementation only
makes it harder to get both a correct formal definition and something
that people will actually want to use.

Ross Ridge

Re: Some thoughts about steerring commitee work

[Ryan Hill]

Dorit Nuzman wrote:
>> H. J. Lu wrote:
>>
>>> Why don't we turn on vectorizer at -O3 or even -O2, depending on
>>> ISA? I added -ftree-vectorize to BOOT_CFLAGS on x86-64. According to
>>> -ftree-vectorizer-verbose=1, there are 82 loops vectorized in
>>> gcc source. There are no regressions. There are not much changes
>>> in bootstrap time as well as "make check" time.
>> We have about two dozen cases of packages that break when
>> -ftree-vectorize is used.  I'm sure there are several more as we tend to
>> discourage such bug reports.
>>
> If you could take the time to find the reduced testcases and file PRs for
> these, that would be most appreciated.

I believe the majority of them can be traced back to PR 25413.  For
example building zlib with -O2 -march=pentium4 -ftree-vectorize will
cause several apps that link to it (firefox, openoffice, poppler, etc.)
to segfault.  The vectorizer generates movdqa instructions with datarefs
that are not aligned on a 16 byte boundary.

Other than that, I went through the rest of our -ftree-vectorize bugs
this morning and found that many of them have been fixed in 4.2, so the
situation is much better than I originally thought.


-- 
dirtyepic salesman said this vacuum's guaranteed
 gentoo org  it could suck an ancient virus from the sea
  9B81 6C9F E791 83BB 3AB3  5B2D E625 A073 8379 37E8 (0x837937E8)

Re: init-regs pass initializes virtual-stack-vars?

[Uros Bizjak]

Rask Ingemann Lambertsen wrote:

On Sat, Jun 16, 2007 at 08:11:18PM +0200, Uros Bizjak wrote:
  

Hello!

There is something strange going on, it looks that initialization of 
virtual-stack-vars register in init-regs pass confuses greg. In 
154r.regclass we have this sequence:



   It should have disappeared in the vregs pass, like all (?) the other
virtual pseudo registers.
  


Filled as PR rtl-optimization/32374, probably a dataflow bug.

Uros.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[Robert Dewar]

Ross Ridge wrote:
t formal definition.


Most of GCC's long list of extensions to C are also implemented as
extensions to C++, so you've already lost this battle in GNU C++.


And many of them are ill-defined (and some would agree ill-considered).
Mistakes in the past are not a good reason for mistakes in the future.


Trying to add new a new feature without an existing implementation only
makes it harder to get both a correct formal definition and something
that people will actually want to use.


I think the best procedure is to discuss new features from a language
design point of view, and the committee is the best forum for that,
then implement them as *part* of the (typically fairly drawn out)
process of adding a new feature.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[Robert Dewar]

Ross Ridge wrote:


Since it's essentially impossible to be impartial about a feature you
created, both senses of the word apply here.


It's not only possible, but usual in many technical settings. There
is no reason (or excuse) for getting emotionally attached to language
design proposals. In my decades of work on language design committees,
I have often made language proposals, and then the ensuing technical
discussion shows they are a bad idea, and they get dropped, no problem,
and I have seen this happen with many other people.

If you can't operate objectively, you really don't belong being involved
in a language design discussion.

Re: GCC Status Report (2007-06-15)

[H. J. Lu]

On Sat, Jun 16, 2007 at 04:31:14PM -0700, Mark Mitchell wrote:
> H. J. Lu wrote:
> 
> > Who are those relevant maintainers? Since Intel BID patches only
> > affects DFP intrinsics, which is only supported on Linux/PPC,
> > Linux/ia32 and Linux/x86-64 while Linux/PPC uses DPD encoding, not
> > BID encoding, I assume the relevant maintainers are maintainers for
> > DFP, libgcc and x86 backend.
> 
> That sounds correct to me.
> 

Good. I have another question. Intel BID patch itself doesn't change
any sources in DFP nor libdecnummber. The only significant change is
to change Makefile in libgcc to use Intel BID library for DFP
intrinsics when BID encoding is selected.  Currently, DFP is only
supported on Linux/PPC, which uses DPD encoding, and Linux/x86, which
uses BID encoding. So Intel BID patch only affects Linux/x86 as
it changes libgcc/Makefile.in to use Intel BID library. Who has
the final say on this patch?


H.J.

Re: missed vectorization (was Some thoughts about steerring commitee work)

[Tim Prince]

[EMAIL PROTECTED] wrote:

Tim Prince <[EMAIL PROTECTED]> wrote on 17/06/2007 04:15:56:


[EMAIL PROTECTED] wrote:

On Sat, Jun 16, 2007 at 06:54:46PM +0300, Dorit Nuzman wrote:

There are quite a few known simple cases which vectorizer fails to
vectorize.

by "known" you mean there are open missed-optimization PRs for them?

(if

Yes, that is what I meant.


I'd be happy to file some PRs along this line, if there is interest.  C


yes, there is


or C++, if there's more interest in that than in Fortran.  But, gfortran
fails to vectorize more than 50% of the stuff I run into every day,
including most everything which involves distinct sections of the same
array or COMMON block.


I thought there was already a PR opened for this issue (probably by Toon),
but I can't find it :-(

thanks,
dorit

There are several issues.  EQUIVALENCE produces such a problem (PR32373) 
as do various kinds of references to multiple sections of the same array 
(PR32375,32376,32377,32378,32379,32380).  Only 2 of those PRs involve 
actual source/destination overlap, where the vectorizer would have to 
choose the correct direction (loop reversed or not).
In the bigger case (PR32380) there are loops which vectorize in 
isolation but not in the presence of other loops.


There are existing PRs on a somewhat similar issue involving type 
casting in C. IMHO, not vectorizing those might seem excusable.


Thanks,
Tim

Re: RFC: Make dllimport/dllexport imply default visibility

[Daniel Jacobowitz]

On Sat, Jun 16, 2007 at 10:13:34PM -0700, Chris Lattner wrote:
> Because there is no standard to reference, I think it's important to consider 
> these things in terms of explainability.

Chris said everything I could have said about this (better, too).  I
want to particularly highlight this part.  The minimum I'd want to
accept this code would be a complete and useful example in the manual;
since Mark and Danny say this happens a lot on Windows, I'm sure there
must be one.

-- 
Daniel Jacobowitz
CodeSourcery

Re: I'm sorry, but this is unacceptable (union members and ctors)

[michael.a]

Martin Jambor wrote:
> 
> On Sat, Jun 16, 2007 at 06:16:03PM -0700, michael.a wrote:
>> 
>> Any advice on compiling gcc? That is the chicken and egg problem. If I
>> install a binary version of GCC, then use it to build and install a
>> custom
>> GCC (which I want to become the system wide GCC) ...then how is this
>> commonly done? --of course I would like the non custom GCC to do any
>> future
>> rebuilds, so that is to say, I don't want the custom GCC installing over
>> the
>> initial "bootstrap" GCC (if this makes any sense at this point:)
> 
> I  believe that  what you  want to  do at  this stage  is use  the GCC
> version that comes with your  distribution to compile and install your
> custom  patched GCC  that you  configure with  some  unique "--prefix"
> directory  (in your  home,  for  example) and  hack  the configure  or
> Makefile files of  the project you want to compile with  it to use the
> compiler in that directory.
> 
> The --disable-bootstrap  configure option may also be  handy until you
> get the compiler right.
> 
> I   think  that   reading   through  http://gcc.gnu.org/install/   and
> especially  http://gcc.gnu.org/install/configure.html may  save  you a
> lot of questions and experiments, it certainly helped to set me up not
> so long time ago.
> 
> HTH
> 
> Martin
> 
> 

I appreciate the advice. I think what I decided should be done, is I should
hack in a command line option that can be used as a conditional, so that way
GCC can be compiled with all of its functionality, so that it can faithfully
recompile itself, and I can just add that option in the make routines.

I went to compile a "tainted" build last night, but I ran into a build error
apparently related only to subversion checkouts, which might also be
particular to the target debian distribution / hardware support for some
esoteric reason according to what can be gleamed from google. So I went to
just download the release sources, but all of the mirrors were down for some
reason. 

The error is related to a bison/flex build event, which for some reason
can't be completed by autotools or something... I figure it easier to just
go with the release sources as suggested (the relevant .c files are
pregenerated in the release trees)
-- 
View this message in context: 
http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11165121
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: RFC: Make dllimport/dllexport imply default visibility

[Ross Ridge]

Daniel Jacobowitz writes:
>The minimum I'd want to accept this code would be a complete and useful
>example in the manual; since Mark and Danny say this happens a lot
>on Windows

I don't understand how this issue can come up at all on Windows.  As far
I know, visibility is an ELF-only thing, while DLLs are a PE-COFF-only
thing.  Is there some platform that supports both sets of attributes?

Ross Ridge

Re: I'm sorry, but this is unacceptable (union members and ctors)

[michael.a]

Just for the record, this construction was proposed to me from behind the
scenes:

> class Rect
> {
>Rect()
>{
>   new (&xlat) Vec2(); // Explicit calls to the ctor
>   new (&size) Vec2();
>}
>~Rect()
>{
>   xlat.~Vec2();
>   size.~Vec2();
>}
> public:
>union
>{
>struct{ Vec2_ xlat, size; };
>struct{ T_ x,y,w,h; };
>};
> };
>

I think this would likely do the job in many cases with only a little extra
trickery, though I wouldn't be at all surprised if somewhere along the way
the compiler/specs might throw a wrench into the works. 

Nevertheless, it is an interesting expiriment I think, which might contain
further advantages. However, I feel strongly that either avenue of approach
should be open, so that a course of action may be freely chosen. 

I also can't help but consider this a fair ways to go simply to work around
what is I feel a temporary specifications anomale sure to be eventually
sorted out of the future of c++ .  

sincerely,

michael

PS: I really don't think is precisely what the proponents of "placement new"
have in mind, but feel free to rally around this proposal if you must
-michael
-- 
View this message in context: 
http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11165235
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[Aaron W. LaFramboise]

michael.a wrote:


So in closing, I'm interested in any ideas / advice, but compromising the
existing codebase is completely out of the question. You have my
appreciation in advance naturally...


I suspect the proper solution here is something from www.boost.org.  You 
didn't say exactly what you needed, but if its anything related to a 
common programming pattern, Boost has probably already implemented it in 
a portable or standard manner.  See 
.


In particular, see Boost optional, and aligned_storage in Boost typetraits.

Other people have already pointed it out, but I'll say it again: 
language extensions are almost always the wrong solution for these sorts 
of problems.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[michael.a]

Aaron W. LaFramboise-3 wrote:
> 
> michael.a wrote:
> 
>> So in closing, I'm interested in any ideas / advice, but compromising the
>> existing codebase is completely out of the question. You have my
>> appreciation in advance naturally...
> 
> I suspect the proper solution here is something from www.boost.org.  You 
> didn't say exactly what you needed, but if its anything related to a 
> common programming pattern, Boost has probably already implemented it in 
> a portable or standard manner.  See 
> .
> 
> In particular, see Boost optional, and aligned_storage in Boost
> typetraits.
> 
> Other people have already pointed it out, but I'll say it again: 
> language extensions are almost always the wrong solution for these sorts 
> of problems.
> 
> 

I appreciate the thought, but there is sort of an imperitive with this
effort to shy away from Boost/STL/virtual inheritance completely.
-- 
View this message in context: 
http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11165310
Sent from the gcc - Dev mailing list archive at Nabble.com.

More vectorizer testcases?

[Giovanni Bajo]

Hi Dorit,

some years ago I posted these testcases to Bugzilla's GCC:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18437
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18438
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18439

It looks like none of those are vectorized as of GCC 4.3. I read today that 
you're asking for more vectorizer testsuite so I was wondering:


1) Shall we add a GCC bugzilla component for the vectorizer? Currently the 
bugs are filed under "tree-optimization" which might be a little too generic, 
these days.


2) Do you need more testcases from geometric code like those above? Those 3 
above are pretty simple in fact, so I doubt more complex ones can be of help, 
but I can extract something more from my code if you want...

--
Giovanni Bajo

Activate -mrecip with -ffast-math?

[Giovanni Bajo]

Hello,

I was wondering if there are objects to automatically activating Uros' new 
-mrecip flag when -ffast-math is specified. It looks like a good match since 
-mrecip is exactly about fast non-precise mathematics.

--
Giovanni Bajo

Re: Activate -mrecip with -ffast-math?

[Uros Bizjak]

Hello!

I was wondering if there are objects to automatically activating Uros' 
new -mrecip flag when -ffast-math is specified. It looks like a good 
match since -mrecip is exactly about fast non-precise mathematics.


There is a discussion in gcc-patches@ mailing list about this topic, in 
"Re: [PATCH, middle-end, i386]: reciprocal rsqrt pass + full recip x86 
backend support" thread [1]. The main problem is, that one of the 
polyhedron tests segfaults with this patch (not the problem of the recip 
patch, but usage of questionable FP equivalence tests and FP indexes in 
the array).


Uros.

[1]: http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01146.html

Re: Help in understanding ccp propagator

[Revital1 Eres]

Hello,

I have one more question regarding the comment in
tree-ssa-ccp.c file -


  /* Note that for propagation purposes, we are only interested in
 visiting statements that load the exact same memory reference
 stored here.  Those statements will have the exact same list
 of virtual uses, so it is enough to set the output of this
 statement to be its first virtual definition.  */
  *output_p = first_vdef (stmt);

I wonder if this comment is true also if the vuses are not immediate as
in stmt no. 1 in the following example:

 1) arr[i].x = tmp1;
 ...
 2) arr[i].y = tmp2;
 ...
 3) reg1 = arr[i].x;
 ...
 4) arr[i].z = tmp2;
 ...
 5) reg2 = arr[i].x;

Is it because we are looking for the exact same memory reference (although
not immediate) it is enough to look at only first_vdef of every store we
encounter in our walk through the virtual def-use chain; or by looking
only at the first vdef we could miss vuses that could have been reached
by vdefs other than the first one?

Thanks again,
Revital

Re: Incorrect bitfield aliasing with Tree SSA

[Adam Nemet]

Eric Botcazou writes:
> For the Ada testcase:
> 
> ;; s->i = 0
> (insn 7 6 0 p.adb:5 (set (mem/s/j:SI (reg/v/f:DI 59 [ s ]) [4 .i+0 
> S4 A32])
> (const_int 0 [0x0])) -1 (nil))
> 
> ;; *p = 1
> (insn 8 7 0 p.adb:6 (set (mem:SI (reg/v/f:DI 60 [ p ]) [2 S4 A32])
> (const_int 1 [0x1])) -1 (nil))
> 
> ;; return s->i
> (insn 9 8 10 p.adb:6 (set (reg:SI 62)
> (mem/s/j:SI (reg/v/f:DI 59 [ s ]) [4 .i+0 S4 A32])) -1 
> (nil))
> 
> i.e. s->i is accessed with the alias set of 'S'.

Thanks, that helped.  I think you're right.  Obviously we don't have
this issue with bitfields in C.

I am trying now to prototype a new approach along the lines of
returning true in component_uses_parent_alias_set for SFT's with
DECL_NONADDRESSABLE_P.

Adam

Re: Activate -mrecip with -ffast-math?

[Giovanni Bajo]

On 17/06/2007 20.20, Uros Bizjak wrote:

I was wondering if there are objects to automatically activating Uros' 
new -mrecip flag when -ffast-math is specified. It looks like a good 
match since -mrecip is exactly about fast non-precise mathematics.


There is a discussion in gcc-patches@ mailing list about this topic, in 
"Re: [PATCH, middle-end, i386]: reciprocal rsqrt pass + full recip x86 
backend support" thread [1]. The main problem is, that one of the 
polyhedron tests segfaults with this patch (not the problem of the recip 
patch, but usage of questionable FP equivalence tests and FP indexes in 
the array).


My own humble 2c on this is that what Roger Sayle calls "the black & white 
approach" is what most users understand. I am no expert of floating point 
arithmetics standard; I do understand that by default GCC is very accurate to 
the standards, and that -ffast-math is the option for "less accuracy, more 
speed". Simple users have simple needs.


I reckon simple users like me want an option that means: "activate all options 
that speed up floating point calculations at the cost of accuracy". I believe 
that option is "-ffast-math" today. If that's the semantic of the option, then 
-mrecip should be added to it.


But if you dispute this, and you believe that the current semantic of 
"-ffast-math" is different (that is: there are track records of -ffast-math 
only including a selection of optimizations by some standards -- like -O2 
which doesn't mean "every optimization"), that's fine by me either. But 
please, give me a -ffaster-math or -fuber-fast-math that really means "turn on 
everything, thanks".


Either way, -ffast-math should be documented to explain its intended semantic, 
and not only how that semantic is currently implemented in GCC. This way, this 
discussion will not need to be reopened in the future.

--
Giovanni Bajo

Re: missed vectorization (was Some thoughts about steerring commitee work)

[Janne Blomqvist]

Tim Prince wrote:
There are several issues.  EQUIVALENCE produces such a problem (PR32373) 
as do various kinds of references to multiple sections of the same array 
(PR32375,32376,32377,32378,32379,32380).  Only 2 of those PRs involve 
actual source/destination overlap, where the vectorizer would have to 
choose the correct direction (loop reversed or not).
In the bigger case (PR32380) there are loops which vectorize in 
isolation but not in the presence of other loops.


Vectorization is tough work, and in the end if you succeed noone cares 
except for the crystallography weenies (and pipe stress freaks, if you 
catch my drift). ;-/


That being said, for the gfortran frontend there are a few things we can 
do to help the vectorizer:


1) Keep our data 16-byte aligned, this could help 32380?. For ALLOCATE 
we could use posix_memalign instead of malloc, if that is available. 
OTOH, AFAIK on x86-64 malloc returns 16-byte aligned so perhaps it's not 
worth bothering about. I'm not sure how to teach the middle-end about 
alignment, but I'm sure there is some way..


2) Annotate variables and procedure interfaces to help the optimizers. I 
think about the only thing we do ATM is declaring pure procedures (incl. 
intrinsics if I read the spaghetti correctly) with DECL_IS_PURE. See 
31094, 31593, 20165, 32131.


3) Better analysis of array syntax. Basically recognizing certain 
patterns and reorganizing the loops so that they can be vectorized. This 
is hard work with limited applicability, and perhaps it's not really 
needed, provided we do (2) well (allowing the middle-end to reorder 
loops if needed)?


--
Janne Blomqvist

Re: Incorrect bitfield aliasing with Tree SSA

[Daniel Berlin]

On 6/17/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:

> > So if I have
> > struct foo {int x; float y; } bar;
> > int *pi;
> > float *pf;
> >
> > and mark X as "nonaddressable", I know that an assigment to *pi can't
> > affect bar.x.
>
> But if you add
>
> struct foo *foop = &bar.
>
> foop->x = 5.
>
> It can, even though we *claim* X is nonaddressable.

Which can what exactly?


It can be addressed, as i've shown above.  foop is a pointer to &bar.x
in the above case.

You guys seem to be trying to get some sort of optimization through
hacking around with the alias set system, and then guessing at how all
the clients will actually use the information.

The reality is that a pointer to it's parent can legally access it, so
their alias sets should conflict.

You seem to only want it to not conflict "in certain cases", and
hacking around with alias sets is the wrong way to do this.

The right way to do this is to take the special cases into account
when you actually see them.

I'm completely unsurprised this is broken at the tree level given how
it is implemented
--Dan

Re: Fixing m68hc11 reorg after dataflow merge

[Kenneth Zadeck]

Rask Ingemann Lambertsen wrote:
> On Sat, Jun 16, 2007 at 11:36:00PM -0400, Kenneth Zadeck wrote:
>   
>>> Try:
>>>
>>> df_note_add_problem ();
>>> df_analyze ();
>>> -- 
>>> #pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
>>>   
>> What Seongbae said is correct. However, what Seongbae failed to say is
>> that you can ditch the code that gets rid of the old notes.  That will
>> be done by the note problem.
>> 
>
>Yes, look at what I posted yesterday already and smile.
> http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01147.html>
>
>   
I thought of one more thing over night: after the call to df_analyze,
you need to add a call to "df_remove_problem (df_note);"  Otherwise, the
next call to df_analyze will also rebuild the notes.  The other
possibility is to call "df_finish_pass ()" which will have the same effect.

Sorry for not thinking about this sooner.

kenny

Suffix for __float128 FP constants

[Uros Bizjak]

Hello!

I was trying to load a full 128 bit constant into __float128 variable, 
but with "L" suffix, I was able to load only XFmode constant. Is there a 
special suffix for __float128 available in gcc?


Uros.

Re: Incorrect bitfield aliasing with Tree SSA

[Laurent GUERBY]

On Sun, 2007-06-17 at 15:31 -0400, Daniel Berlin wrote:
> On 6/17/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> > > > So if I have
> > > > struct foo {int x; float y; } bar;
> > > > int *pi;
> > > > float *pf;
> > > >
> > > > and mark X as "nonaddressable", I know that an assigment to *pi can't
> > > > affect bar.x.
> > >
> > > But if you add
> > >
> > > struct foo *foop = &bar.
> > >
> > > foop->x = 5.
> > >
> > > It can, even though we *claim* X is nonaddressable.
> >
> > Which can what exactly?
> 
> It can be addressed, as i've shown above.  foop is a pointer to &bar.x
> in the above case.
> 
> You guys seem to be trying to get some sort of optimization through
> hacking around with the alias set system, and then guessing at how all
> the clients will actually use the information.
> 
> The reality is that a pointer to it's parent can legally access it, so
> their alias sets should conflict.

In Ada if you have a struct type, components of the struct
that do not have the explicit keyword "aliased" cannot
have their adress taken. Example:

type T1 is record
   J : Integer;
end record;

X1 : T1;

=> then X1.J "address" cannot be taken in legal Ada, so no integer
pointer can ever point to it.

type T2 is record
   J : aliased Integer;
end record;

X2 : T2;

=> then X2.J "address" can be taken and integer pointers can point to
it.

I don't think other language have such fine grained control
of adressability attached to the type.

I'm not understanding much of the discussion, just pointing
this language difference out in hope it helps.

Laurent

Re: missed vectorization (was Some thoughts about steerring commitee work)

[Tim Prince]

[EMAIL PROTECTED] wrote:

Tim Prince wrote:
There are several issues.  EQUIVALENCE produces such a problem 
(PR32373) as do various kinds of references to multiple sections of 
the same array (PR32375,32376,32377,32378,32379,32380).  Only 2 of 
those PRs involve actual source/destination overlap, where the 
vectorizer would have to choose the correct direction (loop reversed 
or not).
In the bigger case (PR32380) there are loops which vectorize in 
isolation but not in the presence of other loops.


Vectorization is tough work, and in the end if you succeed noone cares 
except for the crystallography weenies (and pipe stress freaks, if you 
catch my drift). ;-/


That being said, for the gfortran frontend there are a few things we can 
do to help the vectorizer:


1) Keep our data 16-byte aligned, this could help 32380?. 
In the actual application 32380 is derived from, the initial index is 1 
(16-byte aligned) 99% of the time.  Some of those loops do vectorize 
with gfortran when taken in isolation.  As all the arrays are set the 
same addresses, modulo 32 bytes, any required alignment adjustments for 
the rare cases are the same for all.
Recent public statements indicated that applications like these account 
for >25% of the "server" business of the largest vendors (more than that 
for their competitors), and this fraction is growing.  While this may 
not fit those who use gcc compilers, once the effort has been made to 
support vectorization, it may be of interest to see whether the 
boundaries could be extended.

Re: Incorrect bitfield aliasing with Tree SSA

[Daniel Berlin]

On 6/17/07, Laurent GUERBY <[EMAIL PROTECTED]> wrote:

On Sun, 2007-06-17 at 15:31 -0400, Daniel Berlin wrote:
> On 6/17/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> > > > So if I have
> > > > struct foo {int x; float y; } bar;
> > > > int *pi;
> > > > float *pf;
> > > >
> > > > and mark X as "nonaddressable", I know that an assigment to *pi can't
> > > > affect bar.x.
> > >
> > > But if you add
> > >
> > > struct foo *foop = &bar.
> > >
> > > foop->x = 5.
> > >
> > > It can, even though we *claim* X is nonaddressable.
> >
> > Which can what exactly?
>
> It can be addressed, as i've shown above.  foop is a pointer to &bar.x
> in the above case.
>
> You guys seem to be trying to get some sort of optimization through
> hacking around with the alias set system, and then guessing at how all
> the clients will actually use the information.
>
> The reality is that a pointer to it's parent can legally access it, so
> their alias sets should conflict.

In Ada if you have a struct type, components of the struct
that do not have the explicit keyword "aliased" cannot
have their adress taken. Example:

type T1 is record
   J : Integer;
end record;

X1 : T1;

=> then X1.J "address" cannot be taken in legal Ada, so no integer
pointer can ever point to it.


However, can a pointer to X1, stored into, affect J?

If so, field J's alias set must be marked as a subset of X1's alias
set, or we will get the info wrong.  We currently do *not* mark field
J's alias set as a subset of X1's, because J is DECL_NONADDRESSABLE_P.

(This is in fact, the problem we are hitting here in C.  We do *not*
record  the alias as a subset, which in effect, claims a pointer to
the structure can never touch the field, which is wrong.
The correct place for such optimization is to do it per-memory
reference, not to screw up the type based info)

Re: Suffix for __float128 FP constants

[Joseph S. Myers]

On Sun, 17 Jun 2007, Uros Bizjak wrote:

> I was trying to load a full 128 bit constant into __float128 variable, but
> with "L" suffix, I was able to load only XFmode constant. Is there a special
> suffix for __float128 available in gcc?

No; since the x86-64 ABI is what defines the __float128 name, you could 
ask the associated mailing list about a standard suffix to associate with 
it.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: Incorrect bitfield aliasing with Tree SSA

[Laurent GUERBY]

On Sun, 2007-06-17 at 17:02 -0400, Daniel Berlin wrote:
> On 6/17/07, Laurent GUERBY <[EMAIL PROTECTED]> wrote:
> > In Ada if you have a struct type, components of the struct
> > that do not have the explicit keyword "aliased" cannot
> > have their adress taken. Example:
> >
> > type T1 is record
> >J : Integer;
> > end record;
> >
> > X1 : T1;
> >
> > => then X1.J "address" cannot be taken in legal Ada, so no integer
> > pointer can ever point to it.
> 
> However, can a pointer to X1, stored into, affect J?

In the particular case above there cannot be a pointer to X1 in the
program. But if you have:

X1 : aliased T1;

Then yes a pointer P1 to X1 can exist, and then P1.all.J is legal.

There are some record types which are automatically aliased, for
example object oriented stuff ("tagged" types in Ada) but most simple
records are non aliased in Ada "normal" code that's why it could
pessimize code to assume all components are aliased.

If aliased variable/aliased type Y1 has a T1 component then of course
you can modify J through a pointer to the container.

> If so, field J's alias set must be marked as a subset of X1's alias
> set, or we will get the info wrong.  We currently do *not* mark field
> J's alias set as a subset of X1's, because J is DECL_NONADDRESSABLE_P.
> 
> (This is in fact, the problem we are hitting here in C.  We do *not*
> record  the alias as a subset, which in effect, claims a pointer to
> the structure can never touch the field, which is wrong.
> The correct place for such optimization is to do it per-memory
> reference, not to screw up the type based info)

I can't comment here :).

Laurent

Re: Incorrect bitfield aliasing with Tree SSA

[Richard Kenner]

> > > > So if I have
> > > > struct foo {int x; float y; } bar;
> > >
> > > But if you add
> > >
> > > struct foo *foop = &bar.
> > >
> > > foop->x = 5.
> > >
> > > It can, even though we *claim* X is nonaddressable.
> >
> > Which can what exactly?
> 
> It can be addressed, as i've shown above.  foop is a pointer to &bar.x
> in the above case.

No, it's a pointer to bar.  It contains the same *value* as a pointer to
bar.x would, but is of the wrong type.

bar.x is "nonaddresable" in the sense that any pointer that refers to memory
contained in it can't be of the type of the field (int) and hence can't
be of its alias set, but must be of the type of bar (struct foo) and hence
of *that* alias set.

> The reality is that a pointer to it's parent can legally access it, so
> their alias sets should conflict.

Which alias sets?  How can a pointer to int conflict with a pointer to bar
if X is nonaddressable?

> You guys seem to be trying to get some sort of optimization through
> hacking around with the alias set system, and then guessing at how all
> the clients will actually use the information.

Not at all.  This is completely consistent.  No hacking or lying to the
type system involved!

Re: I'm sorry, but this is unacceptable (union members and ctors)

[michael.a]

I'm sorry, but can anyone get through to any of these mirrors ever:

http://gcc.gnu.org/mirrors.html

Can someone recommend an alternative means of obtaining GCC source releases?

I can't find a GCC source package in debian repositories.
-- 
View this message in context: 
http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11168832
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[Ismail Dönmez]

On Monday 18 June 2007 04:23:35 michael.a wrote:
> I'm sorry, but can anyone get through to any of these mirrors ever:
>
> http://gcc.gnu.org/mirrors.html

The first mirror there, ftp://gd.tuwien.ac.at/gnu/gcc/ works fine. But next 
time please use gcc-help mailing list for such questions. Thanks.

/ismail

-- 
Perfect is the enemy of good

RE: RFC: Make dllimport/dllexport imply default visibility

[Dave Korn]

On 17 June 2007 18:17, Ross Ridge wrote:

> Daniel Jacobowitz writes:
>> The minimum I'd want to accept this code would be a complete and useful
>> example in the manual; since Mark and Danny say this happens a lot
>> on Windows
> 
> I don't understand how this issue can come up at all on Windows.  As far
> I know, visibility is an ELF-only thing, while DLLs are a PE-COFF-only
> thing.  Is there some platform that supports both sets of attributes?

  I'm fairly sure it's a non-issue for windows.  I think that
dllimport/dllexport are implemented on more than just windows but I'm not
sure.  What they mean on any other platform is anyone's guess, but one thing's
for sure: visibility attributes apply to ELF symbols and not anything else at
all.  


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: I'm sorry, but this is unacceptable (union members and ctors)

[Tim Prince]

[EMAIL PROTECTED] wrote:


http://gcc.gnu.org/mirrors.html

Can someone recommend an alternative means of obtaining GCC source releases?

I can't find a GCC source package in debian repositories.

EDIT: I should've said the subversion repository is likely unworkible for my
setup according to google (I posted this previously)
Then use s release or snapshot tarball from mirrors of 
ftp://gcc.gnu.org/pub/gcc/, and/or get better software, and use gcc-help 
as intended.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[michael.a]

Tim Prince-4 wrote:
> 
> Then use s release or snapshot tarball from mirrors of 
> ftp://gcc.gnu.org/pub/gcc/, and/or get better software, and use gcc-help 
> as intended.
> 

Yes, I apologize, that link and virtually all of the mirrors were timing out
all last night (well for a couple hours at least) 

And starting from the bottom of the mirrors (US mirrors) ...I tried about 6
before I assumed the situation had not changed.

I was simply interested in traffic patterns... Mailing list etiquette I'm
afraid is not my strongest suit.


-- 
View this message in context: 
http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11169013
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: Incorrect bitfield aliasing with Tree SSA

[Daniel Berlin]

On 6/17/07, Richard Kenner <[EMAIL PROTECTED]> wrote:

> > > > So if I have
> > > > struct foo {int x; float y; } bar;
> > >
> > > But if you add
> > >
> > > struct foo *foop = &bar.
> > >
> > > foop->x = 5.
> > >
> > > It can, even though we *claim* X is nonaddressable.
> >
> > Which can what exactly?
>
> It can be addressed, as i've shown above.  foop is a pointer to &bar.x
> in the above case.

No, it's a pointer to bar.  It contains the same *value* as a pointer to




bar.x is "nonaddresable" in the sense that any pointer that refers to memory
contained in it can't be of the type of the field (int) and hence can't
be of its alias set, but must be of the type of bar (struct foo) and hence
of *that* alias set.

> The reality is that a pointer to it's parent can legally access it, so
> their alias sets should conflict.

Which alias sets?  How can a pointer to int conflict with a pointer to bar
if X is nonaddressable?

That is not the example case we have given where this breaks.
The case where it breaks is exactly the case i have shown you.

We have a pointer to a structure, and because you have not recorded
the type's alias relationships properly, we claim derferences that are
offsetted from the structure can not access the field.
This is a direct consequence of trying to use the parent's alias set
for that of the child type, instead of creating a new alias set.

Re: RFC: Make dllimport/dllexport imply default visibility

[Chris Lattner]

On Jun 17, 2007, at 6:40 PM, Dave Korn wrote:


On 17 June 2007 18:17, Ross Ridge wrote:


Daniel Jacobowitz writes:
The minimum I'd want to accept this code would be a complete and  
useful

example in the manual; since Mark and Danny say this happens a lot
on Windows


I don't understand how this issue can come up at all on Windows.   
As far
I know, visibility is an ELF-only thing, while DLLs are a PE-COFF- 
only

thing.  Is there some platform that supports both sets of attributes?


  I'm fairly sure it's a non-issue for windows.  I think that
dllimport/dllexport are implemented on more than just windows but  
I'm not
sure.  What they mean on any other platform is anyone's guess, but  
one thing's
for sure: visibility attributes apply to ELF symbols and not  
anything else at

all.


They also apply to macho symbols on darwin.

-Chris

Re: Incorrect bitfield aliasing with Tree SSA

[Richard Kenner]

> > type T1 is record
> >J : Integer;
> > end record;
> >
> > X1 : T1;
> >
> > => then X1.J "address" cannot be taken in legal Ada, so no integer
> > pointer can ever point to it.
> 
> However, can a pointer to X1, stored into, affect J?

Of course.

> If so, field J's alias set must be marked as a subset of X1's alias
> set, or we will get the info wrong.  

"field J" doesn't *have* an alias set (only references do) and any
reference to field J will have the alias set of T1 (see get_alias_set).
So they conflict.

If you insist on asking "what is the alias set of field J", you get it by
DECL_NONADDRESSABLE_P (decl_of_j)
? TYPE_ALIAS_SET (DECL_CONTEXT (decl_of_j))
: TYPE_ALIAS_SET (TREE_TYPE (decl_of_j))

Re: machine learning for loop unrolling

[Ken Raeburn]

  - compile with the loop unrolled 1x, 2x, 4x, 8x, 16x, 32x and
measure the time the benchmark takes


The optimal unrolling factor may not be a power of two, depending on  
icache size (11 times the loop body size?), iteration count (13*n for  
some unknown n?), and whether there are actions performed inside the  
loop once or twice every N passes (for N not a power of two).


The powers of two would probably hit a lot of the common cases, but  
you might want to throw in some intermediate values too, if it's too  
costly to check all practical values.


Ken

Re: Incorrect bitfield aliasing with Tree SSA

[Eric Botcazou]

> I am trying now to prototype a new approach along the lines of
> returning true in component_uses_parent_alias_set for SFT's with
> DECL_NONADDRESSABLE_P.

Yes, the key problem is indeed SFTs, which is why we disable structure 
aliasing in the Ada compiler.

-- 
Eric Botcazou

Re: Incorrect bitfield aliasing with Tree SSA

[Eric Botcazou]

> I'm completely unsurprised this is broken at the tree level given how
> it is implemented

Nice tautology. :-)  You have resisted implementing anything at the tree level 
to fix the problem and now you're complaining there is a problem...

Let's try and devise something plausible at the tree level.  If we eventually 
fail, we could indeed consider disabling the optimization at the RTL level.

-- 
Eric Botcazou

Re: GCC Status Report (2007-06-15)

[Ben Elliston]

On Sat, 2007-06-16 at 06:17 -0700, H. J. Lu wrote:

> BTW, an x86 DFP configure bug was reported 3 months ago.  But it still
> hasn't benen fixed. I opened a DFP bug report:
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32351
> 
> with a patch. I hope it will be fixed before gcc 4.3 is released :-).

Sorry about the delay.  Yes, I assure you it will be fixed by then and
perhaps by the end of this week .. :-)

Cheers, Ben