search for: sjoerd

...ng about verbose output right? Verbose isn’t the default. > I'm fairly certain the issue in this thread is just the verbosity of -dump-input=fail. Yes, -vv makes it even more verbose by annotating input lines with good matches, etc., but that's not part of the "new behaviour" Sjoerd meant, I believe. Joel > > > *From:* Joel E. Denny <jdenny.ornl at gmail.com> > *Sent:* Thursday, June 18, 2020 10:54 AM > *To:* Chris Tetreault <ctetreau at quicinc.com> > *Cc:* Sjoerd Meijer <Sjoerd.Meijer at arm.com>; llvm-dev at lists.llvm.org > *Subjec...

...llvm-lit -a ../llvm/test/CodeGen/my_test.ll In a terminal, the new default behaviour of FileCheck has become pretty unusable IMHO. ________________________________ From: Chris Tetreault <ctetreau at quicinc.com> Sent: 18 June 2020 20:49 To: Joel E. Denny <jdenny.ornl at gmail.com> Cc: Sjoerd Meijer <Sjoerd.Meijer at arm.com>; llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org> Subject: RE: [llvm-dev] FileCheck Sjoerd specifically said “in verbose mode”, which I interpret to mean “when passing -v or -vv”. If we’re discussing the default behavior, then that’s a separate...

...the tests is a separate discussion. That is, I think you can have 1 test-case in 1 file, and the current behaviour is already inconvenient, so don't see that as a solution. Cheers. ________________________________ From: Mehdi AMINI <joker.eph at gmail.com> Sent: 19 June 2020 09:32 To: Sjoerd Meijer <Sjoerd.Meijer at arm.com> Cc: Chris Tetreault <ctetreau at quicinc.com>; Joel E. Denny <jdenny.ornl at gmail.com>; llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] FileCheck On Fri, Jun 19, 2020 at 12:56 AM Sjoerd Meijer via llvm-dev...

Yep, exactly that. We see quite a lot of them, most of them get cleaned up, but not always... Cheers. ________________________________ From: Roger Ferrer Ibáñez <rofirrim at gmail.com> Sent: 16 March 2020 08:53 To: Sjoerd Meijer <Sjoerd.Meijer at arm.com> Cc: LLVM-Dev <llvm-dev at lists.llvm.org>; Sam Parker <Sam.Parker at arm.com> Subject: Re: [llvm-dev] Redundant copies At this point however it doesn't (obviously) look like one (it still using different vregs) which suggests it might requir...

...point, they are going to customize it however they want. I > assume anybody using filecheck to debug an issue is tech savvy enough to be > able to configure the options, given reasonable documentation. > > > > Thanks, > > Christopher Tetreault > > > > *From:* Sjoerd Meijer <Sjoerd.Meijer at arm.com> > *Sent:* Thursday, June 18, 2020 9:45 AM > *To:* Chris Tetreault <ctetreau at quicinc.com> > *Cc:* llvm-dev at lists.llvm.org > *Subject:* [EXT] Re: [llvm-dev] FileCheck > > > > > > I would guess that in a CI system the or...

...his, and yeah, it's fine either way, I was guessing. My primary use-case is usage in a terminal, and displaying the errors first followed by all input makes this pretty unusable. ________________________________ From: Chris Tetreault <ctetreau at quicinc.com> Sent: 18 June 2020 17:34 To: Sjoerd Meijer <Sjoerd.Meijer at arm.com> Cc: llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org> Subject: RE: [llvm-dev] FileCheck For anybody viewing these failures through some sort of CI system, showing the error first then the input file is more useful for the same reasons you mentio...

Thanks for reply. I was using LLVM 8.0. Let me try trunk and will let you know if it works. On Wed, Sep 4, 2019 at 11:19 PM Sjoerd Meijer <Sjoerd.Meijer at arm.com> wrote: > > Hi, > Which version of Clang are you using? I do get a "vfma.f16" with a recent trunk build. I haven't looked at older versions and when this landed, but we had an effort to plug the remaining fp16 holes not that long ago, so...

...ores hit the backend, we translate the generic intrinsic get.active.mask to a target specific one. All predication remains explicit, and this remains the case. Only at the end, we use this intrinsic to instruction select a specific variant of the hardwarloop with some implicit predication. Cheers, Sjoerd. ________________________________ From: Simon Moll <Simon.Moll at EMEA.NEC.COM> Sent: 19 May 2020 09:56 To: Sjoerd Meijer <Sjoerd.Meijer at arm.com> Cc: Roger Ferrer Ibáñez <rofirrim at gmail.com>; Eli Friedman <efriedma at quicinc.com>; listmail at philipreames.com <lis...

...ked.load(.., %mask) where IV is the induction step, and BTC the backedge taken count. This completely piggy backs on everything that is already there in the vectoriser, and nothing is fundamentally changed here. Now, this seems very generic, and doesn't seem to bite the VP intrinsics. Cheers, Sjoerd. ________________________________ From: Simon Moll <Simon.Moll at EMEA.NEC.COM> Sent: 19 May 2020 15:07 To: Sjoerd Meijer <Sjoerd.Meijer at arm.com> Cc: Roger Ferrer Ibáñez <rofirrim at gmail.com>; Eli Friedman <efriedma at quicinc.com>; listmail at philipreames.com <lis...

