[LLVMbugs] [Bug 20805] New: [EarlyCSE, Missed Opt] Don't need to advance generation number unless mayalias

[bugzilla-daemon at llvm.org]

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

            Bug ID: 20805
           Summary: [EarlyCSE, Missed Opt] Don't need to advance
                    generation number unless mayalias
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: listmail at philipreames.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 12955
  --> http://llvm.org/bugs/attachment.cgi?id=12955&action=edit
Failing test case for missed optimization 1

In EarlyCSE, we currently advance the generation number when we encounter a
store.  If the store we encounter does not alias any of the loads encountered
since the previous store (i.e. in the current generation), then we can continue
to forward their values across the store.  As a result, we can avoid advancing
the generation number in this case.  

I've attached a test case which illustrates a profitable case.  To actually
implement this, we'd probably want to bound the number of locations considered
when deciding to advance the generation number.  

Note that http://llvm.org/bugs/show_bug.cgi?id=20804 relies on similiar logic
to remove the store itself in some cases.  They may be worth implementing
together.


As a further optimization, we may be able to advance some of the loads from the
previous generation into the next, even if we do need to advance the generation
number.  Any load which is provably noalias with the store location should be
safe to add to the new generation.  

I haven't attached a test case for this one, but it should be easily to derive
from the previous one.

-- 
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/20140829/8fe959ad/attachment.html>