Can we guarantee "sizeof(<vscale x 1 x i8>) == vscale" for all future targets? much like how "sizeof(<vscale x 1 x i1>) == vscale" doesn't hold true for SVE. If not then this isn't a canonical form as the exact pattern becomes target specific. Or to put another, why should vscale be linked to data layout?

Given this establishes that adding the scalable vector type has inadvertently created a way to represent the runtime constant of vscale as a constant, what's the downside to having a clearer representation in the form of an explicit constant?

In D66337#1633466, @eugenis wrote:

I've committed a better fix in r369138.

Thanks for the report, I've committed a version without the %s that will hopefully fix the issue.

Have I got the terminology the wrong way round? I assumed relaxing meant the act of converting a branch who destination is not within range into a one that is within range either by inversion or introducing a second branch with sufficient range. I just want to make sure my commit message makes sense.

There is this nugget from the C documentation:

I also prefer Geoff's solution. Thanks Geoff.

In D45770#1071047, @gberry wrote:

Ugh, good find. Isn't this an issue if variable sized stack objects are present as well?

Query LangOpts for FastMast rather than IRBuilder and fleshed out the tests.

Not yet.

Adds support for versions of cabs that take discrete real and imaginary parameters.

Removed three instcombine tests that are either covered by existing instsimplify tests of have equivalent instsimplify tests provided by this patch.

Extended to cover une and oeq conditions. Added an assert to protect against unintentional refactoring and a TODO for future improvements.

Good point, I'll add the extra conditions along with the TODO.

Broke out the isNegative case into its own block so that more conditions can be handled when it's known the constant is non-zero. Removed my original tests and updated the existing ones to reflect the optimised output.

As requested I've simplified the patch's mir test.