lkml.org 
[lkml]   [2000]   [Nov]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH] removal of "static foo = 0"
    Michael Meissner wrote:
    >On Sat, Nov 25, 2000 at 11:55:11PM +0000, Tim Waugh wrote:
    >> On Sat, Nov 25, 2000 at 10:53:00PM +0000, James A Sutherland wrote:
    >>
    >> > Which is silly. The variable is explicitly defined to be zero
    >> > anyway, whether you put this in your code or not.
    >>
    >> Why doesn't the compiler just leave out explicit zeros from the
    >> 'initial data' segment then? Seems like it ought to be tought to..
    >
    >Because sometimes it matters. For example, in kernel mode (and certainly for
    >embedded programs that I'm more familiar with), the kernel does go through and
    >zero out the so called BSS segment, so that normally uninitialized static
    >variables will follow the rules as laid out under the C standards (both C89 and
    >C99). I can imagine however, that the code that is executed before the BSS
    >area is zeroed out needs to be extra careful in terms of statics that it
    >references, and those must be hand initialized.

    Since that code is already careful to hand initialize what
    it needs and explicitly zeroes the BSS, that sounds like an argument
    that it *is* safe to change gcc to move data that is intialized to
    all zeroes into bss, either as a compiler option or even not
    optionally.

    I am not a gcc hacker, but it looks to me like one could
    copy the code from output_constant and the functions that it
    calls (in gcc-2.95.2/gcc/gcc/varasm.c) to walk the tree to figure
    out if the data was all zeroes. I even started writing a routine
    for assemble_variable to call to try to test just for the integer case
    (basically just by cutting and pasting code). I include it here just
    to illustrate. Note: this code doesn't even type check properly when
    I try to compile it, so I know it's very wrong, but it's as good as
    posting pseudo code to explain my thinking).

    void
    clear_zero_initialization(tree decl)
    {
    tree exp = DECL_INITIAL(decl);
    enum tree_code code;

    if (exp == NULL)
    return;

    code = TREE_CODE (TREE_TYPE (exp));
    if (lang_expand_constant)
    exp = (*lang_expand_constant) (exp);

    while ((TREE_CODE (exp) == NOP_EXPR
    && (TREE_TYPE (exp) == TREE_TYPE (TREE_OPERAND (exp, 0))
    || AGGREGATE_TYPE_P (TREE_TYPE (exp))))
    || TREE_CODE (exp) == NON_LVALUE_EXPR)
    exp = TREE_OPERAND (exp, 0);

    if (code == INTEGER_TYPE && exp == const0_rtx)
    DECL_INITIAL(decl) = NULL;
    }


    At the moment, I have started daydreaming about instead
    writing an "elf squeezer" to do this and other space optimizations
    by modifying objdump. However, I do think that such an improvement
    to gcc would be at least a bit useful to the larger user base than
    just those people who use binutils-based systems.

    Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104
    adam@yggdrasil.com \ / San Jose, California 95129-1034
    +1 408 261-6630 | g g d r a s i l United States of America
    fax +1 408 261-6631 "Free Software For The Rest Of Us."
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 12:47    [W:0.025 / U:214.620 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site