headers
J.C. Pizarro | 1 Jun 2007 02:43
Picon

Re: Very Fast: Directly Coded Lexical Analyzer

2007/5/31, J.C. Pizarro <jcpiza <at> gmail.com> wrote:
> To obtain 200-250% in speed gain won't be possible for this GCC
> optimizing compiler because of http://en.wikipedia.org/wiki/Amdahl%27s_law
>
> To understand the law's idea, to see first the red-A & blue-B graphic.
>
> GCC throws more time optimizing than analyzing lexically unless it
> deactivates the optimizing option -O.

I redacted a new "Speedup in a sequential program" in
http://en.wikipedia.org/wiki/Amdahl%27s_law with a numerical example
for more clarification of the idea of usefulness of the Amdahl's Law.

To see if you are understood better it than before, little stupid!

Sincerely :)
Permalink | Reply | 0 comments |
headers
Bernardo Innocenti | 1 Jun 2007 03:34
Favicon
Gravatar

Git repository with full GCC history

Hello,

I've set up a Git mirror of the entire GCC history on
server space kindly provided by David Woodhouse.

You can clone it with:

 git-clone git://git.infradead.org/gcc.git

The entire repo packs to 877MB.  If you can't afford that
much disk space, I suggest you get a shallow copy instead:

 git-clone --depth 100

This is just 43MB, very affordable if you consider
that the total size of the .svn dirs is 610MB!

One nice thing about the git GCC repo is its blazing
speed with common operations:

 - grep through all the history in less than 5 seconds:

   bernie <at> learn:~/src/gcc/gcc-git$ time git-log | grep ^commit | wc -l
   81193

   real    0m4.232s
   user    0m4.158s
   sys     0m0.381s

 - nop remote pull in 0.5 sec:
(Continue reading)

Permalink | Reply | 28 comments |
headers
Daniel Berlin | 1 Jun 2007 03:36

Re: Access to symbol table??

On 5/31/07, Seema S. Ravandale <ravandale <at> cse.iitb.ac.in> wrote:
> Hello sir,
>
> Thank you for help. you have already cleared my confusion.
>
> But I am working on inter-procedural data flow analysis. And i am trying
> to implement IPDFA on gimple-CFG IR.

If i were you, I would do it on the gimple-SSA IR, since gimple-CFG
isn't very useful to any optimization apsses.

> So at IR level all usages of global variable are replaced by some local
> variables of kind global.0, global.1 etc...
>
> But I am trying to visualize all of them as usages of global variable.
> In code sample below,let gl is global var.
>
> 1: c = gl+b;
> 2: array[0] = gl;
> 3: gl = 10;
>
> at line number 1,2 gl is used and at line number 3 it is defined.
>
> But in IR we will have...
>
> 1: gl.0 = gl;
> 2: c = gl.0 + b;
> 3: gl.1 = gl;
> 4: array[0] = gl.1
> 5: gl = 10;
(Continue reading)

Permalink | Reply | 501 comments |
headers
Harvey Harrison | 1 Jun 2007 05:37
Picon

Re: Git repository with full GCC history

Are you sure it packs to 877MB?  Oh, are you including a checked out
gcc source tree in that total?

In my gcc-svn clone of trunk:

~/dev/trunk$ du -s
873200

~/dev/trunk$ du .git -s
423064

This is a fully packed repo with default packing settings. (git gc)

Cheers,

Harvey Harrison
Permalink | Reply | 6 comments |
headers
Bernardo Innocenti | 1 Jun 2007 06:12
Favicon
Gravatar

Re: Git repository with full GCC history

Harvey Harrison wrote:

> Are you sure it packs to 877MB?  Oh, are you including a checked out
> gcc source tree in that total?

No, I only computed the .git size.

> ~/dev/trunk$ du .git -s
> 423064

I have a single, huge pack of 863M:

 -r--r--r-- 1 bernie bernie 863M May 31 21:42 pack-88472c7e9d0d8b80da5f7a815685d4347bee9546.pack

> This is a fully packed repo with default packing settings. (git gc)

I did it with "git-repack -a -d"... should have the same result.

How many commits do you have? 81193 here.

What version of git did you use? 1.5.0.6 here.

--

-- 
   // Bernardo Innocenti
 \X/  http://www.codewiz.org/
Permalink | Reply | 5 comments |
headers
Harvey Harrison | 1 Jun 2007 07:12
Picon

Re: Git repository with full GCC history

