search for: gberri

Hi George, After digging a little deeper, it appears that readonly calls showing up as MemoryDefs is only happening on an EarlyCSE test that is using the new pass manager (test/Transforms/EarlyCSE/basic.ll test5 if you’re curious), so I suspect it is an issue with the new pass manager setup code for either MemorySSA, my changes to EarlyCSE, the test run command line or something else not

1) Sounds good. This isn’t holding me up so I’ll just try to keep an eye out for these changes. 2) I’ve attached an example IR file and debug log of where the caching is going bad. It depends on my changes to EarlyCSE, but hopefully it is clear from the debug output what is going on. Let me know if there is a better way to get this repro case to you. Also, I’ll be on IRC for the

Hi, I recently found myself in trouble because the crash I had disappeared with -g, so I could not debug the program. This happened because the optimizer did not remember to consider DBG_VALUEs instruction so it changed its behavior, and the bug went hiding. I then started discussing this on https://reviews.llvm.org/D45878, and since this is something that should be handled by all different

> On Aug 14, 2017, at 7:35 AM, Geoff Berry <gberry at codeaurora.org> wrote: > > Hi Sanjoy, > > [adding Adam since I believe he added the original FIXME to preserve SCEV > in LoopDataPrefetch] For record, that wasn’t me. It was there from the beginning when Hal added the PPC-specific pass. Adam > > On 8/14/2017 1:36 AM, Sanjoy Das wrote: >> Hi Geoff,

Hi Daniel, Thanks for the info. I’ve started looking into converting EarlyCSE to use MemorySSA first since 1) I don’t think it needs any additional MemorySSA update API and 2) the particular case I’m looking at needs EarlyCSE to catch more load cases before LICM to be profitable. I have a prototype working, but have run into two issues: 1) readonly calls are treated as clobbers by

On 9/26/2017 6:47 PM, Matthias Braun wrote: > >> On Sep 26, 2017, at 3:33 PM, Geoff Berry <gberry at codeaurora.org >> <mailto:gberry at codeaurora.org>> wrote: >> >> >> >> On 9/26/2017 6:11 PM, Matthias Braun wrote: >>>> On Sep 26, 2017, at 2:39 PM, Geoff Berry via llvm-dev >>>> <llvm-dev at lists.llvm.org

I've put my changes to EarlyCSE that trigger this case up on phab here: http://reviews.llvm.org/D19821. These changes depend on http://reviews.llvm.org/D19664 so that will need to be applied first. With these changes applied, the original attached .ll file should trigger this bug when compiled with opt -early-cse -early-cse-use-memoryssa On 5/2/2016 2:34 PM, Daniel Berlin wrote: >

> On Sep 26, 2017, at 8:24 PM, Geoff Berry via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 9/26/2017 6:47 PM, Matthias Braun wrote: >>> On Sep 26, 2017, at 3:33 PM, Geoff Berry <gberry at codeaurora.org <mailto:gberry at codeaurora.org> <mailto:gberry at codeaurora.org <mailto:gberry at codeaurora.org>>> wrote: >>> >>>

I suspect something is pulling the RHS of the memorydef and caching it for calls it should not be used for. In particular, i suspect we are about to discover we can't cache the results from both versions of getClobberingMemoryAccess together, or that the cache is not always getting consistently written. On Mon, May 2, 2016 at 11:16 AM, George Burgess IV < george.burgess.iv at

Forgive me if these questions are naive or if I'm misunderstanding something. I'm certainly very interested in seeing the MachineCopyPropagation patch finally land and stick. 1. Wouldn't function live-ins and reserved registers have started life as physical registers already? For example, wouldn't a live-in be a copy from a physical register to a virtual one allowing the flag to

Yeah, they are just triggered by lit check tests. I’ll file some bugs today, though it looks like Quentin may have already filed bugs for some of these. -- Geoff Berry Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project From: Daniel Berlin [mailto:dberlin at dberlin.org] Sent: Friday,

Hi All, I'm looking into converting LICM to use MemorySSA instead of AliasSets to determine when it is safe to hoist/sink/promote loads and stores to get around the issue of alias set collapse (see discussion [1]). I have a prototype implementation, but have run into two issues that I could use input from the designers of MemorySSA to resolve: 1) Is MemorySSA intended to be

Hi Geoff, On Wed, Aug 9, 2017 at 8:58 AM, Geoff Berry <gberry at codeaurora.org> wrote: > On 8/8/2017 8:38 PM, Sanjoy Das wrote: >> >> Hi, >> >> On Tue, Aug 8, 2017 at 12:58 PM, Friedman, Eli <efriedma at codeaurora.org> >> wrote: >>> >>> Oh, I see... yes, we do stupid things involving mutating NoWrap flags >>> after

Thanks for noticing this, Geoff. I just landed r268050 which add a cmake option for this (and unifies XDEBUG and EXPENSIVE_CHECKS). This might make it easier to setup some build bots. Thank you, Filipe On Fri, Apr 22, 2016 at 8:40 PM, Geoff Berry via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Bugs filed: > 27488 <https://llvm.org/bugs/show_bug.cgi?id=27488> librarie

On 2018-02-22 11:14, gberry at codeaurora.org wrote: > FROM: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] ON BEHALF OF > Jun Lim via llvm-dev > SENT: Thursday, February 22, 2018 11:05 AM > > Hi All, > > I found some cases where a spill of a live range in a block is > reloaded only in one of its successors, and there is no reload in > other paths through other

> On Sep 26, 2017, at 3:33 PM, Geoff Berry <gberry at codeaurora.org> wrote: > > > > On 9/26/2017 6:11 PM, Matthias Braun wrote: >>> On Sep 26, 2017, at 2:39 PM, Geoff Berry via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> Hi all, >>> >>> Mikael reported a machine verification failure in his out-of-tree target

> From: junbuml at codeaurora.org [mailto:junbuml at codeaurora.org] > Sent: Thursday, February 22, 2018 11:39 AM > > On 2018-02-22 11:14, gberry at codeaurora.org wrote: > > FROM: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] ON BEHALF OF > > Jun Lim via llvm-dev > > SENT: Thursday, February 22, 2018 11:05 AM > > > > Hi All, > > > > I

This is definitely a caching bug related to this code: 1038 // Don't try to optimize this phi again if we've already tried to do so. 1039 if (!Q.Visited.insert(PHIPair).second) { 1040 ModifyingAccess = CurrAccess; 1041 break; 1042 } We don't differentiate elsewhere between having stopped at a phi because we were path walking and discovered that path

On 9/26/2017 6:11 PM, Matthias Braun wrote: > >> On Sep 26, 2017, at 2:39 PM, Geoff Berry via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi all, >> >> Mikael reported a machine verification failure in his out-of-tree target with the MachineCopyPropagation changes to forward registers (which is currently reverted). The verification in question is:

Hey All, I've come across what I believe to be a bug in MemorySSA. George, I wasn't sure if this was a known issue that you'll be addressing in your upcoming walker caching changes or not, so I haven't investigated it very much. The test case is attached. The bug is that the defining access for the second load is set to the loop MemoryPhi node instead of being liveOnEntry as