LGTM

Looks good.

LGTM.

The change looks good but can you add a test case to test/CodeGen/ARM/swifterror.ll that r8 is not spilled say for a target triple of 'armv7-linux-androideabi'. For example, the function params_and_return_in_reg should not spill r8 as part of CSR spilling.

Same patch bug with added diff context.

Based on email conversation with John. He pointed out we purposely don't want to use the allocation size for the algorithm and that we can just use LLVM's layout when we compute the coercion types.

LGTM

I don't see a reasonable way to write a unit test without either creating a stub IR or making the typedef typename Traits::PhiItT public and then just testing the presence.

This might penalize programs that don't traffic in denormals (most programs as I understand it). Did you measure the performance impact?

Makes sense.

Thank you.

This make sense to me.

I think this change is orthogonal to improving SCEV for cases where we can prove no wrapping by looking at the IR. At the high level this change looks good to me (I have always wanted to have the ability for SCEV to gather assumptions needed to prove no wrapping) - and the examples demonstrate that there is a need. Silviu has addressed the issue of only generating the checks when needed.

I share Simon's concerns. Please make sure that we still get a good estimate for kernels like (these are from the rdar mentioned in the commit).

This LGTM. Nice work!

LGTM.

This LGTM though I think we should add an example to the documentation in the header similar to what is in the implementation.

LGTM

LGTM

I think that this should be a global at the top of the file so that it is more visible to folks would want to experiment with thresholds.

I think the discussion about how and whether we should use a caching mechanism in AliasAnalysis should be separate. Some clients already have their own caching strategy (MemoryDependence has its own, for example) and might not want/need the overhead of a caching implementation ...

Very nice! I only see minor fixes.

I don't think this should go behind a flag.

The code looks fine to me.

LGTM.

LGTM.

LGTM.

I also thing it makes sense to rename this to interleave factor to point out the difference between interleaved unrolling vs concatenating unrolling. Interleaving is not necessarily tied to vectorization. The fact that we interleave in the vectorizer is just an artifact of our implementation. I think it should be getMaxInterleaveFactor(). We are not necessarily interleaving vector instructions.

Hi Renato,

Thanks Hal!

Your patch LGTM.

We probably get NaN or some infinity - forget what I said.

Actually, now I am not sure myself - does an floating point div trap on zero? :D

I believe the optimization is safe for floating values that cannot trap.

LGTM. Sorry for the delay.

Hi Karthik,

With those changes this LGTM.

With those little nitpicks fixed. LGTM.

It is the relative depth of common uses.

There are four parts to the problem of widening chains when viewed from the SLP vectorizers perspective (staying in vector types):