similar to: llvm-ir: anonymous struct name mangling

On 7/7/2017 4:59 PM, Davide Italiano wrote: > On Fri, Jul 7, 2017 at 1:47 PM, Chad Rosier <mcrosier at codeaurora.org> wrote: >> David/Johan, >> >> I would love to claim victory, but I don't think that D34901 catches this >> case. >> > Hi Chad, thanks for taking another look at this. > Maybe I didn't bisect correctly. Apologies. Anyway, more fun

On 8/4/2017 2:06 PM, Daniel Berlin wrote: > A few notes: > I'm a bit surprised IPO copy/constant propagation doesn't get this > case, but i didn't look if the lattice supports variables. > In particular, in your example, given no other call sites, it should > eliminate the dead code. > (In a real program, it may require cloning). In the actual program

2017-10-14 5:03 GMT+02:00 Daniel Berlin <dberlin at dberlin.org>: > FWIW: We hit a subset of this issue with MemorySSA (which subclasses value > for the MemoryAccess's, etc), and it was discussed as well during > PredicateInfo. > > NewGVN has a variant the same issue as well, where it actually creates > unattached (IE not in a basic block) new instructions just so it

Hey folks, After a long amount of discussion both offline and on, I put a pass/intrinsic to add extended SSA up at http://reviews.llvm.org/D29316. Sean asked me to share it more broadly on llvm-dev, so here you go :) For those not familiar with extended-SSA, it's described in the paper "ABCD: Eliminating Array Bounds Checks on Demand". There is a very large amount of explanation

All, I'm working on an improvement to the inline cost model, but I'm unsure how to proceed. Let me begin by first describing the problem I'm trying to solve. Consider the following pseudo C code: *typedef struct element { unsigned idx; } element_t; * *static inline unsigned char fn2 (element_t *dst_ptr, const element_t *a_ptr, const element_t *b_ptr,

Hi, Coincidentally I've been working to optimize this same case last week. I was struggling a bit to determine where to put this functionality and eventually went for the pragmatic approach of creating an experimental pass. Probably not the eventual solution, but it may provide some useful input to the discussion here. Basically, I experimented with a 'pre-inlining-transform' pass

Hi All, We have recently found some optimization opportunities created by replicating code into branches in order to enable optimization. In general, the optimization opportunity we are pursuing is like the following. Given pseudo-code: // block A if (some condition) // block B // block C If it can be efficiently proven that some portion of block C can be simplified had control flow not

On 10/14/2017 05:28 PM, Daniel Berlin via llvm-dev wrote: > > > On Sat, Oct 14, 2017 at 2:54 PM, Michael Kruse <llvmdev at meinersbur.de > <mailto:llvmdev at meinersbur.de>> wrote: > > 2017-10-14 5:03 GMT+02:00 Daniel Berlin <dberlin at dberlin.org > <mailto:dberlin at dberlin.org>>: > > FWIW: We hit a subset of this issue with

>Do you recall the arguments why it was considered a bad idea? Felt like long time ago, but it turned out that was actually just a bit over a year ago. Here's the thread. http://lists.llvm.org/pipermail/llvm-dev/2016-August/104079.html Only a few explicitly responded, but I took that as silent majority was satisfied with the responses. Prior to that thread, I also pinged HPC oriented LLVM

I'm running lmer repeatedly on artificial data with two fixed factors (called 'gender' and 'stress') and one random factor ('speaker'). Gender is a between-speaker variable, stress is a within-speaker variable, if that matters. Each dataset has 100 rows from each of 20 speakers, 2000 rows in all. About 5% of the time I get a strange result, where the lmer() model with

On Sun, Feb 5, 2017 at 12:25 PM, Nuno Lopes <nunoplopes at sapo.pt> wrote: > Hi Daniel, > > Many thanks for working on this! > SSI/e-SSA is the only way I'm aware of for doing efficient sparse > analyses, so I'm definitely in favor of adding support for it in LLVM! > > I read the discussion so far and did a cursory review of the patches, and > I have just a

Signed-off-by: ZhiHu <huzhi001 at 208suo.com> --- .../gpu/drm/nouveau/nvkm/engine/fifo/gk104.c | 40 ++++++++++++++----- 1 file changed, 29 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c index d8a4d773a58c..b99e0a7c96bb 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c +++

Signed-off-by: ZhiHu <huzhi001 at 208suo.com> --- .../gpu/drm/nouveau/nvkm/engine/fifo/gk104.c | 40 ++++++++++++++----- 1 file changed, 29 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c index d8a4d773a58c..b99e0a7c96bb 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c +++

not sure how i got signed up for this and i don?t see a way to unsubscribe. this is flooding my email with things i don?t care about. On Fri, Jul 14, 2023, at 1:14 AM, huzhi001 at 208suo.com wrote: > Signed-off-by: ZhiHu <huzhi001 at 208suo.com> > --- > .../gpu/drm/nouveau/nvkm/engine/fifo/gk104.c | 40 ++++++++++++++----- > 1 file changed, 29 insertions(+), 11 deletions(-)

NAK - checkpatch.pl is a (strongish) guideline, but not a rule. In the cases corrected in the patch series here, we format the switch cases on single lines as it dramatically improves the readability of what is otherwise just a /long/ list of slightly different static mappings. I don't believe we're the only part of the kernel to do this either. On Fri, 2023-07-14 at 14:58 +0800, huzhi001

On Tue, Apr 11, 2017 at 3:14 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Hi Kostya, > > On April 11, 2017 at 2:39:44 PM, Kostya Serebryany (kcc at google.com) wrote: > > > ptr0 = malloc(); > > > free(ptr0); > > > ptr1 = malloc(); > > > > > > ptr0 and ptr1 will be NoAlias despite overlapping (there is actually a > >

On Tue, Apr 11, 2017 at 1:40 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Hi, > > On April 11, 2017 at 1:37:20 PM, Sanjoy Das > (sanjoy at playingwithpointers.com) wrote: > > Hi Kostya, > > > > On April 11, 2017 at 1:30:10 PM, Kostya Serebryany (kcc at google.com) > wrote: > > > > > of course, but accesses are done via pointers,

Hi Kostya, On April 11, 2017 at 1:30:10 PM, Kostya Serebryany (kcc at google.com) wrote: > of course, but accesses are done via pointers, and if TBAA queries > MayAlias(AccessViaP1, AccessViaP2) > there should (??) be a point in the IR where both P1 and P2 exist together > and can be compared. That may not be possible (though I'm second guessing what exactly you have in mind so

> On Thu, Aug 10, 2017 at 12:22 AM, Nema, Ashutosh via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> I’m not sure how transforming GEP offset to i8 type will help alias >> analysis & SROA for the mentioned test case. > > It should neither help nor hinder AA or SROA -- the two GEPs (the complex one and the simple one) are equivalent. > Since memory isn't

please add the following diffs to the vorbis/vq dir. - include files changed so things actually compile in new scheme - _ogg_...alloc cleanups caught a half-dozen typos or so - minor Makefile touchup. (stuff is still not tested, but this will compile at least) Would someone with cvs write access commit them for me please? Erik diffs: ------------------------ diff -bBu2r vorbis/vq/Makefile