LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 8908 - call ModRefInfo not sensitive to ordering
Summary: call ModRefInfo not sensitive to ordering
Status: RESOLVED FIXED
Alias: None
Product: libraries
Classification: Unclassified
Component: Scalar Optimizations (show other bugs)
Version: trunk
Hardware: PC Linux
: P normal
Assignee: Nick Lewycky
URL:
Keywords:
Depends on:
Blocks: 8886
  Show dependency tree
 
Reported: 2011-01-05 00:39 PST by Nick Lewycky
Modified: 2011-11-14 16:49 PST (History)
5 users (show)

See Also:
Fixed By Commit(s):


Attachments
.ll testcase (run opt -basicaa -gvn) (652 bytes, application/octet-stream)
2011-01-05 00:39 PST, Nick Lewycky
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Lewycky 2011-01-05 00:39:38 PST
Created attachment 5960 [details]
.ll testcase (run opt -basicaa -gvn)

This is a breakout bug from bug 8886 comment 2. The problem is that we have in pseudo:

  %x = alloca
  store @CONSTANT, %x
  call @external1()
  %DEAD = load %x
  call @external2(%x)

and the load isn't being eliminated by GVN. MemDep does its backwards scan but when it asks BasicAA about the call to external1, BasicAA looks at the alloca's address leaking into external2 and bails returning ModRef.
Comment 1 Nick Lewycky 2011-01-16 19:58:52 PST
One way to fix this is to generalize llvm::PointerMayBeCaptured which already takes bool ReturnCaptures and bool StoreCaptures to take a generic "ignore this capture" functor. MemDep could then provide such a functor that ignores captures that happen too late using a DominatorTree for intra-block analysis.

The query would have to go through alias analysis and things like the getModRefInfo implementation in BasicAA would use it. This will require expanding the AA interface a little.

I'm not sure how folks feel about using a functor. One alternative is to return the list of all capturing instructions, though that list could get needlessly big on large functions where most instructions capture.
Comment 2 Nick Lewycky 2011-11-14 16:49:52 PST
Fixed in r144580.