search for: johannesdoerfert

That’s a good question. I’m afraid I don’t know how/if that’s controlled in these tests. From: Johannes Doerfert <johannesdoerfert at gmail.com> Sent: Monday, June 08, 2020 3:05 PM To: Kaylor, Andrew <andrew.kaylor at intel.com>; Lazarev, Vladimir <vladimir.lazarev at intel.com> Cc: LLVM Developers <llvm-dev at lists.llvm.org>; bhomerding at anl.gov; Finkel, Hal J. <hfinkel at anl.gov>; Kruse, Michae...

> On Apr 3, 2020, at 11:06 AM, Johannes Doerfert <johannesdoerfert at gmail.com> wrote: > >> >> >> Is it worth it? I think it is. But I am not sure I see the whole picture - >> are there low-memory systems that need to run LLVM on? >> >> I am not sure what needs to be done to approve such a fundamental change; >>...

...wledge still no strong > arguments against removing it. > is everyone OK to proceed with the removal ? > > Gauthier > ------------------------------ > *From:* Chris Lattner <clattner at nondot.org> > *Sent:* Saturday, April 4, 2020 7:40 PM > *To:* Johannes Doerfert <johannesdoerfert at gmail.com> > *Cc:* Ehud Katz <ehudkatz at gmail.com>; llvm-dev at lists.llvm.org < > llvm-dev at lists.llvm.org>; Tyker1 at outlook.com <Tyker1 at outlook.com> > *Subject:* Re: [llvm-dev] [RFC] Removing Waymarking from Use. > > > > On Apr 3, 2020, at 11:...

...n llvm-test-suite/SYCL, but it should be easy enough to move them another level deeper to create a parallel structure to be shared with OpenMP. Vladimir is on vacation right now, but I believe he’ll be preparing a patch for review shortly after he returns. Thanks, Andy From: Johannes Doerfert <johannesdoerfert at gmail.com> Sent: Monday, June 08, 2020 2:00 PM To: Kaylor, Andrew <andrew.kaylor at intel.com> Cc: LLVM Developers <llvm-dev at lists.llvm.org>; bhomerding at anl.gov; Finkel, Hal J. <hfinkel at anl.gov>; Kruse, Michael <michael.kruse at anl.gov>; Malik,Abid <amalik...

...ey have no specific !scope tag? I've looked at the ScopedNoAliasAA but during the inline no !scope MD is created therefore it's not marked as NoAlias from that analysis (it returns MayAlias if no scope MD or no noalias MD). Thanks, Ryan On Mon, Sep 28, 2020, 8:53 PM Johannes Doerfert <johannesdoerfert at gmail.com> wrote: > Hi Ryan, > > the alias metadata was (and is) broken for various reasons. > he replacement is currently under review, I can point you to it, > however, to be honest, I'm unclear how we are supposed to help > you with LLVM 6 right now. > > Cheers...

> On Nov 9, 2020, at 19:27, Johannes Doerfert <johannesdoerfert at gmail.com> wrote: > On 11/9/20 5:09 AM, Florian Hahn wrote: >> >>> On Nov 6, 2020, at 17:32, Johannes Doerfert <johannesdoerfert at gmail.com <mailto:johannesdoerfert at gmail.com>> wrote: >>> >>> Cool! I really like the idea. I left a comment...

...rrectly use 'alias' metadata. I should define them in IR like below: !3 = !{!3} !4 = !{!4} !5 = !{!5, !3} !6 = !{!6, !4} And then use !5 and !6. The below usage is wrong: !3 = !{!3} !4 = !{!4} Then use !3 and !4 in IR. BR, Terry On Fri, Jul 24, 2020 at 12:12 AM Johannes Doerfert < johannesdoerfert at gmail.com> wrote: > `noalias` metadata is more complex than this: > > https://llvm.org/docs/LangRef.html#noalias-and-alias-scope-metadata > > I doubt the below was accepted by the AliasAnalysis as valid annotations > and consequently ignored. > > > On 7/23/20 10:48...

On 9/7/20 4:48 PM, Nicolai Hähnle wrote: > Hi Johannes, > > > On Mon, Sep 7, 2020 at 11:17 PM Johannes Doerfert > <johannesdoerfert at gmail.com> wrote: >> >> > As a separate comment, I don't find the reference to the C++ spec in >> >> > https://reviews.llvm.org/D86233 to be informative enough. Whenever >> >> > that section of the C++ spec talks about "progress&q...

...But I am not sure I am even framing the problem statement correctly at this point. 3. I have added a tentative tasks section and made a note that the project is open ended and things are quite fluid and may change significantly. Cheers Shiva On Mon, Mar 30, 2020 at 6:52 PM Johannes Doerfert < johannesdoerfert at gmail.com> wrote: > On 3/30/20 8:07 PM, Shiva Stanford wrote: > > 1. Thanks for the clarifications. I will stick to non-containerized OS X > > for now. > > Sounds good. As long as you can build it and run lit and llvm-test suite > tests :) > > > > 2. As...

On Feb 28, 2020, at 8:56 AM, Johannes Doerfert <johannesdoerfert at gmail.com> wrote: > On 02/28, Nicholas Krause via llvm-dev wrote: >> Anyhow what is the status and what parts are we planning to move to >> MLIR in LLVM/Clang. I've not seen any discussion on that other than >> starting to plan for it. > > As far as I know, t...

