similar to: [RFC] Expose user provided vector function for auto-vectorization.

> 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)),

Hi Francesco, > I am crafting the attribute so that it makes it explicit that we are using OpenMP and we are expecting a Vector Function ABI. I just thought that another option would be to force FE to always emit "logically"-widened alwaysinline wrapper for the vector function that does the arguments processing according to ABI inside (we need that info in the FE anyway). That way

>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>;

>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

@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

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

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

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

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

> 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

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

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

On 5/16/2017 6:30 AM, Sanjay Patel wrote: > Thanks for posting this question, Julia. > > I had a similar question about a signed min/max variant here: > http://lists.llvm.org/pipermail/llvm-dev/2016-November/106868.html > > The 2nd version in each case contains a canonical max/min > representation in IR, and this could enable more IR analysis. > A secondary advantage is

Hi Peter, Thanks for the reply. I agree that the base class vtable may be not referenced by a derived class. However, the vtable of a derived class has to reference its parent type_info, and so having type_info internalized means that the class is final, doesn’t it? Thanks, Nikolai From: Peter Collingbourne [mailto:peter at pcc.me.uk] Sent: Wednesday, December 6, 2017 4:36 AM To: Gainullin,

Hello, I am new to LLVM and I am not sure whether I am writing to the right distribution list or not. Please let me know if this is not the right distribution list. Question: - I am having hard time lowering ADD instructions for different purposes. Basically, I want to have different machine instruction for pointer addition vs scalar addition. I am having hard time mapping LLVM add to my machine

Hi, all I didn't get any response from swig for my question. see if I can get some help here Thanks ---------- Forwarded message ---------- From: charlie <charlie.xia.fdu@gmail.com> Date: Tue, Nov 4, 2008 at 1:55 PM Subject: SWIG with R and C++ STL To: swig-user@lists.sourceforge.net Hi all, I am new to SWIG. I encountered some problem when I try to SWIG to R some C++ modules. Here

Maybe you need to subscribe to that folders? On 4/25/20 3:07 PM, Andrei Petru Mura wrote: > Rectification: For example, created a_folder would be found on server > under Maildir/cur/.b_dir. > would be: > For example, created a_folder would be found on server under > Maildir/cur/.a_folder. > > On Sat, Apr 25, 2020 at 2:45 PM Andrei Petru Mura <mapandrei at gmail.com >

Hi Aki, Thanks. I was especially interested in documentation related to dovecot and it's users permissions, the way in which dovecot uses users. Till now I found only spread information on different articles from dovecot's website. Thanks, Mura Andrei On Sat, Apr 11, 2020 at 9:49 AM Aki Tuomi <aki.tuomi at open-xchange.com> wrote: > Hi, > > >

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 Aki, Any documentation on this topic? Mura Andrei On Mon, Apr 6, 2020 at 5:27 PM Aki Tuomi <aki.tuomi at open-xchange.com> wrote: > This is probably caused by systemd (or selinux or both). > > With systemd, you need to add > > ReadWritePaths=/home/mail > > to the systemd unit. > > Then you can check /var/log/audit/audit.log for any selinux specific >