Yes, cc1 flag would be useful.

So we can start by giving these objects full-expression lifetime, chase down any program bugs that that uncovers (which will all *unquestionably* be program bugs under the standard), and then gradually work on landing the more aggressive rule (perhaps even for non-trivial types).

Will gcc use counted_by or element_count ?

Maybe mention https://github.com/llvm/llvm-project/issues/42210

Do we again hit https://reviews.llvm.org/D102834?

This is serious, please fix or revert from release branches.

Tests?

In my opinion it makes sense to adjust that kernel code based on this warning in the current inplementation state.

You should add a testcase which uses “expected no diagnostics”.

We should not warn for macros.

In D86993#4497744, @aaron.ballman wrote:

In D86993#4477744, @RalfJung wrote:

It would probably be worth including all string functions that take a length in such a DR. In Rust we are currently puzzling over whether calling 0-length memcmp on something like (char*)42 is okay or not. If not we'd have to introduce a pretty pointless branch.

I think the DR would be to change 7.1.4p1 where it currently says:

If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer, or a pointer to non-modifiable storage when the corresponding parameter is not const-qualified) or a type (after default argument promotion) not expected by a function with a variable number of arguments, the behavior is undefined.

"invalid value" includes null pointers and we may want to make a surgical repair to say something along the lines of "unless invalid value is a null pointer and the library function has a count parameter blah blah blah". Then we'd cover all the APIs taking a pointer and a count in one go, I believe.

Not all tests are updated? X86/licm-nested.ll

It would be great to have reusable general algo with N as parameter.

fold -> expand? or inline?

Happy to see it!

Try
https://llvm-compile-time-tracker.com/about.php

efriedma:

(instcombine specifically won't work; for the sake of compile-time performance, we've forbidden instcombine from changing the cfg.)

In D86993#4474403, @RalfJung wrote:

Yeah, agreed. Though I hear that GCC makes similar assumptions, so this should count as something I think. (I don't have a source for this, so it should probably be verified.)

whole struct would be probably better, less churn. Plus, can we static_assert that size is <= XY?

Looks fine

If all you want is (1), that doesn't require any attribute (the optimizer will do it automatically).

In D147714#4446809, @haberman wrote:

Such a definition doesn't make much sense because for some targets tail call optimization isn't available at all.
Eg. Wasm w/o tail call proposal, xtensa windowed abi.

That is true. But what is the correct behavior if you try to use [[clang::musttail]] on such a target? In my case, I want to get a compiler error, because if a tail call cannot be performed, the algorithm is incorrect (it will cause stack overflow at runtime).

There are three possible semantics that I can see:

1. Perform a tail call if possible.
2. Perform a tail call, fail to compile if this is not possible ([[clang::nonportable_musttail]])
3. Perform a tail call, fail to compile if this is not possible or if the function signatures between caller and callee differ in ways that make tail calls difficult on some platforms ([[clang::musttail]])

Both (2) and (3) would fail to compile on Wasm without tail calls. If all you want is (1), that doesn't require any attribute (the optimizer will do it automatically).

In D147714#4446780, @yamt wrote:

musttail provide assurances that the tail call can be optimized on all targets.

Such a definition doesn't make much sense because for some targets tail call optimization isn't available at all.
Eg. Wasm w/o tail call proposal, xtensa windowed abi.

So I'm not sure what's the point of the new attribute. It seems simpler to fix the existing musttail attribute.

You have to update that file anyway. Pre-commit builds are clearly failing.

https://reviews.llvm.org/D136737 used 'builtin_unspecified_value' which could be okay. .. or builtin_undefined_value maybe?

You should update checks in loopstrengthreduce::scaling-factor-incompat-type.ll

I am wondering if we could enable it for X86 too. Any known blockers?

Added missing comment.

Addressed review comments.

Addressed review feedback

But I prefer if things are slow rather than faulty.

Rebased and updated callsites.

Addressed review feedback, thanks.

any futher comments?

In D147704#4322809, @nikic wrote:

@xbolva00 Could you please explain what the larger context here is? Which frontend generates nonnull on call-site only?

Something "cheap" we could do is attach nonnull attributes to arguments of inlined calls, when appropriate.

Remove useless PhaseOrdering test.

Addressed review feedback. Added new test with char duplication.

In D128011#4314930, @nikic wrote:

Why does this need a phase ordering test? What is the output after just InstCombine for it? Does InstCombine not reliably reduce the comparisons and require SimplifyCFG switch optimization? What if there is no actual branch involved and SimplifyCFG doesn't reduce it?

Rebased.

We generally fail to call 'foldBinOpIntoSelectOrPhi' in commonIDivTransforms and commonIRemTransforms

any futher comments?

Addressed review feedback.

Use USHRT_MAX. Added check.

alignment info generally hits same issue

Yes, please, as I would be able to commit it for you only next week.

Added check 'CB.getAttributes().hasParamAttr(ArgNo, Attribute::NoUndef)'. The impact of this PR is non-trivial:
https://llvm-compile-time-tracker.com/compare.php?from=06ddb7bfe24891eee43bcf19252708b0cf684562&to=d1559cc73ad38f7684a026f8c69c6c96af9246a3&stat=instructions:u