> 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;
> > 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 *cl
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-optimiz
> 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
>
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?
> > 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 non
"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
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
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
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 a
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
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 mis
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
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 e
[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
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.
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)
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
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();
>
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
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 fro
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
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
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: [
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
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]))
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
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
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
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,
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.
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 a
[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,
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;
> > > >
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 nam
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
>
> > > > 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 ab
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%
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.
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.
[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 googl
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
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
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 th
> > 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
- 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 perf
> 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
> 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 leve
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
49 matches
Mail list logo
