>
> When there are no symbols in the pointer's points-to set.
>
I am beginning to realize. But there is something it remains:
1) Once the ssa rename has been done, the alias analysis begins
(points-to sets). Each version of a base pointer has associated its
own points-to set? Like
if ()
t_1 =
Hi,
> Core2 follows a similar pattern, although it's not seeing any
> slowdown in the "no deps, predictable, jmp" case like K8 does.
>
> Any comments? (please cc me) Should gcc be using conditional jumps
> more often eg. in the case of __builtin_expect())?
The problem is that in general GCC's bra
> Hi,
> > Core2 follows a similar pattern, although it's not seeing any
> > slowdown in the "no deps, predictable, jmp" case like K8 does.
> >
> > Any comments? (please cc me) Should gcc be using conditional jumps
> > more often eg. in the case of __builtin_expect())?
>
> The problem is that in g
> --- ORIG/trunk/gcc/config/sh/sh.h 2007-12-07 09:11:38.0 +0900
> +++ LOCAL/trunk/gcc/config/sh/sh.h2008-02-25 19:09:48.0 +0900
> @@ -553,7 +553,7 @@ do {
> \
> {
Hello,
I am running the attached testcase (inspired from vect/vect-reduc-3.c
testcase) with -O3 -fwrapv on powerpc64-linux with trunk 4.4.
Here is a snippet from the testcase:
...
unsigned short ub[N] = {0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45};
unsigned short uc[N] = {0,1,2,3,4,5,6,7,
On Mon, 25 Feb 2008, Richard Guenther wrote:
> On Mon, 25 Feb 2008, H.J. Lu wrote:
>
> > Uros failed with --enable-checking=release and I failed with
> > --enable-checking=assert.
> > You can try either one.
>
> That reproduces it. I have reverted the patch for now.
It turns out that PCH and g
On Tue, Feb 26, 2008 at 12:12 PM, Revital1 Eres <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> I am running the attached testcase (inspired from vect/vect-reduc-3.c
> testcase) with -O3 -fwrapv on powerpc64-linux with trunk 4.4.
>
> Here is a snippet from the testcase:
>
> ...
>
> unsigned short
On Tuesday 26 February 2008 21:14, Jan Hubicka wrote:
> Hi,
>
> > Core2 follows a similar pattern, although it's not seeing any
> > slowdown in the "no deps, predictable, jmp" case like K8 does.
> >
> > Any comments? (please cc me) Should gcc be using conditional jumps
> > more often eg. in the cas
On Tue, Feb 26, 2008 at 04:44, Fran Baena <[EMAIL PROTECTED]> wrote:
> if ()
> t_1 = & a_1;t_1 points-to { a_1 }
> else
> if ()
> t2_ = & b_1; t_2 points-to { b_1 }
> else
> t_3 = & c_1; t_3 points-to { c_1 }
>
> # t_4 = PHI
> p_1 = t_4; p_1 and t_
Compiling and executing the code of Nick Piggin at
http://gcc.gnu.org/ml/gcc/2008-02/msg00601.html
in my old Athlon64 Venice 3200+ 2.0 GHz,
3 GiB DDR400, 32-bit kernel, gcc 3.4.6, i got
$ gcc -O3 -falign-functions=64 -falign-loops=64 -falign-jumps=64
-falign-labels=64 -march=i686 foo.c -o foo
$ .
Since the branch still does not bootstrap cleanly, we have to jump
through some hoops to do testing. I've added configuration and build
instructions to the tuples wiki (http://gcc.gnu.org/wiki/tuples).
Diego.
On 2008/2/26, J.C. Pizarro <[EMAIL PROTECTED]>, i wrote:
> 4. C > cmov >> jmp when it's unpredictable and has not data dependencies.
I'm sorry of my error typo, the correct is (without the "not")
4. C > cmov >> jmp when it's unpredictable and has data dependencies.
and my forgotten 3rd annotatio
It's a final summary for good performance of the tested machines:
+ unpredictable: * don't use conditional jmp (the worst).
/ * use cmov or C version.
/
\ + no deps: * use cmov or C version.
\ /
+ predictable: \
+ has deps: * do
On Tuesday 26 February 2008 21:14, Jan Hubicka wrote:
> Only cases we do so quite reliably IMO are:
> 1) loop branches that are not interesting for cmov conversion
> 2) branches leading to noreturn calls, also not interesting
> 3) builtin_expect mentioned.
> 4) when profile feedback is arou
This is also interesting for the ARC700 processor.
There is also an issue if the flag for the conditionalized instruction is
set in the immediately preceding instruction, and the result of the
conditionalized instruction is required in the immediately following
instruction, and if using a conditio
I just spent a couple of hours looking into what turned out to be an
issue with decl_constant_value_for_broken_optimization, and I wanted
to record the notes.
The function was introduced here:
http://gcc.gnu.org/ml/gcc-patches/2000-10/msg00649.html
At the time Joseph added this comment:
/*
Here is a draft FDPIC ABI for SH uClinux, based on the FR-V FDPIC ABI.
Please send any comments; CodeSourcery will be implementing the final ABI
version in GCC and Binutils.
The SH FDPIC ABI
Joseph Myers
CodeSo
On Tue, Feb 26, 2008 at 08:02:27PM -0800, Joe Perches wrote:
> Converting inline __attribute__((format (printf,x,y) functions
> to macros or statement expressions produces smaller objects
>
> before:
> $ size vmlinux
>textdata bss dec hex filename
> 4716770 474560 618496 5809
On Tue, 2008-02-26 at 21:13 -0700, Matthew Wilcox wrote:
> That's very interesting. It's only 64 bytes, but still, it's not
> supposed to have any different effect.
Especially because __simple_attr_check_format is not even used
or called in an x86 defconfig. It's powerpc/cell specific.
> Could
On Tue, 26 Feb 2008, Matthew Wilcox wrote:
> On Tue, Feb 26, 2008 at 08:02:27PM -0800, Joe Perches wrote:
> > Converting inline __attribute__((format (printf,x,y) functions
> > to macros or statement expressions produces smaller objects
> >
> > before:
> > $ size vmlinux
> >textdata b
On Tue, 2008-02-26 at 21:44 -0800, David Rientjes wrote:
> I'm not seeing any change in text size with allyesconfig after applying
> this patch with latest git:
This is just x86 defconfig
> Joe, what version of gcc are you using?
$ gcc --version
gcc (GCC) 4.2.2 20071128 (prerelease) (4.2.2-3.1m
On Tue, 26 Feb 2008, Joe Perches wrote:
> > I'm not seeing any change in text size with allyesconfig after applying
> > this patch with latest git:
>
> This is just x86 defconfig
>
allyesconfig should be able to capture any text savings that this patch
offers.
> > Joe, what version of gcc ar
22 matches
Mail list logo
