similar to: LLVM projects and monorepo.

> On Nov 15, 2019, at 1:52 AM, Alex Denisov <1101.debian at gmail.com> wrote: > >> I think I can just get the patch and remove the `llvm` on top of the paths, but that’s not a scalable approach. > > IIRC, the -p option of 'patch' is exactly for doing this. Would that simplify your use-case? > Yes, for a single patch that would work. If there is a way to do

On Sun, May 7, 2017 at 12:07 AM, NAKAMURA Takumi via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I have done just now. 5 repos added including debuginfo-tests. > ATM, it includes 17 repos total. > > - Created the new repo; https://github.com/llvm- > project/llvm-project-20170507.git > Branches will come later. > - The previous repository has a merge commit that

Now that we’re on the Git monorepo, is there an updated script for cherry-picking commits into the release branch? llvm/utils/release/merge.sh appears to still use SVN, and llvm/utils/release/merge-git.sh uses git-svn. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200116/5c791bd2/attachment.html>

On 01/15/2020 05:03 PM, Reid Kleckner via llvm-dev wrote: > Tom Stellard told me to use `git cherry-pick -x`, and if you look at the release branches, you can see it is used, although the old style is used as well. I'm not sure what script is being used there. > I recommend updating the merge.sh script to use `git cherry-pick -x` and then deleting the merge-git.sh script. -Tom >

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

@Xinmin, Saito: If Clang/the frontend generates the version there is no problem, or is there? The frontend knows about the original source type and it's ABI specific lowering already. @Francesco, we should even consider putting the generating capabilities outside of the OpenMP code generation (in the future). That could allow easier reuse by other frontends. Get Outlook for

>In all cases, the IR type of the parameters in `foo` is i64, therefore is not possible to distinguish what C type generated the signature of `foo`. Ouch. >I don’t know if this is going to be a problem for other architectures I haven't checked what IA-32/Intel64 should do for type 2, but I fully agree that this needs to be done properly according to the ABI. >Therefore, I would

>Thank you everybody for their input, and for your patience. This is proving harder than expected! :) Thank you for doing the hard part of the work. Hideki -----Original Message----- From: Francesco Petrogalli [mailto:Francesco.Petrogalli at arm.com] Sent: Monday, June 24, 2019 11:26 AM To: Saito, Hideki <hideki.saito at intel.com> Cc: Doerfert, Johannes <jdoerfert at anl.gov>;

On Mon, 3 Jun 2019 at 20:00, Francesco Petrogalli via cfe-dev < cfe-dev at lists.llvm.org> wrote: > Hi All, > > The original intend of this thread is to "Expose user provided vector > function for auto-vectorization.” > > I originally proposed to use OpenMP `declare variant` for the sake of > using something that is defined by a standard. The RFC itself is not

I have an RFC for first-class complex types in LLVM IR pending for some internal review. I hope to post it soon. That should help address this problem. Then the vector function signature generation could stay in LLVM, if I'm understanding the issue correctly. -David Francesco Petrogalli via llvm-dev <llvm-dev at lists.llvm.org> writes: > Hi all - I am

Yes, this is very similar, but only expressed in terms of clang attributes, which may have different spellings for clang, GCC, c++11 etc. I don't think GCC will implement this as pragma. They added simd attribute instead of pragma. Best regards, Alexey Bataev > 31 мая 2019 г., в 14:43, Francesco Petrogalli <Francesco.Petrogalli at arm.com> написал(а): > > > >> On

I agree with Simon. This looks good conceptually. I have minor implementation comments but that can wait till the code reviews. Sorry for the delay and thanks for working on this. Get Outlook for Android<https://aka.ms/ghei36> ________________________________ From: Simon Moll <moll at cs.uni-saarland.de> Sent: Monday, June 17, 2019 10:02:58 AM To: Francesco Petrogalli; LLVM

You can define clang specific attribute and later add GCC alias for it. Best regards, Alexey Bataev > 31 мая 2019 г., в 13:46, Francesco Petrogalli <Francesco.Petrogalli at arm.com> написал(а): > > > >> On May 31, 2019, at 12:38 PM, Alexey Bataev <a.bataev at hotmail.com> wrote: >> >> Francesco, there won't be any duplication. Most of the

> On Jun 24, 2019, at 10:53 AM, Tian, Xinmin <xinmin.tian at intel.com> wrote: > > To me, it is also an issue related to SIMD signature matching when the vectorizer kicks in. Losing info from FE to BE is not good in general. > Yes, we cannot loose such information. In particular, the three examples I reported are all generating i64 in the scalar function signature: // Type 1

For example, Type 2 case, scalar-foo used call by value while vector-foo used call by ref. The question Johannes is asking is whether we can decipher that after the fact, only by looking at the two function signatures, or need some more info (what kind, what's minimal)? I think we need to list up cases of interest, and for each vector ABI of interest, we need to work on the requirements and

Dear all, This RFC is a proposal to provide auto-vectorization functionality for user provided vector functions. The proposal is a modification of an RFC that I have sent out a couple of months ago, with the title `[RFC] Re-implementing -fveclib with OpenMP` (see http://lists.llvm.org/pipermail/llvm-dev/2018-December/128426.html). The previous RFC is to be considered abandoned. The original RFC

Hi Francesco, On 06/03, Francesco Petrogalli wrote: > > On Jun 3, 2019, at 1:43 PM, Andrea Bocci <andrea.bocci at cern.ch> wrote: > > as a candidate future user of the proposed extension, I think I like the simplified proposal better than the original RFC. > > > > The only part of the syntax that I would find not very much user-friendly is having to mangle the

Hi, is there a R function that order a matrix according to some criteria based on the rows(or cols) of that matrix? For example, let's say that my matrix S is composed by n rows S_1, S_2,.., S_n and that I compute some real value g_i=g(S_i) for each row. Then I want to order this set of g_i (from smaller to bigger) and order the correspondent row to the new position. Is it possible (apart

> What is a `"logically"-widened alwaysinline wrapper for the vector function`? Can you provide an example? Also, what is the `tricky processing` you are referring to that the vectorizer should care about? For the case mentioned earlier: float MyAdd(float* a, int b) { return *a + b; } __declspec(vector_variant(implements(MyAdd(float *a, int b)),

On 12 December 2016 at 16:49, Francesco Petrogalli <Francesco.Petrogalli at arm.com> wrote: > I am not sure I understand here. In my patch, all I am doing is “vector > symbol awareness generation”. There are no globals that are generated in > the final object file, it is just the TargetLibraryInfoImpl that is being > populated with the info needed by the vectorizer. The