search for: pr28400

On Mon, Jul 11, 2016 at 7:51 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Hi Sean, > > Sean Silva wrote: > > While building test-suite with the new PM, I ran into problems with > > AssertingVH being triggered which is obvious in retrospect: > > https://llvm.org/bugs/show_bug.cgi?id=28400 > > > > Both cases I ran into revolve around LVI

> On Jan 23, 2017, at 10:07 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > > On Mon, Jan 23, 2017 at 1:08 AM, Chandler Carruth <chandlerc at gmail.com <mailto:chandlerc at gmail.com>> wrote: > This thread kinda died. I'd like to revive it. > > The new PM stuff is making excellent progress, and this is actually one of the last things to

On Mon, Jul 11, 2016 at 11:17 PM, Sanjoy Das <sanjoy at playingwithpointers.com > wrote: > Hi Sean, > > Sean Silva wrote: > > > > But asan won't catch problems (insofar I understand how it works) if > > the free'ed BasicBlock is used as a key in a DenseMap or something -- > > if another BasicBlock gets allocated to the same location

While building test-suite with the new PM, I ran into problems with AssertingVH being triggered which is obvious in retrospect: https://llvm.org/bugs/show_bug.cgi?id=28400 Both cases I ran into revolve around LVI which holds AssertingVH. Essentially, what happens is this: 1. LVI holds an AssertingVH pointing at a BasicBlock 2. Some other pass ends up deleting that BB (e.g. SimplifyCFG) 3. BOOM

This thread kinda died. I'd like to revive it. The new PM stuff is making excellent progress, and this is actually one of the last things to clean up. On Mon, Aug 8, 2016 at 1:10 AM Sean Silva <chisophugis at gmail.com> wrote: > Thoughts? For the moment I have put in a workaround (r274457) that makes > jump-threading invalidate LVI. > > > Is everybody happy with this

...M seems to account for quite a few of the problems. - BasicAA and other stuff are marked (by overriding `invalidate` to return false) to never be invalidated because they are "stateless". However they still hold pointers and so they do need to be invalidated. - CallGraph uses AssertingVH (PR28400) and so I needed a workaround similar to r274656 in various passes. - D21921 is holding up -- I haven't hit any issues with the core logic of that patch. - AAResults holds handles to various AA result objects. This means it pretty much always needs to be invalidated unless you are sure that non...

...one of the main issues. I think once you start testing out the new PM "for real" you will change your position. (Correct me if I'm wrong, but I have to assume that you haven't yet because you would have run into the showstopping bug that started this thread (filed as PR28622), or PR28400, or even simply PR28577.) -- Sean Silva > > I think it would be better to iterate on this once we understand how the > new pass manager works. I think exposing the fact that these things are > cached is really important and useful, and it makes querying across IR unit > boundarie...

...f the problems. >> - BasicAA and other stuff are marked (by overriding `invalidate` to >> return false) to never be invalidated because they are "stateless". However >> they still hold pointers and so they do need to be invalidated. >> - CallGraph uses AssertingVH (PR28400) and so I needed a workaround >> similar to r274656 in various passes. >> - D21921 is holding up -- I haven't hit any issues with the core logic >> of that patch. >> - AAResults holds handles to various AA result objects. This means it >> pretty much always needs t...

...> - BasicAA and other stuff are marked (by overriding `invalidate` to > > return false) to never be invalidated because they are "stateless". > > However they still hold pointers and so they do need to be > > invalidated. > > > - CallGraph uses AssertingVH (PR28400) and so I needed a workaround > > similar to r274656 in various passes. > > > - D21921 is holding up -- I haven't hit any issues with the core > > logic of that patch. > > > - AAResults holds handles to various AA result objects. This means > > it > >...

...; > return false) to never be invalidated because they are > > > > "stateless". > > > > However they still hold pointers and so they do need to be > > > > invalidated. > > > > > > > > > > - CallGraph uses AssertingVH (PR28400) and so I needed a > > > > workaround > > > > similar to r274656 in various passes. > > > > > > > > > > - D21921 is holding up -- I haven't hit any issues with the > > > > core > > > > logic of that patch. > &gt...

...; > return false) to never be invalidated because they are > > > > "stateless". > > > > However they still hold pointers and so they do need to be > > > > invalidated. > > > > > > > > > > - CallGraph uses AssertingVH (PR28400) and so I needed a > > > > workaround > > > > similar to r274656 in various passes. > > > > > > > > > > - D21921 is holding up -- I haven't hit any issues with the > > > > core > > > > logic of that patch. > &gt...

