LDD/STD Optimizations

Preston and I have been having an e-mail discussion about the use of
LDD and STD. He's brought up some good points, so with his permission
here's a summary. Everything is paraphrased.


Preston:
    Code replication can work. But if there's more than one array
    refernced in a loop we'll see exponential explosion (exponential
    in the number of things that must be aligned).


Pardo:
    But you can have code for the general case and code for the all-
    things-are-aligned cases and none of the rest:


        if (aligned(a) && aligned(b) && ..) {
            ... use ldd ...
        } else {
            ... don't use ldd ...
        }


    I believe most arrays will be double-aligned. `malloc' returns
    double-aligned memory and the compiler can be told to allocate
    stack arrays on double boundaries. If most arrays are aligned,
    then the ``everything is aligned'' code will be used most of the
    time.


Preston:
    Maybe I'm just overly used to FORTRAN, but I see a lot of code
    where unaligned array slices or odd-size columns get passed.


    Another issue is safety. To use LDD, unroll and jam. If there
    are any stores in the loop body you need to ensure the store in
    iteration I doesn't store to a location that might be one used in
    I+1.


    The two-versions trick is like procedure cloning. We're looking at
    it for sharper interprocedural information for constants, aliasing,
    and alignment.


Pardo:
    It might be worth doing a brief instrumentation study using an
    editor:


a[x] => (dump (1234, &a[0], &a[x], sizeof(&a[0])), a[x])






Preston:
    Using LDD/STD for save/restore at calls is easy. Other places are
    hard.


Pardo:
    True. In current codes, though, calls are substantial overhead.




Preston:
    What about `ldq/stq'? Are they worth puttig in the architecture?
    Maybe we can relax the LDD/STD alignment constraints.


Pardo:
    You have to repeat the analysis and see if it's valuable.


    My guess is that you'll find LDQ/STQ aren't so useful.


    The hardware people (includes me) will argue that relaxing the
    alignment constraints makes slower and/or more complicated
    implementations. Using LDD/STD only when you can guarantee
    static alignment will still lead to perf. improvements.


    Some (not me; I don't have the data to know) will argue that the
    alignment-required implementation is enough faster or sooner to
    market that the reduction in general utility is justified.




Preston:
    It's not that the problems are insurmountable; but they're all
    good reasons you don't generally see this code emitted today.




Thanks, Preston!
--

Return to the comp.compilers page.
Search the comp.compilers archives again.