...ink the VP intrinsics were able to provide this. But to be honest, I have no preference at all what this intrinsic is, it is not relevant, as long as we can make this explicit. Cheers. ________________________________ From: Simon Moll <Simon.Moll at EMEA.NEC.COM> Sent: 18 May 2020 14:11 To: Sjoerd Meijer <Sjoerd.Meijer at arm.com> Cc: Roger Ferrer Ibáñez <rofirrim at gmail.com>; Eli Friedman <efriedma at quicinc.com>; listmail at philipreames.com <listmail at philipreames.com>; llvm-dev <llvm-dev at lists.llvm.org>; Sander De Smalen <Sander.DeSmalen at arm.co...

...e the canonical form of loops, but couldn't find any evidence of that in [1] or in source-code. The obvious follow-up question is if there would be any objections to adding this to e.g. LoopSimplifyCFG, and adding LoopSimplifyCFG to the optimisation pipeline just before the vectoriser. Cheers, Sjoerd. [1] https://llvm.org/docs/LoopTerminology.html -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200326/ecc075e6/attachment.html>

Hi Sjoerd We (at Huawei) also have a pass for this. Originally we implemented this back in 2018 and meant to upstream it, but there were some issues with the implementation that required some changes in the code. We started revising it,a few weeks ago. I thought now that there are multiple options, maybe w...

Hi Sjoerd, On Fri, May 3, 2019 at 8:19 AM Sjoerd Meijer via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > I read that out-of-order cores are supported. How about in-order cores? > Would it be easy/difficult to add support for that? > > Cheers, > Sjoerd. > > I don't thi...

...and it is just a bit horrible, so we need something robust, and a simple way of passing this information on from the vectoriser to the backend. I still might have skipped a few details here, but this is what it boils down to, and hopefully you've got a good impression of the problem. Cheers, Sjoerd. ________________________________ From: Zaks, Ayal (Mobileye) <ayal.zaks at intel.com> Sent: 21 May 2020 18:44 To: Sjoerd Meijer <Sjoerd.Meijer at arm.com>; Eli Friedman <efriedma at quicinc.com> Cc: llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org> Subject: RE: [llv...

On 11/6/20 12:39 PM, Sjoerd Meijer wrote: Hello Simon, Thanks for your replies, very useful. And yes, thanks for the example and making the target differences clear: ; Some examples: ; RISC-V V & VE(*): ; %mask = (splat i1 1) ; %evl = min(256, %n - %i) ; MVE/SVE : ; %mask = get.active.lane.mask(%i, %n...

...s.mask(%IV, %BTC) avoids all of this, as we can just pick up %BTC in the backend. As we are looking for the scalar loop iteration count, not the VIV, I don't think SCEV for vector loops is going to be helpful. Please let me know if I can elaborate further, or if things are not clear. Cheers, Sjoerd. ________________________________ From: Zaks, Ayal (Mobileye) <ayal.zaks at intel.com> Sent: 20 May 2020 20:39 To: Sjoerd Meijer <Sjoerd.Meijer at arm.com>; Eli Friedman <efriedma at quicinc.com> Cc: llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org> Subject: RE: [l...

...verbosity. > > For my personal usage, I don't care what the default behavior is as long > as behavior is easy to customize. FILECHECK_OPTS lets me do that per test > suite run, or in my ~/.profile, or in my CI configs, etc. > > Joel > > On Thu, Jun 18, 2020 at 12:45 PM Sjoerd Meijer via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> I would guess that in a CI system the order doesn't matter much because >> you look at a webpage? I looked at some build bots today/yesterday that now >> also show this, and yeah, it's fin...

...nf.org/event/7/contributions/802/), but that made me curious if we can and/or should enable LTO and/or PGO to create our prebuilt binaries? The disadvantage for our release people will be obvious: that will take a lot more time and resources. But would it be worth to make this investment? Cheers, Sjoerd. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200907/40da8714/attachment.html>

...fragile too. All we need is the information that the vectoriser already has, and pass this on somehow. As I am really keen to simply our backend pass, would there be another way to pass this information on? If emitting an intrinsic is a blocker, could this be done with a loop annotation? Cheers, Sjoerd. ________________________________ From: Eli Friedman <efriedma at quicinc.com> Sent: 01 May 2020 19:30 To: Sjoerd Meijer <Sjoerd.Meijer at arm.com>; llvm-dev <llvm-dev at lists.llvm.org> Subject: RE: [llvm-dev] LV: predication The problem with your proposal, as written, is that...

...with a better understanding why current downstream passes pessimize canonical iv's, if they still do? > -----Original Message----- > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Michael > Kruse via llvm-dev > Sent: Saturday, March 28, 2020 12:33 > To: Sjoerd Meijer <Sjoerd.Meijer at arm.com> > Cc: llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] canonical form loops > > The topic came up before, e.g. https://reviews.llvm.org/D60565#1484984 > > > Some canonicalization passes are designed for this. In particular, > Ind...