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]

[PATCH 0/5] New implementation of SRA


Hi,

this  patch  set contains  my  new  implementation of  intraprocedural
Scalar Replacement of Aggregates (SRA)  that I would like to commit to
trunk first.  It is essentially a  part of the merge of the pretty-ipa
branch   because  a   (only  slightly   different)  variant   of  this
implementation   was  on  that   branch  for   a  number   of  months.
Nevertheless,  this patch  set  does not  contain the  interprocedural
variant, IPA-SRA  that I posted here  earlier.  I will send  that as a
followup patch later (hopefully once this is in).

Unlike  the  previous  SRA,  this  one is  not  based  on  decomposing
aggregate  types and references  but on  get_ref_base_and_extent() and
classifying accesses into aggregates on the basis of their offsets and
sizes.   It  only  creates  scalar  replacements and  only  for  those
components that are actually individually accessed in a function.  The
main advantages of this new implementation are that:

  - It is able to scalarize unions and aggregates that contain unions
    (PR 32964).  Moreover, there are potentially other scalarizable
    accesses caught by get_ref_base_and_extent() that are not by
    simple reference analysis, an example is an access to a
    one-element array that is not at the end of a structure.

  - It is simpler.  In fact, simplicity was the main objective of this
    new implementation.   On the  other hand, whenever  performance or
    bogus warning avoidance required  it (the two were usually tightly
    connected), necessary computations and data structures were added,
    even though some are not super simple.

    Still, with comments stripped off, the new implementation has 2246
    lines of code  whereas the old one has 3375.   I also believe it's
    easier to grasp how the new one works, though my view is obviously
    skewed.  Hopefully, it contains less bugs and makes those that are
    there easier to hunt down.   Avoiding all sorts of trickeries also
    makes reasoning of SRA's effects on the code easier.


Its behavior  on the  branch shows  that it does  not bring  about any
non-noise compile  time or run  time regressions.  My isolated  and so
far rather  sloppy benchmarks of  this particular version  suggest the
same thing.  Nevertheless, I am  about to test it thoroughly using one
of our  automated testers.   If there are  indeed no problems,  I will
propose that these patches are committed to trunk.

Because I belive  that the final version will be  very similar to this
one, I'd like to  invite others, especially middle-end maintainers, to
review it.

I have bootstrapped and tested the patches on x86_64-linux-gnu without
any problems.  I intend to do that  on i686 and I'd like to do that on
hppa-linux-gnu  too  but trunk  does  not  bootstrap  there as  it  is
(probably one of the post expand-from-SSA issues).  I'll keep trying.

Thank you very much in advance,

Martin


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