search for: kuperstein

...omments, CodeExtractor is buggy only > works for special cases but not general enough for most usages. Then do we > have other outlining solution in llvm? Or I have to repeat what Michel done > before? > > Best regards, > Ming-Hwa > > On Tue, Apr 12, 2016 at 1:48 PM, Michael Kuperstein < > michael.kuperstein at gmail.com> wrote: > >> CodeExtractor sort of does this. >> >> First, it's a utility, not a pass - you'd still need to wrap it up with >> pass that actually causes it to outlines what you want it to outline. >> >> Seco...

Kuperstein, Michael M wrote: > Regarding the name, I'm not sure noaliasAtFunctionEntry makes sense, for two reasons: > a) The pointer involved may not be defined at entry. Right, I thought of that too. > b) We already have something which is similar in spirit - IsIdentifiedObject. That covers t...

Kuperstein, Michael M wrote: > Thanks Nick! > > Can you just check sanity before I commit? > (Or suggest a better name for the function...) Sure! +static bool canNotAliasDiffArgument(const Value *V) +{ + return (isa<AllocaInst>(V) || isNoAliasCall(V) || isNoAliasArgument(V)); +} Extra pa...

> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] > On Behalf Of Kuperstein, Michael M via llvm-dev > Subject: Re: [llvm-dev] Test Email - Apologies for the noise > I'm seeing the same issue here, also with Outlook. > Had to CC the list manually for this email) Same problem here - good to know it's not just me. For reference, I'm using Outlook versi...

Hi Nadav, On 08/09/12 22:51, Nadav Rotem wrote: > > On Aug 19, 2012, at 2:55 PM, "Kuperstein, Michael M" > <michael.m.kuperstein at intel.com <mailto:michael.m.kuperstein at intel.com>> wrote: > >> Hello, >> Currently, llvm::isSafeToSpeculativelyExecute() always returns false for Call >> instructions. >> This has actual performance implication...

...alValue. Regarding the namespace - I just thought I should keep isNoAliasArgument close to isNoAliasCall. I'll move it to BasicAliasAnalysis if you think that's a better idea. -----Original Message----- From: Nick Lewycky [mailto:nicholas at mxc.ca] Sent: Monday, May 27, 2013 13:54 To: Kuperstein, Michael M Cc: LLVMdev at cs.uiuc.edu Subject: Re: [LLVMdev] Mixing noalias and regular arguments Kuperstein, Michael M wrote: > Thanks Nick! > > Can you just check sanity before I commit? > (Or suggest a better name for the function...) Sure! +static bool canNotAliasDiffArgument(con...

...lternative is to turn this on, and then, if regressions show up on anyone's radar (where we can actually get a reproducer), turn it off again and go back to analysis. But I'd strongly prefer to "prefetch" the problem. Thanks, Michael On Wed, Aug 10, 2016 at 4:32 PM, Michael Kuperstein <mkuper at google.com> wrote: > So, unfortunately, it turns out I don't have access to DENBench. > > Do you happen to have a reduced example that gets pessimized by this? > > On Tue, Aug 9, 2016 at 11:25 AM, Michael Kuperstein <mkuper at google.com> > wrote: >...

...t been a while since I worked on the vectorizers and I think that it's time for someone else to be the code owner. During the conference I talked about this with Arnold and a few other people who were involved in the development of the vectorizers. Based on these discussions I recommend Michael Kuperstein. Michael is committed to improving LLVM and has lots of relevant experience. If approved by the community, I know he would do a great job working with contributors on improving the vectorizers and reviewing the recent proposals from ARM and Intel. -Nadav -------------- next part -------------- An...

...t; > *out++ = y; > > *out++ = (unsigned char)i; > > *out++ = (unsigned char)q; > > } > > } > > > > but you’d currently need to force it to vectorize to overcome its expected > cost. > > > > Ayal. > > > > *From:* Michael Kuperstein [mailto:mkuper at google.com] > *Sent:* Wednesday, August 17, 2016 00:51 > *To:* Zaks, Ayal <ayal.zaks at intel.com>; Demikhovsky, Elena < > elena.demikhovsky at intel.com> > *Cc:* Renato Golin <renato.golin at linaro.org>; Matthew Simpson < > mssimpso at codeaur...

