similar to: [RFC] change .gitignore for monorepo

James, we are using an *unmodified* llvm-project (master llorg), and just add some extra projects from our internal repos to the top-level. Thanks, Slava From: James Y Knight [mailto:jyknight at google.com] Sent: Wednesday, July 17, 2019 11:19 AM To: Zakharin, Vyacheslav P <vyacheslav.p.zakharin at intel.com> Cc: llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] [RFC]

Hi, mustPreserveAnalysisID(LCSSAID) cannot be used with the new pass manager, so what is the right way for querying it? FunctionAnalysisManager::getCachedResult<LCSSAPass>(F) will not work, since LCSSAPass does not have a result. Moreover, it is not an analysis :) Thanks, Slava -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi Cameron, Thank you for the comments, but I am confused even more now ☺ > llvm.rint won't honor the FPEnv in all cases. It falls under the default FPEnv The default FPEnv section specifies round-to-nearest rounding mode. In this case, how is it correct to map rint() user call to llvm.rint intrinsic call? If this is just a temporary inconsistency, and the long term solution is to map

Hello, I believe llvm.rint description in LangRef is not quite complete. Llvm seems to map math.h:rint() call to llvm.rint intrinsic, and the LangRef says that the result of llvm.rint matches the result of libm rint() call. Next, LangRef states that llvm.rint "returns the operand rounded to the nearest integer." Shouldn't the specification also say that "the actual rounding

Hi, The llvm-project monorepo (https://github.com/llvm/llvm-project) is currently missing a top-level license file. It would be nice if there was one so that anyone unfamiliar with layout of the monorepo could find it right away. I have put up a patch that adds a LICENSE.txt file to the monorepo root: https://reviews.llvm.org/D64875. The file is copy of LICENSE.txt from the llvm/ directory. Are

If someone can manage it, it wouldn't be a bad thing - obviously open up more parallelism (I don't know how much of LLVM can be built before you hit everything that needs tblgen run - I guess libSupport and some other bits) On Mon, Jul 1, 2019 at 12:54 PM Zakharin, Vyacheslav P via llvm-dev < llvm-dev at lists.llvm.org> wrote: > [resending to the whole list] > > > >

FWIW, tablegen does not update timestamps for .inc files, if their contents is unchanged, so if you somehow affect a .td file's timestamp (without changing its contents) it will trigger rebuild of the corresponding .inc file with all subsequent incremental make builds. At the same time, this will not trigger rebuilding any targets dependent on this .inc file, since it is not modified. From

Much of this has been discussed (over many, many years) on https://bugs.llvm.org/show_bug.cgi?id=28222 Some of the issues that were identified included: 1 - Poor tablegen dependency handling leading to unexpected rebuilds. 2 - Debug STL iterator checks taking an insane amount of time (might be MSVC specific). 3 - Lack of parallelization of custom commands (XCode and VS builds) - VS at least

I recently ran into the following problem. I'm prototyping a compiler for a dynamically typed language in which functions are first class objects. Assuming I have something like this: if(rand() > 5) i = define(x, y, z) { return x + y + z; } else i = define(x, y) { return x + y; } At this point I cannot know the type of 'i' at compile time. At runtime 'i' is a

On Thu, 2005-21-04 at 09:31 -0400, Vyacheslav Akhmechet wrote: > At this point I cannot know the type of 'i' at compile time. At > runtime 'i' is a structure that contains a type and a function > pointer. What I can't figure out is how to cast my llvm function > pointer to an appropriate function type. I cannot know until runtime > what the type will be.

The monorepo prototype at https://github.com/llvm-project/llvm-project-20170507 is currently 9 hours behind. I forget who’s responsible for the script(s) updating the monorepo(s), and it would be great if we can inform them of the state of the monorepo. Cheers -- Dean

Hello, I am trying to access https://git.llvm.org/git/llvm to be able to cherry pick some of the recent commits I did in the monorepo into our downstream llvm-only repository. The host seems defunct, is this part of the move to the monorepo? I think I can just get the patch and remove the `llvm` on top of the paths, but that’s not a scalable approach. Francesco

Mehdi AMINI <joker.eph at gmail.com> writes: > > If you want a monorepo view for all of your branches' histories > > too it's more involved, but I'm not sure anyone really needs > > that. In any case, even if someone does want that the nature of > > the zipper approach means it could be done later > > non-destructively. >

Mehdi AMINI <joker.eph at gmail.com> writes: > Yes, but that's the case for the zipper repo anyway: one merge per > commit. The point is that the second commit is just a trivial merge, > it wouldn't show up in a file `git log` for example. > In the linear rewritten monorepo, adding the history taken from the > existing git mirror would lead to duplicated commits, as

Justin Bogner via llvm-dev <llvm-dev at lists.llvm.org> writes: > The layout here is not at all different, only the process by which the > repo is generated. I strongly believe that a history preserving > conversion is very important if we want to avoid making porting > out-of-tree work horribly disruptive. How would an out-of-tree branch be ported with this new approach? Do

https://reviews.llvm.org/rL353906 introduced (presumably accidentally) the "b" top-level directory to the monorepo. The files should be moved to their proper location, but I'm also wondering if there's any way to prevent accidental top-level additions like this. Thanks, Shoaib -------------- next part -------------- An HTML attachment was scrubbed... URL:

Justin Bogner <mail at justinbogner.com> writes: > I'll write up some more detailed docs on this, but all you need to do is > a subtree merge to one of the zippered commits. This will then prevent git-biisect from working properly, unfortunately. Maybe most people don't need it be we should be aware of and communicate the tradeoffs. > If you want a monorepo view for all

Hello, I was wondering what was the current expected practice for committing patches to LLVM now that the Git monorepo is here. I have commit access to SVN but when I try to land my patched through GitHub I get an error saying "Permission to llvm/llvm-project.git denied". Depending on the answer, the documentation might need to be slightly clarified: the getting started documents for

--- .gitignore | 11 +++++++++++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/.gitignore b/.gitignore index 147e1cb..dcea811 100644 --- a/.gitignore +++ b/.gitignore @@ -154,10 +154,21 @@ po/POTFILES po/remove-potcdate.sed po/stamp-it po/stamp-po +po/LINGUAS +po/Makefile.in.in +po/Makevars +po/Rules-quot +po/boldquot.sed +po/en at boldquot.header +po/en at quot.header

--- .gitignore | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/.gitignore b/.gitignore index a6caaf9..ae3b16d 100644 --- a/.gitignore +++ b/.gitignore @@ -45,6 +45,7 @@ daemon/install-sh daemon/missing daemon/names.c daemon/stubs.c +daemon/m4/stddef_h.m4 depcomp .deps df/virt-df.1 @@ -114,6 +115,7 @@ libtool *.lo localconfigure ltmain.sh +m4/gnulib-cache.m4