> On Mar 19, 2020, at 2:31 PM, Johannes Doerfert <johannesdoerfert at gmail.com> wrote: > > I think addressing this issue first makes sense. I would however start > by determining the actual impact of different design choices here. I > mean, do we know locks will be heavily contented? If I had to guess I'd > say most passes will not create o...

...that loop2_header_bb might need to be split before extracting loop 2 into its own function? I'm not sure yet about how to use bb splitting to enable inner-loop extraction and what splitting edges means. Sincerely, Iulian On Wednesday, July 1, 2020, 06:06:01 PM EDT, Johannes Doerfert <johannesdoerfert at gmail.com> wrote: Hi Iulian, On first thought I would think that extracting top-level loops is only minimally easier than extracting any other loop level, if you consider arbitrary input, e.g,. potential irreducible "outer-outer-most" loops. For inner ones you might...

...align 1, !noalias !3 **246008 %mem_base66 = load i8*, i8** %mem_base_addr_ptr, align 8, !alias.scope !3 246009 %offset167 = add i32 %call56, 12 246010 %13 = sext i32 %offset167 to i64 .... 382681 !3 = !{!3} 382682 !4 = !{!4} BR, Terry On Thu, Jul 23, 2020 at 11:43 PM Johannes Doerfert < johannesdoerfert at gmail.com> wrote: > Hi Terry, > > > various LLVM passes that run with O3 would do this for you, assuming > they could prove correctness. > > FWIW, the address is the same, so it is (most likely) an aliasing > problem. I assume > > store i64 0, i64* %data_ptr6...

...ucturing this problem well and doing meaningful work over the summer might be a bit difficult. As mentors, do you have any thoughts on how LLVM might be integrated into a joint CPU-GPU compiler by the likes of Nvidia, Apple etc.? Best Shiva On Mon, Mar 30, 2020 at 5:30 PM Johannes Doerfert < johannesdoerfert at gmail.com> wrote: > > On 3/27/20 3:46 PM, Shiva Stanford wrote: > > Hi Johannes - great we are engaging on this. > > > > Some responses now and some later. > > > > 1. When you say setup LLVM dev environment +. clang + tools etc, do you > > mean setup...

> On Nov 6, 2020, at 17:32, Johannes Doerfert <johannesdoerfert at gmail.com> wrote: > > Cool! I really like the idea. I left a comment about metadata preservation below. > Once this is available we will certainly employ it to understand OpenMP programs better. That sounds like a great use case! Having multiple different uses cases during the brin...

...orr Bremse Technology Center India Survey No.276, Village Mann, Hinjewadi, Phase II, Tal.Mulshi, Pune - 411 057. Maharashtra , India. Phone: +91 9028098122 Mobile: mailto:minal.kulkarni at knorr-bremse.com http://www.knorr-bremse.com<http://www.knorr-bremse.com/> From: Johannes Doerfert <johannesdoerfert at gmail.com> Sent: Thursday, May 28, 2020 10:20 PM To: Kulkarni, Minal <Minal.Kulkarni at knorr-bremse.com>; llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] LLVM Support needed I don't think we have a Tricore backend, at least not public in mainline LLVM. I might be wrong though...

Hi Suresh, thanks for reporting this! I thought I fixed this with 8d94d3c3b44c3a27a69b153cef9be4b8e481150e. Did you run before or after that commit? Cheers, Johannes On 5/15/20 7:17 AM, Mani, Suresh via llvm-dev wrote: > [AMD Public Use] > > Hi , > > Please ignore the earlier header of Internal and Official use only. > > Thanks > M Suresh > > From: llvm-dev

...g. > > Note that the bots are doing `ninja` first followed by `ninja check-mlir`: > they likely build much more than they need: the build could be faster by > avoiding the first step. > > -- > Mehdi > > > > On Fri, Jul 31, 2020 at 9:05 AM Johannes Doerfert < > johannesdoerfert at gmail.com> wrote: > >> Hi, >> >> >> I broke the MLIR build yesterday and the two Flang bots told me about it >> pretty much right away. Yay! >> That is how I always thought the setup should work (modulo that we all >> try not to break builds). >...

Hi Nicolai and Hal, I was wondering if your present concerns regarding the directions of the proposed attributes and semantics of the current direction had been addressed, so I thought I'd send over a friendly ping. Have they? Atmn On Wed, Sep 9, 2020 at 1:08 AM Johannes Doerfert <johannesdoerfert at gmail.com> wrote: > > > On 9/8/20 9:08 PM, Hal Finkel wrote: > > There is another thing that I would like for us to document: do > > infinite loops have any relationship to thread synchronization? As I > > recall, this issue came up in the past when we discussed...

...itter's email by other means. Louis > > On 3/3/20, 1:44 PM, "llvm-dev on behalf of Louis Dionne via llvm-dev" <llvm-dev-bounces at lists.llvm.org on behalf of llvm-dev at lists.llvm.org> wrote: > > > >> On Feb 20, 2020, at 14:25, Johannes Doerfert <johannesdoerfert at gmail.com> wrote: >> >> On 02/20, Louis Dionne via llvm-dev wrote: >>> I know there has been significant discussion about "moving" from >>> Phabricator to GitHub reviews and pull requests, etc. I'm not >>> suggesting that we do anything in...