[LLVMbugs] [Bug 16536] New: Function should store Arguments contiguously not in an iplist

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=16536

            Bug ID: 16536
           Summary: Function should store Arguments contiguously not in an
                    iplist
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Core LLVM classes
          Assignee: unassignedbugs at nondot.org
          Reporter: nlewycky at google.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Functions are created separately from their Argument list, which is stored as a
linked list. The Argument list is inseparably tied to the type of the function,
which is an immutable property of the function when created. We aren't
benefiting from giving Argument lists efficient insertion you need to destroy
and recreate the whole Function regardless.

Instead, we should contiguously allocate the space for the arguments and
construct them when the function is created, and destroy them when the function
is destroyed.

Pros:
 - Efficient random access to the n-th Argument*.
 - One fewer allocation for the function and arguments.
 - Saves two pointers per Argument, since there's no more ilist_node<> for each
one.
 - Argument::getArgNo() could be reimplemented as O(1) using pointer
subtraction instead of the present O(n) list walk.

Cons:
 - No longer be efficient to swap two same-typed arguments.
 - No longer lazily create the argument list.
 - No longer support polymorphic Arguments (in case we do already).

This gives us the nice property that we could walk from a callsite parameter
operand number to a function's n-th argument in constant time.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130704/69a1866e/attachment.html>