...; > return false) to never be invalidated because they are > > > > "stateless". > > > > However they still hold pointers and so they do need to be > > > > invalidated. > > > > > > > > > > - CallGraph uses AssertingVH (PR28400) and so I needed a > > > > workaround > > > > similar to r274656 in various passes. > > > > > > > > > > - D21921 is holding up -- I haven't hit any issues with the > > > > core > > > > logic of that patch. > &gt...

...>>> - BasicAA and other stuff are marked (by overriding `invalidate` to >>> return false) to never be invalidated because they are "stateless". However >>> they still hold pointers and so they do need to be invalidated. >>> - CallGraph uses AssertingVH (PR28400) and so I needed a workaround >>> similar to r274656 in various passes. >>> - D21921 is holding up -- I haven't hit any issues with the core logic >>> of that patch. >>> - AAResults holds handles to various AA result objects. This means it >>> pretty...

...- BasicAA and other stuff are marked (by overriding `invalidate` to >>>> return false) to never be invalidated because they are "stateless". However >>>> they still hold pointers and so they do need to be invalidated. >>>> - CallGraph uses AssertingVH (PR28400) and so I needed a workaround >>>> similar to r274656 in various passes. >>>> - D21921 is holding up -- I haven't hit any issues with the core logic >>>> of that patch. >>>> - AAResults holds handles to various AA result objects. This means it &gt...

...- BasicAA and other stuff are marked (by overriding `invalidate` to >>>> return false) to never be invalidated because they are "stateless". However >>>> they still hold pointers and so they do need to be invalidated. >>>> - CallGraph uses AssertingVH (PR28400) and so I needed a workaround >>>> similar to r274656 in various passes. >>>> - D21921 is holding up -- I haven't hit any issues with the core logic >>>> of that patch. >>>> - AAResults holds handles to various AA result objects. This means it &gt...

...ff are marked (by overriding `invalidate` to >>>>>> return false) to never be invalidated because they are "stateless". However >>>>>> they still hold pointers and so they do need to be invalidated. >>>>>> - CallGraph uses AssertingVH (PR28400) and so I needed a workaround >>>>>> similar to r274656 in various passes. >>>>>> - D21921 is holding up -- I haven't hit any issues with the core >>>>>> logic of that patch. >>>>>> - AAResults holds handles to various AA r...

...t;>>>>> - BasicAA and other stuff are marked (by overriding `invalidate` to return false) to never be invalidated because they are "stateless". However they still hold pointers and so they do need to be invalidated. >>>>>>> - CallGraph uses AssertingVH (PR28400) and so I needed a workaround similar to r274656 in various passes. >>>>>>> - D21921 is holding up -- I haven't hit any issues with the core logic of that patch. >>>>>>> - AAResults holds handles to various AA result objects. This means it pretty much a...

...d (by overriding `invalidate` to >>>>>>> return false) to never be invalidated because they are "stateless". However >>>>>>> they still hold pointers and so they do need to be invalidated. >>>>>>> - CallGraph uses AssertingVH (PR28400) and so I needed a workaround >>>>>>> similar to r274656 in various passes. >>>>>>> - D21921 is holding up -- I haven't hit any issues with the core >>>>>>> logic of that patch. >>>>>>> - AAResults holds handles...

On Wed, Jul 13, 2016 at 12:25 AM Sean Silva <chisophugis at gmail.com> wrote: > On Tue, Jul 12, 2016 at 11:39 PM, Chandler Carruth <chandlerc at gmail.com> > wrote: > >> On Tue, Jul 12, 2016 at 11:34 PM Sean Silva <chisophugis at gmail.com> >> wrote: >> >>> On Tue, Jul 12, 2016 at 11:32 PM, Xinliang David Li <davidxl at google.com>

...ding `invalidate` to >>>>>>>> return false) to never be invalidated because they are "stateless". However >>>>>>>> they still hold pointers and so they do need to be invalidated. >>>>>>>> - CallGraph uses AssertingVH (PR28400) and so I needed a workaround >>>>>>>> similar to r274656 in various passes. >>>>>>>> - D21921 is holding up -- I haven't hit any issues with the core >>>>>>>> logic of that patch. >>>>>>>> - AAResul...