similar to: Planned change to IR semantics: constant expressions never have undefined behavior

On Fri, Jun 14, 2019 at 6:58 PM Chris Lattner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Jun 14, 2019, at 3:24 PM, Eli Friedman via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > See https://reviews.llvm.org/D63036 >

On Fri, Jun 14, 2019 at 7:10 PM Chris Lattner <clattner at nondot.org> wrote: > > > On Jun 14, 2019, at 4:06 PM, Cameron McInally <cameron.mcinally at nyu.edu> > wrote: > > > > On Fri, Jun 14, 2019 at 6:58 PM Chris Lattner via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> >> On Jun 14, 2019, at 3:24 PM, Eli Friedman via

On 8/8/19 2:03 PM, Hal Finkel wrote: Hi, First, as a high-level note, you posted a link to a Google doc, and at the end of the Google doc, you have a list of questions that you'd like answered. In the future, please put the questions directly in the email. For one thing, more people will read your email than will open your Google doc. Second, having the questions in the email should allow a

All: There will be a BoF talk at the EuroLLVM conference regarding Numerics (FMF and module flags which control fp behavior and optimization). Even if you are not going to be in attendance, please reply to this thread as we are collecting open issues and ideas for future direction in all layers of LLVM for which optimizations are controlled by numerics flags. Please read over the numerics blog

> 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

Hi Micheal, Thanks for the blog post. Just like to point out few things that I thought is related to FP Numerics. LLVM could do some additional transformation with "sqrt" and "division" under fast math on X86 like 1/sqrt(x)* 1/sqrt(x) to 1/x. These are long latency instructions and could get benefit if enabled under unsafe math. Also are we considering doing such FP

Which optimization did you find unsafe? Thanks, --Serge ср, 21 авг. 2019 г. в 05:12, Cameron McInally <cameron.mcinally at nyu.edu>: > On Tue, Aug 20, 2019 at 1:02 PM Serge Pavlov via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi all, >> >> During the review of https://reviews.llvm.org/D65997 >>

Just spitballing... why not have a splat construct straight through LLVM? It would make the IR more readable, opposed to the insert+shuffle method. On Thu, Aug 29, 2019 at 19:06 Amara Emerson via llvm-dev < llvm-dev at lists.llvm.org> wrote: > +1 to a new node, we’d very likely do the same thing for GlobalISel and > move to a canonical spat representation for all targets. > >

"git remote get-url" is apparently fairly new, the old version is "git config remote.origin.url". Might be worth using that for compatibility. On Mon, Jul 29, 2019, 5:11 PM Stefan Gränitz <stefan.graenitz at gmail.com> wrote: > Hey Cam, it works for me on TOT (89fb9e8ce15). > > What does the failed command return for you? It should be: > > > git

Hi all, During the review of https://reviews.llvm.org/D65997 an issue was revealed, which relates to the decision of how compiler should represents constrained floating point operations. If a floating point operation requires rounding mode or exception behavior different from the default, it should be represented by constrained intrinsic (

llvm-project/llvm> git rev-parse --git-common-dir --git-common-dir llvm-project/llvm> On Fri, May 3, 2019 at 3:48 PM Craig Topper <craig.topper at gmail.com> wrote: > I might have seen this issue. What does "git rev-parse --git-common-dir" > return for you? > > ~Craig > > > On Fri, May 3, 2019 at 12:35 PM Cameron McInally via llvm-dev < > llvm-dev

Hi everyone, The WebAssembly backend recently had Bug 39448 <https://bugs.llvm.org/show_bug.cgi?id=39448> filed against it because NaN payloads in floating-point immediates are not preserved through compilation on 32-bit builds. I took a look and the corruption takes place when the immediates are converted from APFloats to be stored as native doubles in MCOperand. I assume this bug only

Hey, First time using LLVM's git repo. Does 'git llvm push' take a really long time to work? I've tried to push a couple of times now and receive a message like: <scrubbed> llvm-project/llvm> git llvm push Pushing 1 commit: 2159c44 Update PatternMatcher for FNeg Committed 2159c44 to svn. <scrubbed> llvm-project/llvm> The svn repo never seems to update

I've run update_llc_test_checks on a set of tests and am seeing some weird behavior. The CHECK lines appear directly after the function's first line, even if there are multiple arguments. E.g.: define <vscale x 4 x i32> @sel_nxv4i32(<vscale x 4 x i1> %p, ; CHECK-LABEL: sel_nxv4i32: ; CHECK: // %bb.0: ; CHECK-NEXT: mov z0.s, p0/m, z1.s ; CHECK-NEXT: ret

Hi, During the discussion on introducing scalable vectors we established that we could use the canonical IR form for splats of scalable vector types (insert element into lane 0 of an undef vector, shuffle that with another undef vector of the same type and a zeroinitializer mask). We do run into a problem for lowering to SelectionDAG however, since the canonical form there is a BUILD_VECTOR with

All: There will be a BoF talk at the EuroLLVM conference regarding Numerics (FMF and module flags which control fp behavior and optimization). Even if you are not going to be in attendance, please reply to this thread as we are collecting open issues and ideas for future direction in all layers of LLVM for which optimizations are controlled by numerics flags. Please read over the numerics blog

About ftrapping-math: I think we should eliminate ftrapping-math, a boolean option, because it overlaps with ffp-exception-behavior, a 3 valued option. Or we can keep it in the clang driver for compatibility, but it should be rewritten by clang driver into ffp-exception-behavior=ignore and ffp-exception-behavior=strict. There are various fields in llvm and/or clang that maintain Boolean

vecremainder/novecremainder: Should the pragma simply call the vectorizer to attempt to vectorize the remainder loop, or should the vectorizer use a different method? > > Something like that. There were patches posted at some point to enable tail-loop vectorization. At this point, I imagine that you'd construct a VPlan with the vectorized tail. Yep, committed in

On Thu, Nov 8, 2018 at 11:35 PM Fabian Giesen via llvm-dev < llvm-dev at lists.llvm.org> wrote: > What is so complicated about these? Shouldn't they just correspond to > two compares + selects? > > To give a concrete example, x86 MIN[SP][SD] and MAX[SP][SD], > respectively, correspond exactly to > > MIN*: select(a < b, a, b) (i.e. "a < b ? a : b")

Hi Craig: I tried that, now the function is like this: ; Function Attrs: norecurse nounwind readnone ssp uwtable define { double, double } @add(double, double, double, double) local_unnamed_addr #0 {   %5 = call double @llvm.experimental.constrained.fadd(double %0, double %2, metadata !"round.downward", metadata !"fpexcept.ignore")   %6 = fadd double %1, %3