search for: haidl

...son: > Actually for mask vectors of i1 values, you don't need to use reductions > at all(although for SVE this is what we'll do). You can instead bitcast > the vector value to an i8/i16/whatever and then compare against zero. > > Amara > > On 4 August 2017 at 14:55, Haidl, Michael via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > I am currently working on a transformation pass that transforms > masked.load and masked.store intrinsics to (hopefully) increase > performance on targe...

...to move to the intrinsic form as the > canonical representation. > > FYI one of the motivating reasons for these to be introduced was to > allow non power-of-2 vector architectures like SVE to express reduction > operations. > > Amara > > On 4 August 2017 at 13:36, Haidl, Michael <michael.haidl at uni-muenster.de > <mailto:michael.haidl at uni-muenster.de>> wrote: > > Hi Renato, > > just to make it clear, I didn't implement reductions on x86_64 they just > worked when I tried to lower an > llvm.experimentel.ve...

.... and both of these do as of: https://reviews.llvm.org/rL313631 ), then it's easy to observe the diffs by re-running that script after your code patch is applied: $ /path/to/update_llc_test_checks.py --llc=/path/to/local/and/new/llc lea-3.ll $ svn diff lea-3.ll On Tue, Sep 19, 2017 at 5:23 AM, Haidl, Michael via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: I am currently improving the D37896 to include the suggestions from Chad. However, running the lit checks for the x86 backend I observe some changes in the generated MC, e.g.: llvm/test/CodeGen...