On Aug 19, 2012, at 2:55 PM, "Kuperstein, Michael M" <michael.m.kuperstein at intel.com> wrote: > Hello, > > Currently, llvm::isSafeToSpeculativelyExecute() always returns false for Call instructions. > This has actual performance implications, because loop-invariant code motion makes this check, and will never h...

On 13 October 2015 at 13:45, Kuperstein, Michael M via llvm-dev <llvm-dev at lists.llvm.org> wrote: > As far as I know, the consensus was that all 3.x versions should retain > backward compatibility for bitcode. Emphasis on "should". :) I don't think we have enough tests to make sure we don't break that pr...

On Tue, Nov 19, 2013 at 9:56 PM, Kuperstein, Michael M < michael.m.kuperstein at intel.com> wrote: > What I’m trying to say is that according to my understanding of the > C++11 memory model, even in that small reproducer, the store to g and the > load from g are in fact a data race. > > (This is regardless of the fact...

...at we see are in 32-bit mode. > > > > One place to find them, using the default BaseT::getInterleavedMemoryOpCost(), > is DENBench’s RGB conversions. > > > > Ayal. > > > > *From:* Demikhovsky, Elena > *Sent:* Monday, August 08, 2016 00:09 > *To:* Michael Kuperstein <mkuper at google.com>; Renato Golin < > renato.golin at linaro.org> > *Cc:* Matthew Simpson <mssimpso at codeaurora.org>; Nema, Ashutosh < > Ashutosh.Nema at amd.com>; Sanjay Patel <spatel at rotateright.com>; llvm-dev < > llvm-dev at lists.llvm.org>...

Kuperstein, Michael M wrote: > Ping? Pong! Sorry for the slow review, I had this patch starred but hadn't got around to it. Yes, the rationale and implementation are correct. > (Is there a code owner for AA, btw?) (It falls back on the more general code owner who is Chris Lattner in this case,...

On 12/16/2016 11:37 AM, Michael Kuperstein wrote: > Calling an instruction a "source" is basically another way to say "we > can't dataflow through this". > > What I'm trying to say is that this is not really a property of the > instruction type. > I agree we should be adding annotations sparin...

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Herbie Robinson > Subject: Re: [LLVMdev] [RFC] [X86] Mov to push transformation in x86-32 call sequences > > On 12/21/14 4:27 AM, Kuperstein, Michael M wrote: > > Which performance guidelines are you referring to? > Table C-21 in "Intel(r) 64 and IA-32 Architectures Optimization Reference Manual", September 2014. > It hasn't changed. It still lists push and pop instructions as 2-3 times more expensive as mov...

...fer to do this in stages. Here I'm just preserving the current behavior by marking intrinsics that used to be explicitly handled in isSafeToSpeculativelyExecute(), so there should be no functional change. From: Nick Lewycky [mailto:nlewycky at google.com] Sent: Tuesday, July 23, 2013 02:29 To: Kuperstein, Michael M Cc: Nick Lewycky; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Does nounwind have semantics? On 22 July 2013 01:11, Kuperstein, Michael M <michael.m.kuperstein at intel.com<mailto:michael.m.kuperstein at intel.com>> wrote: Of course frontends are free to put attributes, but...

On Tue, Aug 13, 2013 at 5:58 AM, Kuperstein, Michael M < michael.m.kuperstein at intel.com> wrote: > Hi,**** > > ** ** > > It looks like SimplifyLibCalls has a tendency to emit calls to libm > functions without checking with TLI whether these calls are available.**** > > For example, PowOpt has this code:****...

Kuperstein, Michael M wrote: > A patch is attached. + const CallInst* CI = dyn_cast<CallInst>(Inst); + return CI->isSafeToSpeculativelyExecute(); "return cast<CallInst>(Inst)->isSafeToSpeculativelyExecute();"? Use cast<> instead of dyn_cast<>. See http://ll...

...ent to "llc -mtriple=x86_64-unknown-linux-gnu -mcpu=generic". TTI queries (in e.g., CodeGenPrepare) would be based on this. From opt, if the target triple is left unspecified, we will use the "base" TTI implementation (not x86). -- Matt On Wed, Nov 30, 2016 at 2:07 PM, Michael Kuperstein via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Right, let's say what we get from llc --version is: > > Default target: x86_64-unknown-linux-gnu > Host CPU: haswell > > So, what we currently do is use the default target (which is normally the > host target),...