search for: rscottmanley

...g the fast flag or not. I disagree. How does clang know what would ultimately form an FMA? It would have to blanket remove 'fast' from all fadds. On Wed, Jul 10, 2019 at 4:16 PM Matt Arsenault <arsenm2 at gmail.com> wrote: > > > On Jul 10, 2019, at 16:56, Scott Manley <rscottmanley at gmail.com> wrote: > > At any rate, I was only offering an additional reason. Personally I think > it's strange for an option to say "this will never fuse ops" and then under > the covers will fuse ops, regardless of how FMAD is defined. However, my > primary conce...

...ould ultimately form an FMA? It > would have to blanket remove 'fast' from all fadds. > > > >> > >> On Wed, Jul 10, 2019 at 4:16 PM Matt Arsenault <arsenm2 at gmail.com> > wrote: > >> > >>> On Jul 10, 2019, at 16:56, Scott Manley <rscottmanley at gmail.com> > wrote: > >>> > >>> At any rate, I was only offering an additional reason. Personally I > think it's strange for an option to say "this will never fuse ops" and then > under the covers will fuse ops, regardless of how FMAD is defined....

> That's not typically something we'd expose to the end user in any way. > Clang as a compiler should be selecting what it thinks is the fastest > sequence to do some particular job; if it's wrong then that's a bug, > not something to add a command-line flag for. I can't agree with that as a general statement. How is it any different than giving the user the

I am looking for feedback to add support for a new loop pragma to Clang/LLVM. With "#pragma tail_predicate" the idea would be to indicate that a loop epilogue/tail can, or should be, folded into the main loop. I see two use cases for this pragma. First, this could be interesting for the vectorizer. It currently supports tail folding by masking all loop instructions/blocks, but does this

Intel would like to contribute a patch to implement support for these Intel- and Microsoft -fp options. This message is to describe the options and request feedback from the community. -fp-model=[precise|strict|fast|except[-]] and -fp-speculation=[fast|strict|safe] This contribution would dovetail with the llvm patch "Teach the IRBuilder about constrained fadd and friends" which is

> There is a fundamental problem with the way that ivdep is defined by Intel's current documentation, at least for C/C++. As you note in your Google doc, it essentially says that the optimizer may ignore loop-carried dependencies except for those dependencies it can definitely prove are present. These are not semantics that any other compiler can actually replicate, and is not equivalent to

On 4/16/19 4:18 PM, Amara Emerson wrote: On Apr 16, 2019, at 1:47 PM, Kaylor, Andrew via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Thanks, Hal. I hear what you are saying about the accuracy. The problem, from my perspective, is trying to explain to users what they are going to get. The constant folding may be as accurate as the lib call would