search for: neuendorffer

...pdate! This will fix the ugliest hack I have on my build script. I know I wasn't doing the nicest thing, but it's nice to see that what I needed wasn't that far away. I'll update my scripts and get back to you. Really appreciate, thanks! Renato On Fri, 10 Jul 2020, 07:59 Stephen Neuendorffer, < stephen.neuendorffer at gmail.com> wrote: > Renato, > > After looking at your testcase, it seems that you're trying to relocate a > 'build' directory and are having to rewrite absolute paths in the build > directory. > Build directories are not really relocat...

...s still early and we see many elements as highly experimental. At the same time, we feel that the only way to vet these ideas is to build larger systems which will likely take some time and community investment. The LLVM incubator process would be a good way to help us organize this effort. Steve Neuendorffer Xilinx Research Labs -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200704/d7292b25/attachment.html>

Renato, I'm happy to kibitz on the build problems. Cmake seems to be working well at this point for us, but it took quite a bit to get there and there are some pitfalls. I'm aware of some namespace issues in mlir, but haven't gotten around to dealing with them. Steve On Thu, Jul 9, 2020, 3:47 AM Renato Golin <rengolin at gmail.com> wrote: > On Wed, 8 Jul 2020 at 22:43,

...d fails to configure. Then they go fetch a new CMake. Not sure a bootstrap script really helps with that. Especially since the CMake git repository contains one, and many people might prefer to grab a binary distribution rather than build their own. -Chris > On Nov 4, 2019, at 9:29 AM, Stephen Neuendorffer <stephen.neuendorffer at gmail.com> wrote: > > Maybe a bootstrap.sh? I understand that it can get a little tricky, but even if it only worked 95% of the time it might be enough to lower the barrier to entry. > > Steve > > On Mon, Nov 4, 2019 at 9:16 AM Chris Bieneman &lt...

...ns with the new guidelines set out in that document. > As you know, I’m personally very much in favor of this project landing, but > am also have a conflict of interest, so I’d like to know what other > community members think. > > -Chris > > On Jul 4, 2020, at 3:29 PM, Stephen Neuendorffer via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > For the past several months, members of the ‘CIRCT’ group have been > working to begin adapting MLIR for hardware design. We believe that this > area would benefit from good open source infrastructure enabling resear...

These errors seem pretty pervasive for me on a clean build. It appears that it arises because when tablegen'd headers are included in a .h file, every place where that .h file is used needs a dependency on the corresponding IncGen targets. This seems broken in the short term and unmaintainable in the long term. There really needs to be a way of automatically generating the right

CMake doesn’t have the ability to reliably re-invoke itself in a way that would make that workflow reasonable. To do it would require a meta build system for our meta build system, and that is the road to madness. -Chris > On Nov 4, 2019, at 8:59 AM, Stephen Neuendorffer via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >  > > Since it's 'so easy', I wonder if it would make people's lives easier to add a bootstrap of cmake to the out of the box build flow. > Maybe: "You're system Cmake is too old for us. Downloadin...

...t; wrote: > Is there any observable difference between "Squash and Merge" or "Rebase > and Merge" when "enforce linear history" is enabled, then? > "Squash and Merge" will only generate one commit. > > On Fri, Sep 11, 2020 at 3:45 PM Stephen Neuendorffer via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Just to clarify: All the LLVM incubator repositories have "enforce linear >> history" enabled. Neither "Squash and Merge" or "Rebase and Merge" results >> in a Merge commit in the g...

Just to clarify: All the LLVM incubator repositories have "enforce linear history" enabled. Neither "Squash and Merge" or "Rebase and Merge" results in a Merge commit in the git history. Steve On Fri, Sep 11, 2020 at 3:32 PM Hubert Tong < hubert.reinterpretcast at gmail.com> wrote: > On Fri, Sep 11, 2020 at 6:12 PM Renato Golin <rengolin at

