This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Unrevied patches^3


http://gcc.gnu.org/ml/gcc-patches/2003-09/msg00657.html

    Support n32 & n64 structure return conventions.  This needs a new
    target hook, return_in_msb, to control the padding of the return
    value.

    Although the patch touches quite a bit of code, all the changes
    should be no-ops if return_in_msb returns false, which it does
    for everything except mips.

    I'd really like to get this in for 3.4 since it fixes the last
    known[*] incompatibility with the n32 & n64 calling conventions.
    We've already fixed a few other problems so, as it stands, 3.4
    would be incompatible with both 3.3 and the SGI tools.

       [*] famous last words...

http://gcc.gnu.org/ml/gcc-patches/2003-09/msg00841.html

    This patch makes two tweaks to reload:

       1. Take addressing modes into account when deciding whether
          to force constants into memory.

       2. Take more notice of SECONDARY_MEMORY_NEEEDED.

    At the moment, symbols seem to be needlessly forced into memory
    quite often in mips programs.


The rest are just ^1 rather than ^3 from me, although David pinged
the last two recently:

http://gcc.gnu.org/ml/gcc-patches/2003-10/msg00112.html

    Add new target hooks to control the representation of the high
    part of an address.  This allows the rtl optimisers to cope with
    target-specific representations, a bit like delegitimize_address
    does for full addresses.

http://gcc.gnu.org/ml/gcc-patches/2003-09/msg01268.html

    Part 1 of a two-part optimisation.  It splits out the code in
    check_ext_dependent_givs so that it can be reused by part 2 (below).
    It also fixes a loop misoptimisation on x86.

http://gcc.gnu.org/ml/gcc-patches/2003-09/msg01293.html

    Part 2: treat sign- and zero-extended variables as bivs if we know
    that the variable can't overflow the inner mode of the extension.

    There's a difficult (IMO) policy decision to be made wrt the
    handling of undefined overflow.  As I mentioned in the patch,
    if we have an increment such as:

       (set (reg:SI temp) (plus:SI (reg:SI i) (const_int 1)))
       (set (reg:SI i) (sign_extend:SI (subreg:HI (reg:SI temp) 1)))

    then we already allow "i" to be treated as a biv, but we still
    keep the extension.  So "i" itself will always be a 16-bit value
    but givs like "x[i]" can be strength-reduced.  The biv might
    wrap when the giv doesn't.

    It seems like there are three possibilities:

       1. Don't take advantage of overflow being undefined.
          Only treat a sign-extended variable as a biv if we
          know it can't overflow.

       2. What we do now: treat sign-extended variables as bivs
          but keep the extension.

       3. Treat sign-extended variables as bivs and remove the
          extension.  That way, we'll never have a situation
          where a biv can wrap but a giv derived from the biv
          does not wrap.

    Patches for (1) and (2) are included in the message above.
    However, (3) seems better than (2) to me, and gives better
    benchmark results in some cases.  (I can't publish them,
    unfortunately.)  I can send a patch for (3) if there's
    any interest.

    (Actually, the patch was originally written to do (3), but
    I didn't think it would be accepted.)

    Having said all that, maybe it's too late to apply this one for 3.4.
    I realise that patches submitted in stage2 can sometimes be applied
    in stage3, but this one is kind of invasive.  It can probably wait
    for 3.5.

    I'd like to apply part (1) though, since it does fix a bug.

Richard


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]