similar to: Regarding Usage of opt

Hi all, I'm looking into resolving a FIXME in the LoopDataPrefetch (and FalkorMarkStridedAccesses) pass by marking both of these passes as preserving the ScalarEvolution analysis. Unfortunately, when this change is made, LSR will generate different code. One of the root causes seems to be that SCEV will return different nsw/nuw flags for the same Value, depending on what order the

On 8/8/2017 1:37 PM, Friedman, Eli wrote: > On 8/8/2017 10:22 AM, Geoff Berry via llvm-dev wrote: >> Hi all, >> >> I'm looking into resolving a FIXME in the LoopDataPrefetch (and FalkorMarkStridedAccesses) pass by marking both of these passes as preserving the ScalarEvolution analysis. Unfortunately, when this change is made, LSR will generate different code. One of the

> 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 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

Hi, There was a recent discussion on generating non-temporal stores automatically[1]. This is a hard problem to get right. What seems like a much easier but still useful problem to solve is to provide diagnostics to the user where NT stores *may* help. Then the user can add the corresponding builtins and see if they are beneficial. My hope is that with the work to add profile-driven

Hey, I've been reading back the thread and there's a lot of ideas flying around, I may have missed more than I should, but here's my view on it. First, I think this is a good idea. Mapping caches is certainly interesting to general architectures, but particularly important to massive operations like matrix multiply and stencils can pull a lot of data into cache and sometimes thrash

Am Do., 1. Nov. 2018 um 15:21 Uhr schrieb David Greene <dag at cray.com>> > > thank you for sharing the system hierarchy model. IMHO it makes a lot > > of sense, although I don't know which of today's passes would make use > > of it. Here are my remarks. > > LoopDataPrefetch would use it via the existing TTI interfaces, but I > think that's about it

Hi, thank you for sharing the system hierarchy model. IMHO it makes a lot of sense, although I don't know which of today's passes would make use of it. Here are my remarks. I am wondering how one could model the following features using this model, or whether they should be part of a performance model at all: * ARM's big.LITTLE * NUMA hierarchies (are the NUMA domains