...{ shows the same result. Michael On 22.09.2017 07:19, Craig Topper wrote: > Is VT a legal type on Hexagon? It looks like Hexagon may be setting SHL > as Custom for every defined vector type. Try adding TLI.isTypeLegal(VT) too. > > ~Craig > > On Thu, Sep 21, 2017 at 10:06 PM, Haidl, Michael > <michael.haidl at uni-muenster.de <mailto:michael.haidl at uni-muenster.de>> > wrote: > > Hi Sanjay, > > thanks for this information. I did get a little bit further with the > patch. However, Hexagon gives me headaches. > > I tr...

...per <craig.topper at gmail.com> wrote: > > Probably in visitMUL in DAGCombiner.cpp to be target independent. Or in LowerMUL in X86ISelLowering.cpp to be X86 specific. > > Adding Simon. Simon, which were you thinking? > > ~Craig > > On Wed, Sep 13, 2017 at 10:06 PM, Haidl, Michael <michael.haidl at uni-muenster.de <mailto:michael.haidl at uni-muenster.de>> wrote: > Hi Craig, > > thanks for digging into this. So InstCombine is the wrong place for > fixing PR34474. Can you give me a hint where such an optimization should > go into CodeGen?...

...gmail.com>> wrote: > > Your code seems fine. InstCombine can infinite loop if some > other transform is reversing your transform. Can you send the > whole patch and a test case? > > ~Craig > > On Wed, Sep 13, 2017 at 10:01 AM, Haidl, Michael via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Hi, > > I am working on PR34474 and try to add a new optimization to > InstCombine. Like in other parts of the visitMul fun...

Is VT a legal type on Hexagon? It looks like Hexagon may be setting SHL as Custom for every defined vector type. Try adding TLI.isTypeLegal(VT) too. ~Craig On Thu, Sep 21, 2017 at 10:06 PM, Haidl, Michael < michael.haidl at uni-muenster.de> wrote: > Hi Sanjay, > > thanks for this information. I did get a little bit further with the > patch. However, Hexagon gives me headaches. > > I tried to limit the scope of the patch to the BeforeLegalizeTypes phase > and Hexa...

...wrote: >> >> Probably in visitMUL in DAGCombiner.cpp to be target independent. Or >> in LowerMUL in X86ISelLowering.cpp to be X86 specific. >> >> Adding Simon. Simon, which were you thinking? >> >> ~Craig >> >> On Wed, Sep 13, 2017 at 10:06 PM, Haidl, Michael >> <michael.haidl at uni-muenster.de <mailto:michael.haidl at uni-muenster.de>> >> wrote: >> >> Hi Craig, >> >> thanks for digging into this. So InstCombine is the wrong place for >> fixing PR34474. Can you give me a hint...

> On Dec 6, 2017, at 02:28, Haidl, Michael <michael.haidl at uni-muenster.de> wrote: > > The IR goes through a backend agnostic preparation phase that brings it into SSA from and changes the AS from 0 to 1. This sounds possibly problematic to me. The IR should be created with the correct address space to begin with....

...ped with GPU in mind (e.g. range-v3) vs code that was? What restrictions do you apply? I assume virtual functions, recursion. What else? How does pacxx's SPMD model differ from what one can do in LLVM at the moment? Nic [1]: http://github.com/libmir/dcompute/ > On 5 Feb 2018, at 7:11 am, Haidl, Michael via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > HI LLVM comunity, > > after 3 years of development, various talks on LLVM-HPC and EuroLLVM and other scientific conferences I want to present my PhD research topic to the lists. > > The main goal for my resea...

...command line switch, C++ attributes, some diagnostics and metadata generation during code gen. The PACXX-RT can be integrated into the LLVM build system and may remain a standalone project. (BTW, may I ask to add PACXX to the LLVM projects?). Looking forward for your feedback. Cheers, Michael Haidl [1] https://github.com/cdl-saarland/rv [2] https://github.com/ericniebler/range-v3 [3] https://dl.acm.org/authorize?N20051 [4] https://github.com/pacxx/pacxx-llvm

...o problem and we could add the aggregate pointer to this new intrinsic and in my particular case I should ignore it, but I am looking now at "speculation_marker" metadata and I am still not sure how to implement it better. Thanks, Dinar. On Wed, Sep 13, 2017 at 3:23 PM, Haidl, Michael <michael.haidl at uni-muenster.de> wrote: > Hi Dinar, > > I am asking because I am maintaining an out-of-tree pass which does > exactly what SLP does not. It is a pass designed for GPUs to combine > loads and stores, e.g., when consecutive fields of a structure have th...

...rinsics with the AArch64 backend. Maybe I find the time to look into codegen to get this intrinsics out of experimental stage. They seem pretty useful. Cheers, Michael -----Original Message----- From: Amara Emerson [amara.emerson at gmail.com] Received: Donnerstag, 03 Aug. 2017, 14:50 To: michael.haidl at uni-muenster.de [michael.haidl at uni-muenster.de] CC: llvm-dev at lists.llvm.org [llvm-dev at lists.llvm.org] Subject: Re: [llvm-dev] Status of llvm.experimental.vector.reduce.* intrinsics ​Hi Michael, ​The intrinsics are still technically in an experimental state as we need to have a further...

.... and both of these do as of: https://reviews.llvm.org/rL313631 ), then it's easy to observe the diffs by re-running that script after your code patch is applied: $ /path/to/update_llc_test_checks.py --llc=/path/to/local/and/new/llc lea-3.ll $ svn diff lea-3.ll On Tue, Sep 19, 2017 at 5:23 AM, Haidl, Michael via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I am currently improving the D37896 to include the suggestions from > Chad. However, running the lit checks for the x86 backend I observe some > changes in the generated MC, e.g.: > > llvm/test/CodeGen/X86/lea-3.ll:1...

...to implement it better. Are you primarily concerned with being able to widen loads later in the pipeline? Could we attached metadata to the remaining loads indicating that it would be legal to widen them? -Hal > Thanks, Dinar. > > On Wed, Sep 13, 2017 at 3:23 PM, Haidl, Michael > <michael.haidl at uni-muenster.de> wrote: >> Hi Dinar, >> >> I am asking because I am maintaining an out-of-tree pass which does >> exactly what SLP does not. It is a pass designed for GPUs to combine >> loads and stores, e.g., when consecutive fiel...

Hi, I was wandering about the status of the llvm.experimental.vector.reduce.* intrinsics. Are all back-ends supporting those intrinsics or are they still in a very "experimental" state? Thanks, Michael

> On Dec 5, 2017, at 13:53, Matt Arsenault <arsenm2 at gmail.com> wrote: > > > >> On Dec 5, 2017, at 02:51, Haidl, Michael via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi dev list, >> >> I am currently exploring the integration of AMDGPU/ROCm into the PACXX project and observing some strange behavior of the AMDGPU backend. The...

...marily concerned with being able to widen loads later in the > pipeline? Could we attached metadata to the remaining loads indicating that > it would be legal to widen them? > > -Hal > > >> Thanks, Dinar. >> >> On Wed, Sep 13, 2017 at 3:23 PM, Haidl, Michael >> <michael.haidl at uni-muenster.de> wrote: >>> >>> Hi Dinar, >>> >>> I am asking because I am maintaining an out-of-tree pass which does >>> exactly what SLP does not. It is a pass designed for GPUs to combine >>> loads an...

...nit8 = insertelement <4 x double> %vecinit5, double %3, i32 3 %shuffle = shufflevector <4 x double> %vecinit8, <4 x double> %vecinit8, <4 x i32> <i32 3, i32 3, i32 2, i32 2> ret <4 x double> %shuffle } Thanks, Dinar. On Tue, Sep 12, 2017 at 8:26 PM, Haidl, Michael <michael.haidl at uni-muenster.de> wrote: > Interesting approach but how do you handle more complex offsets, e.g., when > the pointer is part of an aggregate? Only one offset does not seem enough to > handle generic cases. > > -----Original Message----- > From: Dina...

...ops after the DAG has been legalized. So that's another potential way to > limit the scope of the patch - don't try the transform unless we're > pre-legalization: >   if (Level < AfterLegalizeDAG) { // do something } > > > > On Wed, Sep 20, 2017 at 4:17 AM, Haidl, Michael > <michael.haidl at uni-muenster.de <mailto:michael.haidl at uni-muenster.de>> > wrote: > > Hi, > > I am currently working on a more or less intrusive patch (D37896), which > pulls optimizations on multiplications from some back-ends, e.g.,...