I removed _Float16 related tests since some bots may fall with it, i dont know much about this custom type.
Anyway, It is fine on linux x86 64. I will restore them.

Addressed comments, fixed tests

Ping :)

Sorry for little offtopic at first.

Ok, I will address your comments soon.

Very interesting work!

Since no futher comments, i think it is ok.
After day or two I will commit it.

Ping

@echristo wanted to look at this

@aaron.ballman

Any benchmark results w/o this patch?

Ping :)

Since I don't think we have any false positives here, maybe it would be useful to add it to -Wall or -Wextra?

maybe @aaron.ballman wants to take a look too

• Addressed review comments.

Ping

Are you still looking at this?

Anything else to be done here? I would like to finish this patch to work on other things.

• New warning text, added another test line

In D52504#1282049, @RKSimon wrote:

Sanjay's changes don't seem to be rebased ?

• Rebased

Ok, https://reviews.llvm.org/D53901

Any ideas for better warning message? Except for the warning text, I see this patch as ready.

• Rebased

Ping @MTC or @rsmith

Ping

ping

Side idea:
From C function callsites with size arg we could theoretically determine some pointer aliasing info..

• formatting fixes

• drop problematic nonnull attributes with unknown size arg

Maybe we can also drop nonnull attributes for certain functions with size argument, here, in instcombine?

• updated test file

• Avoid marking if address spaces

• Tests updated

Does the pass groups hot code together? is it in your plans?

Thanks @spatel, I missed it :(

https://pastebin.com/8bxCuV5V + this patch
opt -instcombine p.ll -S

• Added MTC'c case to test file

No warning for your case.

Ping @spatel whether he has any idea why instcombine turns
define dso_local i32 @fff6(i8* nocapture readonly %s) local_unnamed_addr #5 {
entry:
%call = tail call i64 @strlen(i8* nonnull %s) #8
%conv = trunc i64 %call to i32
ret i32 %conv
}

Ping

Ping

I reverted D50656 fix for pr38539 and pr38539.ll passed fine. So pr38539.ll tests nothing in the current trunk and it should not block this patch.

Second thought, I don't think we should recommend std::size here (maybe it should be okay for clang static analyzers)

Is PrecisionConversion acceptable? If not, any suggestions for name?

Also we should avoid cases like
mov eax, dword ptr [rsi]
lea eax, [rax + rdi]

Ping, plesse rebase

InstCombine does something weird for me.

• Updated

Thanks for stats, interesting! Maybe try with some big C benchmarks/codebases? SPECs? :)

• More marked functions