search for: bocci

...t; Cc: Saito, Hideki <hideki.saito at intel.com>; Simon Moll <moll at cs.uni-saarland.de>; LLVM Development List <llvm-dev at lists.llvm.org>; Clang Dev <cfe-dev at lists.llvm.org>; Renato Golin <rengolin at gmail.com>; Finkel, Hal J. <hfinkel at anl.gov>; Andrea Bocci <andrea.bocci at cern.ch>; Elovikov, Andrei <andrei.elovikov at intel.com>; Alexey Bataev <a.bataev at hotmail.com>; nd <nd at arm.com>; Roman Lebedev <lebedev.ri at gmail.com>; Philip Reames <listmail at philipreames.com>; Shawn Landden <slandden at gmail.com...

> 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

...t;https://aka.ms/ghei36> ________________________________ From: Tian, Xinmin <xinmin.tian at intel.com> Sent: Monday, June 24, 2019 5:28:45 PM To: Saito, Hideki; Francesco Petrogalli; Doerfert, Johannes Cc: Simon Moll; LLVM Development List; Clang Dev; Renato Golin; Finkel, Hal J.; Andrea Bocci; Elovikov, Andrei; Alexey Bataev; nd; Roman Lebedev; Philip Reames; Shawn Landden Subject: RE: RFC: Interface user provided vector functions with the vectorizer. >>>>I don’t know if this is going to be a problem for other architectures ++++++I haven't checked what IA-32/Intel64 sh...

...gov>; Tian, Xinmin <xinmin.tian at intel.com>; Simon Moll <moll at cs.uni-saarland.de>; LLVM Development List <llvm-dev at lists.llvm.org>; Clang Dev <cfe-dev at lists.llvm.org>; Renato Golin <rengolin at gmail.com>; Finkel, Hal J. <hfinkel at anl.gov>; Andrea Bocci <andrea.bocci at cern.ch>; Elovikov, Andrei <andrei.elovikov at intel.com>; Alexey Bataev <a.bataev at hotmail.com>; nd <nd at arm.com>; Roman Lebedev <lebedev.ri at gmail.com>; Philip Reames <listmail at philipreames.com>; Shawn Landden <slandden at gmail.com...

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 isa/mask...

...To: Doerfert, Johannes <jdoerfert at anl.gov> Cc: Simon Moll <moll at cs.uni-saarland.de>; LLVM Development List <llvm-dev at lists.llvm.org>; Clang Dev <cfe-dev at lists.llvm.org>; Renato Golin <rengolin at gmail.com>; Finkel, Hal J. <hfinkel at anl.gov>; Andrea Bocci <andrea.bocci at cern.ch>; Elovikov, Andrei <andrei.elovikov at intel.com>; Alexey Bataev <a.bataev at hotmail.com>; Saito, Hideki <hideki.saito at intel.com>; Tian, Xinmin <xinmin.tian at intel.com>; nd <nd at arm.com>; Roman Lebedev <lebedev.ri at gmail.com&...

...m, but I went through the R FAQ, "Writing R Extensions" and R-devel but was not able to sort this problem out (so, please ignore this post if you find it OT). I hope the question is not too messy (this is my first time on R-devel). Many thanks for any help you may provide, Gionata Bocci. [[alternative HTML version deleted]]

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

Dear List, I've realized that the "CRAN Checking Package" system returns some Warnings for my package TR8 under "r-release-osx-x86_64-mavericks"; all the warnings include the following message "Invalid MIT-MAGIC-COOKIE-1 key" which I find a little cryptic. After some web searches, I understood that "MIT-MAGIC-COOKIE" is related to the X server and

On Thu, 21 Mar 2019 at 16:34, Artem Dergachev via cfe-dev < cfe-dev at lists.llvm.org> wrote: > If you're doing merge commits, you might lose linear history, but you > obtain another fancy invariant: every piece of work - i.e., every patch, > every merge conflict resolution - appears in the repository exactly > once, under a unique identifier, and the non-linear source

...uartz is outdated. Unfortunately there is no easy way anymore to check on Mavericks. Travis used to support it, but they have deprecated mavericks (along with Apple and homebrew). Hopefully CRAN will update to the current MacOS for the next release of R. On Fri, Dec 9, 2016 at 3:56 PM, Gionata Bocci <boccigionata at gmail.com> wrote: > > Dear List, > > I've realized that the "CRAN Checking Package" system returns some > Warnings for my package TR8 under "r-release-osx-x86_64-mavericks"; all the > warnings include the following message "Inv...

...r working on this. >> >> Get Outlook for Android >> >> From: Simon Moll <moll at cs.uni-saarland.de> >> Sent: Monday, June 17, 2019 10:02:58 AM >> To: Francesco Petrogalli; LLVM Development List; Clang Dev >> Cc: Renato Golin; Finkel, Hal J.; Andrea Bocci; Elovikov, Andrei; > Alexey Bataev; Doerfert, Johannes; Saito, Hideki; Tian, Xinmin; nd; > Roman Lebedev; Philip Reames; Shawn Landden >> Subject: Re: RFC: Interface user provided vector functions with the vectorizer. >> >> Hi Francesco, >> >> On 6/11/19 10:55...

...or 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 Development List; Clang Dev Cc: Renato Golin; Finkel, Hal J.; Andrea Bocci; Elovikov, Andrei; Alexey Bataev; Doerfert, Johannes; Saito, Hideki; Tian, Xinmin; nd; Roman Lebedev; Philip Reames; Shawn Landden Subject: Re: RFC: Interface user provided vector functions with the vectorizer. Hi Francesco, On 6/11/19 10:55 PM, Francesco Petrogalli wrote: > Dear all, > &gt...

If I am not mistaken, there are two things that are becoming clear: 1. For email, nobody seems to be against Discourse as long as the mailing lists are still a supported way to participate. So this seems non-controversial. 2. For IRC, people seem to be happy with switching to a more modern solution, but Discord is largely disliked by a significant portion of respondents. So perhaps we can focus

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 about fully implementing the `declare variant` directive. In fact, given the amount of complication it is bringing, I would like to move the

Dear all, I have re-written the proposal for interfacing user provided vector functions, originally posted in both llvm-dev and cfe-dev mailing list: "[RFC] Expose user provided vector function for auto-vectorization." The proposal looks quite different from the original submission, therefore I took the liberty to start a new thread. The original thread generated some good

Simple suggestion from an OpenSSH user to the guys who package and make available the RPMs for Portable OpenSSH: why don't you also add a YUM (RPM) headers to the ftp/http distributions ? If any help/manpower is needed, I volunteer :-) .Andrea. PS. Please cc: me, I'm not on the list. -- fwyzard at member.fsf.org Free Software Foundation Associate Member