search for: temirbulatov

On 09/26/2017 08:31 AM, Dinar Temirbulatov wrote: > Hi Hal, >> 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? > no, I don't have any concerns about intrinsic way of implementation, > and in...

...PR21780, I don't need to use aggregate so it is set to null, but for other similar issues this aggregate parameter might be useful. Thanks, Dinar. On Tue, Sep 26, 2017 at 5:52 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > On 09/13/2017 04:46 PM, Dinar Temirbulatov via llvm-dev wrote: >> >> Hi Michael, >>> >>> I have a case where InstCombine removes a store and your approach would >>> be >>> valuable for me if the entire access to an aggregate could be restored. >> >> Yes, no problem and we could add...

...t that it is > dereferenceable for the size of the access (otherwise it would be undefined > behavior). > Isn't that information sufficient for your use case? (sorry, didn't read > the whole thread carefully). > > Nuno > > -----Original Message----- > From: Dinar Temirbulatov via llvm-dev > Sent: Tuesday, July 18, 2017 7:36 PM > Subject: [llvm-dev] [RFC] dereferenceable metadata > > Hi, > While working on PR21780, I used "dereferenceable_or_null" metadata > and I realized now that it is not correct for my solution to use this > metadata ty...

On 09/13/2017 04:46 PM, Dinar Temirbulatov via llvm-dev wrote: > Hi Michael, >> I have a case where InstCombine removes a store and your approach would be >> valuable for me if the entire access to an aggregate could be restored. > Yes, no problem and we could add the aggregate pointer to this new > intrinsic and in my...

...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: Dinar Temirbulatov via llvm-dev [llvm-dev at lists.llvm.org] >>> Received: Dienstag, 12 Sep. 2017, 9:57 >>> To: llvm-dev at lists.llvm.org [llvm-dev at lists.llvm.org] >>> CC: Filipe Cabecinhas [me at filcab.net] >>> Subject: [llvm-dev] RFC phantom memory intrinsic >>> &gt...

Hi, We are interesting in expanding some vector operations directly in the IR form as constants https://reviews.llvm.org/D33406, for example: _mm256_cmp_ps("any input", "any input", _CMP_TRUE_UQ) should produce -1, -1, -1, ... vector, but for some values for example "1.00 -nan" if FPU exceptions were enabled this operation triggers the exception. Here is the question:

Hi, While working on PR21780, I used "dereferenceable_or_null" metadata and I realized now that it is not correct for my solution to use this metadata type since it might point to an address that it is not dereferenceable but null. I think that we need another new metadata type, something like "dereferenceable" with that we could annotate any load (not just pointer type like

Hi, For PR21780 solution, I plan to add a new functionality to restore memory operations that was once deleted, in this particular case it is the load operations that were deleted by InstCombine, please note that once the load was removed there is no way to restore it back and that prevents us from vectorizing the shuffle operation. There are probably more similar issues where this approach could

...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: Dinar Temirbulatov via llvm-dev [llvm-dev at lists.llvm.org] > Received: Dienstag, 12 Sep. 2017, 9:57 > To: llvm-dev at lists.llvm.org [llvm-dev at lists.llvm.org] > CC: Filipe Cabecinhas [me at filcab.net] > Subject: [llvm-dev] RFC phantom memory intrinsic > > Hi, > For PR21780 solution, I plan...

...mailing lists * Zachary Turner has sent a [heads-up](http://lists.llvm.org/pipermail/llvm-dev/2017-September/117418.html) about a slight change to the lit workflow. If you already use `./bin/llvm-lit` in the build dir rather than `utils/lit/lit.py` from source, you should see no changes. * Dinar Temirbulatov has posted an RFC on adding a ['phantom' memory intrinsic](http://lists.llvm.org/pipermail/llvm-dev/2017-September/117381.html). This would keep track of cases where load operations are removed by passes like InstCombine. * Kyle Butt has posted an RFC [implementing trace-based basic block...