search for: algabraically

On Tue, May 17, 2016 at 8:49 PM Owen Anderson <resistor at mac.com> wrote: > > On May 16, 2016, at 2:42 PM, Sanjoy Das via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > - Core motivation: why do we even care about optimizing floating > point induction variables? What situations are they common in? Do > programmers _expect_ compilers to optimize them

Demikhovsky, Elena wrote: > > Even then, I'd personally want to see further evidence of why the > correct solution is to model the floating point IV in SCEV rather than > find a more powerful way of converting the IV to an integer that models > > the non-integer values taken on by the IV. As an example, if the use > case is the following code with appropriate flags to

> One option would be to extend InductionDescriptor::isInductionPHI in the vectorizer to directly analyze the PHIs without SCEV support as Sanjoy suggested. I *think* that that could be sufficient to handle case B. I implemented this with FP SCEV and the code looks very structured, including SCEVExpander. Extending the existing structures without implementing FP SCEV will be problematic. And

To the best of my experience, handling case B (secondary induction) is must-have, and if I’m not mistaken, people aren’t opposed to that. For me, handling case A (primary induction) is “why not?”, but I certainly admit that that can be very naïve thinking coming from lack of good understanding on SCEV and their proper usages. Now, let’s assume we can postpone discussion about case A. What is the

> 1. Callers are expected to not engage in speculation. ScalarEvolution > itself must only create expressions it knows hold in all cases. This is correct. There is some more relevant text in ScalarEvolution::isSCEVExprNeverPoison. And you're right, this is quite restrictive. > Long term, I think that it would be cleaner to rework this so that all of the SCEV's are immutable

Hi Hideki, I like this summary overall, thanks. More below. > On May 20, 2016, at 10:04 AM, Saito, Hideki <hideki.saito at intel.com> wrote: > > > To the best of my experience, handling case B (secondary induction) is must-have, and if I’m not mistaken, > people aren’t opposed to that. > > For me, handling case A (primary induction) is “why not?”, but I certainly

Adding support for FP inductions through isInductionPHI() is certainly possible, I have a relatively small local patch that does exactly that for simple fp add-recurrence cases, along with changes to the vectorizer to make it aware of FP inductions. It won't get give you the powerful reasoning capabilities of SCEV, but for the B-like cases it should work. Amara On 20 May 2016 at 19:31, Adam

...ail/llvm-dev/2016-September/105108.html >> and http://lists.llvm.org/pipermail/llvm-dev/2017-August/116324.html >> >> +Andrew Trick >> >> — Sanjoy > I was never able to reconcile integrating nsw/nuw flags into SCEV. They violate the spirit of SCEV, in the sense that algabraically equivalent expressions must be uniquely identified, and that the the order that expressions are evaluated should not affect the outcome. > > My understanding matches Hal's, that we can imbue AddRec's with flags because they're already tied to the IR. It's usually incorrect to...

[+CC Andy] Hi Elena, I don't have any fundamental issues with teaching SCEV about floating point types, but given this will be a major change, I think a high level roadmap should be discussed on llvm-dev before we start reviewing and committing changes. Here are some issues that I think are worth discussing: - Core motivation: why do we even care about optimizing floating point