...to set it to batch mode, if someone tells me where to configure it :) > > Otherwise we could also upgrade the machine from 16 to 32 cores, if you > would like to get more build results. Or do both... > > > Best, > Christian > > > On Sat, Aug 1, 2020 at 1:05 AM Stephen Neuendorffer via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> +1 for batching. In practice it's probably more important that things >> get run for every MLIR checkin, and not necessarily for every LLVM checkin. >> >> Steve >> >> >> On Fri, Jul 3...

...ve an external MLIR user in the project, and > this project seems really well organised and relevant. +1 from me, > too. I think that flang beat us to the punch as the first external MLIR user :-) but thank you for your support Renato! -Chris > > On Sat, 4 Jul 2020 at 23:30, Stephen Neuendorffer via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> >> >> For the past several months, members of the ‘CIRCT’ group have been working to begin adapting MLIR for hardware design. We believe that this area would benefit from good open source infrastructure enabling res...

If fptosi takes 0.9 -> 0, then that is not 'rounding' in any sense I'm aware of (IEEE754 or otherwise). Rounding (in the IEE754 sense) determines how a number is converted when it is halfway between two candidate results. (see round(), ceil(), floor()). fptosi seems to model the behavior of a C cast from float to int, which truncates the fractional bits (as in trunc()). Steve

...tHub's inferior tooling here wouldn't be quite as much of a problem, > but it just isn't -- and I don't think hurrying up the process at the > expense of quality is quite the right answer, either. > > Cheers, > Nicolai > > On Fri, Sep 11, 2020 at 7:39 PM Stephen Neuendorffer > <stephen.neuendorffer at gmail.com> wrote: > > The LLVM incubator projects have been using github PRs for reviews and > so far haven't really seen any significant issues. The biggest confusion > so far has not been with reviews but with the difference between "rebas...

...s much of a problem, >>> but it just isn't -- and I don't think hurrying up the process at the >>> expense of quality is quite the right answer, either. >>> >>> Cheers, >>> Nicolai >>> >>> On Fri, Sep 11, 2020 at 7:39 PM Stephen Neuendorffer >>> <stephen.neuendorffer at gmail.com> wrote: >>> > The LLVM incubator projects have been using github PRs for reviews and >>> so far haven't really seen any significant issues. The biggest confusion >>> so far has not been with reviews but with th...

+1 for batching. In practice it's probably more important that things get run for every MLIR checkin, and not necessarily for every LLVM checkin. Steve On Fri, Jul 31, 2020 at 9:26 AM Mehdi AMINI via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Indeed there is quite a backlog here right now: > http://lab.llvm.org:8011/builders/mlir-windows and here >

The LLVM incubator projects have been using github PRs for reviews and so far haven't really seen any significant issues. The biggest confusion so far has not been with reviews but with the difference between "rebase and merge" and "squash and mere". We have used basically 3 different processes: Method 1: start a review with one commit on a new branch (typically in a

> On Sep 24, 2020, at 23:52, Petr Hosek <phosek at chromium.org> wrote: > > Using more interface libraries is definitely the right direction and a modern way to use CMake. I'm not sure if we can get to a single interface target since different runtimes have different requirements. I was assuming that we would have one interface target per dependency and use the existing CMake

On Sun, Nov 3, 2019 at 7:20 PM Neil Nelson via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Glad we are getting some reasonable justifications for CMake 3.15.0. There > are two points we may be missing. > > Is our plan to just keep updating to the most recent CMake version or will > our objectives be reached with this version? If we gain what we need with > this version

I'll comment from the perspective of someone that is in the Mesa, #dri-devel, #radeon channels myself and have watched their behaviour over the years. This is a real person that spams a load of information into a channel about their understanding of how hardware works. I have no idea what their goal is for spamming this information, could be some desire for acceptance from perceived smartness.

Hi all, Today, we maintain a high bar for getting a new subproject into LLVM: first a subproject has to be built far enough along to “prove its worth” to be part of the LLVM monorepo (e.g. demonstrate community, etc). Once conceptually approved, it needs to follow all of the policies and practices expected by an LLVM subproject. This is problematic for a couple reasons: it implicitly means that