Whoops, trimmed CC:

On 5/31/07, Bernardo Innocenti <bernie <at> codewiz.org> wrote:
> Harvey Harrison wrote:
>
> > Are you sure it packs to 877MB?  Oh, are you including a checked out
> > gcc source tree in that total?
>
> No, I only computed the .git size.
>

OK, just seemed like my size with working tree was close to your reported size.

> > This is a fully packed repo with default packing settings. (git gc)
>
> I did it with "git-repack -a -d"... should have the same result.

Was this repo made with svnimport or git-svn? svnimport is faster but
chooses bad delta bases as a result.  git repack -a -d -f would allow
git to choose better deltas rather than reusing the deltas that
svnimport created.  (I think, I'm not a git expert).

>
> How many commits do you have? 81193 here.
>

git rev-list HEAD | wc
80419

Hmmm, mine is only a clone of trunk, but I am suprised by the blowup
(Continue reading)

Permalink | Reply | 4 comments |
headers
Bernardo Innocenti | 1 Jun 2007 08:52
Favicon
Gravatar

Re: Git repository with full GCC history

Harvey Harrison wrote:

> Was this repo made with svnimport or git-svn? svnimport is faster but
> chooses bad delta bases as a result.  git repack -a -d -f would allow
> git to choose better deltas rather than reusing the deltas that
> svnimport created.

I used:

 git-svn fetch
 git-fetch . remotes/git-svn

Yes, I did a "git-repack -a -d -f" too.  And I even did
one with --window=20, but nothing changed.

> (I think, I'm not a git expert).

Neither am I, but after all, who is?  (Linus, you don't count)

>> What version of git did you use? 1.5.0.6 here.
>
> 1.5.2

I shall try it...  That's probably it.

--

-- 
   // Bernardo Innocenti
 \X/  http://www.codewiz.org/
(Continue reading)

Permalink | Reply | 3 comments |
headers
Prasad, Kamal R | 1 Jun 2007 09:02
Picon
Favicon

Optimizations for itanium

Hello,

 Can someone tell me the back-end optimizations available for itanium
(IA64)?
We (HP) may be able to contribute to this from our side.

Thanks
-kamal
Permalink | Reply | 5 comments |
headers
Gabriel Paubert | 1 Jun 2007 09:26
Picon

[OT] Re: Git repository with full GCC history

On Fri, Jun 01, 2007 at 02:52:43AM -0400, Bernardo Innocenti wrote:
> Harvey Harrison wrote:
> 
> >Was this repo made with svnimport or git-svn? svnimport is faster but
> >chooses bad delta bases as a result.  git repack -a -d -f would allow
> >git to choose better deltas rather than reusing the deltas that
> >svnimport created.
> 
> I used:
> 
> git-svn fetch
> git-fetch . remotes/git-svn
> 
> 
> Yes, I did a "git-repack -a -d -f" too.  And I even did
> one with --window=20, but nothing changed.
> 
> 
> >(I think, I'm not a git expert).
> 
> Neither am I, but after all, who is?  (Linus, you don't count)
> 
> 
> >>What version of git did you use? 1.5.0.6 here.
> >
> >1.5.2
> 
> I shall try it...  That's probably it.
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Frank Schaefer | 1 Jun 2007 09:28
Picon

Re: Very Fast: Directly Coded Lexical Analyzer

> Like e.g. the generated code
>    IF match-char1 THEN ..
>    ELSIF match-char2 THEN ..
>    ELSIF match-char3 THEN ..
>    ..
>    END
> ?
Similar. It identifies ranges of character point sets and
brackets them via binary bracketting.

> Why to complicate the things? The determinist finite automaton (DFA)
> table-driven helps us to express efficiently this with regular
> expressions (RE).

Because the directly coded approach avoids overhead of housekeeping
for the lexer state. As  you might have realized, the RE in quex
follow the syntax of flex/lex. 

> Too, with the Ken Thompson & Kleene theories, it's not easy to be
> hand-written the implementation of an analyzer or analyzer generator.

The analyzer generator does, indeed, do the Thomson Construction and
repetition of state machines according to Kleene Closure with
epsilon transition. And it is done. If you have any critics about
the coverage of the unit tests in core_engine/state_machine/TEST, 
you are free to add some new. Let me know.

> It's possible to be unstable your quex analyzer generator while the
> lex/flex generator is stable.
(Continue reading)

Permalink | Reply | 574 comments |

Gmane