Zdenek Dvorak wrote:
Hello,
you might try turning the references to TARGET_MEM_REFs, and copy the
alias information using copy_ref_info to it. I am not sure how that
would interact with the transformations you want to do, but we do lot
of magic to keep the virtual operands for TARGET_MEM_REFs
On 2/20/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
So, my feeling is that the best course of action is to set a relatively
low threshold for GCC 4.2.0 and target 4.2.0 RC1 soon: say, March 10th.
Then, we'll have a 4.2.0 release by (worst case, and allowing for
lameness on my part) March 3
Richard Guenther napisał(a):
On 2/20/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
So, my feeling is that the best course of action is to set a relatively
low threshold for GCC 4.2.0 and target 4.2.0 RC1 soon: say, March 10th.
Then, we'll have a 4.2.0 release by (worst case, and allowing fo
Hello,
> >>>you might try turning the references to TARGET_MEM_REFs, and copy the
> >>>alias information using copy_ref_info to it. I am not sure how that
> >>>would interact with the transformations you want to do, but we do lot
> >>>of magic to keep the virtual operands for TARGET_MEM_REFs the
Zdenek Dvorak wrote:
Hello,
you might try turning the references to TARGET_MEM_REFs, and copy the
alias information using copy_ref_info to it. I am not sure how that
would interact with the transformations you want to do, but we do lot
of magic to keep the virtual operands for TARGET_MEM_REFs
Hi,
I am working on GCC 3.3.1 port. The architecture mostly based
on RISC architecture.
Here is the problem.
After compiling following code
--
void g(char *a);
f(char c)
{
g(&c);
}
-
The in the generated RTL (file.c.00.rtl)
I see inc
Hello,
> >>In principle, I don't see anything forbidding Zdenek's idea.
> >>Unfortunately, what I avoided to mention is that TARGET_MEM_REF nodes
> >>are also transformed into pointer arithmetics
> >>and the equivalent
> >>INDIRECT_REF memory access... therefore, this is not an option even only
Hello,
We saw that the reassociation pass does not operate on built-in functions,
for example:
vp3 = vec_madd (vp1, vp2, vp3);
In the RTL level the function is expanded to regular insn:
(insn 87 91 88 9 (set (reg/v:V4SF 217 [ vp3 ])
(plus:V4SF (mult:V4SF (reg/v:V4SF 219 [ vp1 ])
Zdenek Dvorak wrote:
Hello,
In principle, I don't see anything forbidding Zdenek's idea.
Unfortunately, what I avoided to mention is that TARGET_MEM_REF nodes
are also transformed into pointer arithmetics
and the equivalent
INDIRECT_REF memory access... therefore, this is not an option even o
On Mon, 19 Feb 2007, Joe Buck wrote:
> On Tue, Feb 20, 2007 at 12:27:42AM +, Joseph S. Myers wrote:
> >... *All* releases seem to have the
> > predictions that they are useless, should be skipped because the next
> > release will be so much better in way X or Y, etc.; I think the question
> >
"sameer sinha" <[EMAIL PROTECTED]> writes:
> Please can any one tell me how to bulid gcc newer version for
> generating
> code for i960MC processor.
> is there any switch to generate coed for i960MC or i will
> have to build it first
> for target i960.
>
Ian Lance Taylor wrote:
Unfortunately support for the Intel i960 was dropped in gcc 4.0.
There is no way to generate i960 code with a recent gcc release.
which means that GNAT is also unavailable at this stage.
Hello,
> >this seems quite close to what TARGET_MEM_REFs are designed for. IMHO,
> >the best way would be to lower the memory references to TARGET_MEM_REFs
> >(*) just once, sometime quite late in the optimization pipeline (just after
> >loop optimizations, for example), so that high-level optimi
Mark Mitchell wrote:
I've spent some time today looking at GCC 4.2.
I've heard various comments about whether or not it's worth doing a 4.2
release at all. For example:
[Option 1] Instead of 4.2, we should backport some functionality from
4.2 to the 4.1 branch, and call that 4.2.
[Option 2]
On 2/20/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
As for proposal to revert the aliasing fixes on the 4.2, IMHO aliasing
bugs are pretty nasty it is hard to find a option to work around because
alias info is used in many optimizations.
All bugs we are talking about can be worked around b
Richard Guenther wrote:
On 2/20/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
As for proposal to revert the aliasing fixes on the 4.2, IMHO aliasing
bugs are pretty nasty it is hard to find a option to work around because
alias info is used in many optimizations.
All bugs we are talking a
On 2/20/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
Richard Guenther wrote:
> On 2/20/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
>
>> As for proposal to revert the aliasing fixes on the 4.2, IMHO aliasing
>> bugs are pretty nasty it is hard to find a option to work around because
>> ali
Steven Bosscher <[EMAIL PROTECTED]> writes:
> Hello,
>
...[snip]
> So I'm looking for help here: Who can help me find a test case to trigger
> a verify_flow_info ICE in GCC with the above patch applied? Can people
> try this patch on their favorite target, and see if they can trigger a
> test sui
On 2/20/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
>[Option 1] Instead of 4.2, we should backport some functionality from
>4.2 to the 4.1 branch, and call that 4.2.
>
>[Option 2] Instead of 4.2, we should skip 4.2, stabilize 4.3, and call
>that 4.2.
>
>[Option 3] Like (2), but create (the ne
Steven Bosscher wrote:
On 2/20/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
>[Option 1] Instead of 4.2, we should backport some functionality from
>4.2 to the 4.1 branch, and call that 4.2.
>
>[Option 2] Instead of 4.2, we should skip 4.2, stabilize 4.3, and call
>that 4.2.
>
>[Option 3] Li
In term of ports, yes I am agree. As the preformance even with last
Paolo's patches (some changes could be applied to the mainline too, so
it is not only about df), the branch compiler is still 8.7% slower for
SPECint2000 compilation on 2.66Ghz Core2 with --enable-check=release.
Just to str
Paolo Bonzini wrote:
In term of ports, yes I am agree. As the preformance even with last
Paolo's patches (some changes could be applied to the mainline too,
so it is not only about df), the branch compiler is still 8.7% slower
for SPECint2000 compilation on 2.66Ghz Core2 with
--enable-chec
>
>
> Hello,
>
> We saw that the reassociation pass does not operate on built-in functions,
> for example:
>
> vp3 = vec_madd (vp1, vp2, vp3);
One thing which could be done is expand the builtins into tree code
instead of keeping around a builtin function.
This might also help other cases too
As for proposal to revert the aliasing fixes on the 4.2, IMHO aliasing
bugs are pretty nasty it is hard to find a option to work around because
alias info is used in many optimizations.
All bugs we are talking about can be worked around by using
-fno-strict-aliasing.
FWIW, in Apple distribute
* How do we compare the costs of if-converted vectorized code to
it's scalar counterpart?
o It may be convenient to calculate scalar cost during if-conversion itself.
o It is possible that size of two sibling blocks (Block_A & Block_B)
does not match at the beginning of tree-ssa level if co
> FWIW, in Apple distributed GCC 4.0.x, strict-aliasing is disabled by
> default when -O? is used because it breaks too much existing
> code (not just Apple internal code).
Much more than in 3.x?
--
Eric Botcazou
On 2/20/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> FWIW, in Apple distributed GCC 4.0.x, strict-aliasing is disabled by
> default when -O? is used because it breaks too much existing
> code (not just Apple internal code).
Much more than in 3.x?
I do not have data to answer this appropriate
I am agree, benchmarking is evil. My favorite benchmark is gcc because
it is my tool and I work on it. Compilation of gcc from Spec2000 is
>12% slower with df including last Paolo's patches (which are a really
big improvement).
Interesting enough, 176.gcc has a pretty bad result for runti
> As a first step, to stay on conservative side, it makes sense
> consider the scalar cost of smaller block while calculating scalar cost.
> Note, smaller block may not exist.
I think that this should be considwered quite common.
We should base the weights of the costs of the two blocks on branch
Paolo Bonzini wrote:
I am agree, benchmarking is evil. My favorite benchmark is gcc
because it is my tool and I work on it. Compilation of gcc from
Spec2000 is >12% slower with df including last Paolo's patches
(which are a really big improvement).
Interesting enough, 176.gcc has a pre
Mark Mitchell wrote:
FP performance regressions of the recent GCC 4.2 (revision 120817)
compiler against September GCC 4.2 (revision 116799)
What does that translate to in terms of overall score?
Hi,
This is 4.7% drop of SPECfp_base2006 ratio (geomean of individual FP
ratios).
Here is the f
On 2/20/07, Grigory Zagorodnev <[EMAIL PROTECTED]> wrote:
Mark Mitchell wrote:
>> FP performance regressions of the recent GCC 4.2 (revision 120817)
>> compiler against September GCC 4.2 (revision 116799)
> What does that translate to in terms of overall score?
>
Hi,
This is 4.7% drop of SPECfp_b
"Kaveh R. GHAZI" <[EMAIL PROTECTED]> writes:
>
> And we don't want to arm our detractors with bad SPEC numbers. I can just
> imagine the FUD spreading... we've got to fix it or backout.
For me as a gcc user miscompilations are far worse than bad SPEC numbers.
I never run SPEC, but if my programs
On Tue, 20 Feb 2007, Andi Kleen wrote:
> "Kaveh R. GHAZI" <[EMAIL PROTECTED]> writes:
> >
> > And we don't want to arm our detractors with bad SPEC numbers. I can just
> > imagine the FUD spreading... we've got to fix it or backout.
>
> For me as a gcc user miscompilations are far worse than bad
Richard Guenther wrote:
>> This is 4.7% drop of SPECfp_base2006 ratio (geomean of individual FP
>> ratios).
Clearly, 4.7% is significant. Grigory, thanks for the measurements!
>> Here is the full set of changes in cpu2k6/fp performance of GCC 4.2
>> compiler between r116799 and r120817, measure
Paweł Sikora wrote:
> Current development line of PLD-Linux uses 4.2 too.
Thanks for that information.
> Mark, could you add the PR30052 to your 4.2-TODO ?
Did you mean personally? If so, I have no particular plans to work on
this PR. I'm afraid that my GCC time is pretty limited, and I'm try
On Tue, Feb 20, 2007 at 06:23:14PM -0500, Kaveh R. GHAZI wrote:
> No it doesn't need stating, at least not for me. :-) Sure nobody likes
> bugs/miscompilations, but all compilers have them. We evaluate how
> serious they are and whether a performance hit from a bug fix is worth it.
> My understan
On 2/19/07, Joe Buck <[EMAIL PROTECTED]> wrote:
On Tue, Feb 20, 2007 at 12:27:42AM +, Joseph S. Myers wrote:
>... *All* releases seem to have the
> predictions that they are useless, should be skipped because the next
> release will be so much better in way X or Y, etc.; I think the question
Andi Kleen <[EMAIL PROTECTED]> writes:
| "Kaveh R. GHAZI" <[EMAIL PROTECTED]> writes:
| >
| > And we don't want to arm our detractors with bad SPEC numbers. I can just
| > imagine the FUD spreading... we've got to fix it or backout.
|
| For me as a gcc user miscompilations are far worse than ba
The install.texi manual has the following bit of code for the title page:
--
@titlepage
@sp 10
@comment The title is printed in a large font.
@center @titlefont{Installing GCC}
--
However, thi
40 matches
Mail list logo
