[early patch] Speed up decl chaining

[Rafael Espíndola]

I found this old incomplete patch while cleaning my git repo. I just
want to see if it is crazy or not before trying to finish it.

Currently decl chaining is O(n). We use a circular singly linked list
that points to the previous element and has a bool to say if we are
the first element (and actually point to the last).

Adding a new decl is O(n) because we have to find the first element by
walking the prev links. One way to make this O(1) that is sure to work
is a doubly linked list, but that would be very wasteful in memory.

What this patch does is reverse the list so that a decl points to the
next decl (or to the first if it is the last). With this chaining
becomes O(1). The flip side is that getPreviousDecl is now O(n).

In this patch I just got check-clang to work and replaced enough uses
of getPreviousDecl to get a speedup in

    #define M extern int a;
    #define M2 M M
    #define M4 M2 M2
    #define M8 M4 M4
    #define M16 M8 M8
    #define M32 M16 M16
    #define M64 M32 M32
    #define M128 M64 M64
    #define M256 M128 M128
    #define M512 M256 M256
    #define M1024 M512 M512
    #define M2048 M1024 M1024
    #define M4096 M2048 M2048
    #define M8192 M4096 M4096
    #define M16384 M8192 M8192
    M16384

In my machine this patch takes clang -cc1 on the pre processed version
of that from 0m4.748s to 0m1.525s.

There are still a lot of uses of getPreviousDecl to go, but can anyone
see a testecase where this strategy would not work?

Cheers,
Rafael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.patch
Type: application/octet-stream
Size: 17719 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131008/9c18586f/attachment.obj>