please also add test cases.

I see a lot of potential to make this more general. As I mentioned, this is similar to constant propagation based function cloning -- exposing specialization opportunities seems not limited to inliner though inlining could be the biggest customer.

This is good stuff, but I don't feel Inliner is the right place to do such transformation.

Can you add a test case with shared libraries?

This does not look like backward compatible IR change. For the purpose of annotating irreducible loop headers, it might be better to introduce a new type of metadata.

A test case?

I need an explicit LGTM for the patch. thanks.

Addressed review feedback.

Um -- updated the wrong patch. Please ignore.

Addressed review feedback.

lgtm

As I have mentioned, this patch itself does *not* fold any ptrtoint/inttoptr. It simply moves the intptr across the phi node. The folding you see with the test cases is done by existing optimizations, so I am not sure what the objection is about.

Address Wei's review feedback

Address review comments (fixing lower case in comments) by Hal.

This patch basically just sinks ptrtoint operation from phi arguments to the phi output, but does not do any ptrtoint(inttoptr) folding itself (relies on existing rules to do that), so it should be safe to do by itself.

It does not look like related SROA -- the conversion already exists via stack memory store and load in IR. It looks like related libstdc++'s tuple implementation, though I did not have a small repro -- whether it is from sroa is also irrelevant -- user source can always produce IR like this which needs to be cleaned up or understood (by analysis).

lgtm

Perhaps provide a simple overload getBlockProfileCount for MachineFunction?

lgtm

Just some initial comments around the test cases.

The class of inputs are usually generated by other optimizations such as SROA from C++ code -- the int/ptr conversions are usually not directly created by the user code. Logically speaking, handling of inttoptr/ptrtoint is no different from BitCast operation (ideally also implemented using BitCast op, but not doable due to IR spec), so there is no reason we should treat them as opaque while not doing so for BitCast.

looks like a useful debugging option.

lgtm

lgtm

How can we test it works for ThinLTO? some end-to-end test is also desired (given that this becomes an external feature).

Looks fine to me, but please wait for Richard's comment.

Documentation needs to be added to clang/docs/ClangCommandLineReference.rst .

lgtm

What happens if caller is hot, and the callee (missing profile) is unconditionally called by the caller? Will it still be treated as cold?

lgtm

Addressed review feedback.

Also improved test cases to cover the path that exposed the bug.

Fix an obvious bug.

lgtm

Please add a comment why copy is needed.

I am not sure what you try to achieve here. Basically, there is no need to to use environment variable.

Addressed Chandler's review feedbacks

lgtm

Tried the two patches with our internal benchmark -- the alignment related performance issue is still there. The problem disappears with -mllvm -x86-experimental-pref-loop-alignment=5 is used.

Can you send the full patch so that we can help evaluate it?

We verified that the regression we saw internally is due to loop alignment.

lgtm

performance tests with large benchmarks showed no regression.

Will test on some very large programs that are sensitive to icache pressure and get back.

convinced.

I will provide more comments on propagating the inline hint later. However, I do think it is wrong to propagate the cold attribute in inliner -- there should be already an inter-procedural attribute propagation pass that does this.