search for: sdagbuild

Hello all, The rich history of binary distribution formats based on LLVM [0][1][2][3][4] has proven LLVM's viability as a launchpad for stable platforms. However, issues with compilation time and compiler size have suggested that the translator must do too much, i.e. LLVM IR isn't a low-level enough virtual machine. So we introduce DAGIR ("dagger"), a new portable close to the

On April 25, 2014 at 10:48:18 AM, Reid Kleckner (rnk at google.com) wrote: On Fri, Apr 25, 2014 at 10:19 AM, Filip Pizlo <fpizlo at apple.com> wrote: The sdiv operation in LLVM IR only makes sense for C and its very direct relatives.  The amount of control flow necessary to represent a safe division for any other language is ghastly.  (a/b) becomes something like (b != 0 ? ((a != INT_MIN ||

Hal Finkel <hfinkel at anl.gov> wrote on 16.03.2015 17:56:20: > If you want to do it at a clang level, the right thing to do is to > fixup the ABI lowerings for pointers to keep them pointers in this case. > So this is an artifact of the way that we pass structures, and > constructing a general solution at the ABI level might be tricky. > I've cc'd Uli, who did most

...ng issues such as idiom recognition, use by the SLP vectorizer, etc. these seem independent of whether the canonical form is an intrinsic or a composite, and I don't think it makes the vectorizer cost model easier one way or the other. In any case, we now have relevant pattern-matching code in SDAGBuilder (although it is currently somewhat specific to reductions after loops), so we already have a better infrastructure to help backends with the shuffle-matching problem. There is a corresponding 'VectorReduction' SDNode flag. -Hal ----- Original Message ----- > From: "Chandler Car...

...9;m also not excited by the prospect of teaching all the mid-level optimizers about the arithmetic properties of safe.[us]div, which has been a big drawback to the other overflow checked arithmetic intrinsics. So, in conclusion, I think we should at least *try* to pattern match out the branches in SDAGBuilder for ARM64 before giving up and adding this intrinsic, or something like it.  Does that sound reasonable? My fear is that since the control flow is complex, the matching would get really nutty.  For example you could be clever for a/b and say "b + 1 >_unsigned 1 ? a / b : slow path"....

I'm starting to think we should directly implement horizontal operations on vector types. My suspicion is that coming up with a nice model for this would help us a lot with things like: - Idiom recognition of reduction patterns that use horizontal arithmetic - Ability to use horizontal operations in SLPVectorizer - Significantly easier cost modeling of vectorizing loops with reductions in

> why in order to add this particular instruction (sum elements in a vector) I need to add an insrinsic? Adding intrinsic is not the only way, it is one of the way and user WILL-NOT be required to invoke It specifically. Currently LLVM does not have any instruction to directly represent “sum of elements in a vector” and generate your particular instruction.However, you can do it without