exactly the same

re-upload due to the depended llvm patch need rework.

The preview revision failed in expensive build bot check due to register class check. this is the new upload.

add var_arg test case

Please review again

Because __security_push_cookie has extra 0x10 subtraction on SP, if you removes buf[100], you will see no security_push_cookie is used. it will be sp on entry.

I debugged MS ARM64 setjmp/longjmp functions and ARM64 EH runtime. If you looks like assembly output from CL for ARM64, it is using SP instead of FP.

I see you point. I have removed CGOptLevel portion

I tried this patch, I think it is a little bit too restrictive. If something like
define i8* @foo() {
entry:

store i8* getelementptr inbounds ([5 x i8], [5 x i8]* @.str, i32 0, i32 0), i8** @b, align 4
ret i8* getelementptr inbounds ([5 x i8], [5 x i8]* @.str, i32 0, i32 0)

}

Hi, I am facing the same issue. In my case, I disable the rematerialization of all instructions that referring contant pool. I think only t2LEApcrel is rematerializable right now. Because
the safety assumption of ContantIslandPass is that the reference to an constant pool entry should be one use. ARM common subexpression elimination will make single reference to one constant pool, the
rest reference should be copy. I believe the only re-introduction of referencing instruction is the rematerialization in register allocation pass. If we disable rematerialization. the assumption of one use should hold
until constant island pass in general. So in constant island, we can simply check if the CPE->RefCount is not greater than 1, if is greater than 1, no cloning. How do you think?

rename unit test case from qc-deprecated-asm.s to deprecated-asm.s

This kind of IR does actually exist. For our case, it happens after Inlining and Jump Threading, Jump Threading merges if else together and generates a branch with true/false target pointing to the same basic block. It is rare case but it happens. So we need test this situation.

Our code base is huge in LTO, it usually take very very long time to dump into a file. With this function, the process would be dramatically faster. I believe this would also benefit other people.

the functionality, it is similar to llvm-extract. however, it provides a runtime solution to extract a function from a debugger from any point in compilation time like LTO, something after inlining. You can extract function right at the assertion point. llvm-extract only can work on a file. We need a runtime solution.

Hi Nirav, I think the problem need to be solved should be the same with and without AA. It is testing the node predecessors. For your new upload, you use different check with UseAA. For my algorithm, it only tests the latest node in the store array because it is the one that links with the successors. Do you have another test case that shows failure with UseAA? What could be the different with UseAA?

Changing finding better chain algorithm may hide the problem fixed by this patch, but for our test case, changing the FindBetterChain algorithm doesn't help.

Hello, I am wondering if the current llvm/clang's tbaa supports union or not?

Hi Chandler, I agree that the attributes to save cost is not the right approach. I can work on this to fix it. However, we tried this algorithm for SPEC on ARM/AArch64. we saw improved results. However, when we tried this with LTO, we experienced mess regression. Largely due to too aggressive inlining because this algorithm will make some functions which cannot be inlined before inlined now. Some functions should be huge.

Hi Jiangning

Hi Jiangning,

Hi Jiangning,

I looked your code, you removed the check in call analyzer and MaxRecursionInl is about inlining history. I would like to know if you set MaxRecursionInl is 0, the inliner will behave exactly like the before without your code?