In D83745#2178363, @SjoerdMeijer wrote:

I understood from your message to the llvm dev list that generating numbers isn't entirely straightforward for you.
I will take this patch, and generate some numbers, will see if I can do that today/tomorrow, and will let you know.

In D83745#2178363, @SjoerdMeijer wrote:

I understood from your message to the llvm dev list that generating numbers isn't entirely straightforward for you.
I will take this patch, and generate some numbers, will see if I can do that today/tomorrow, and will let you know.

In D83745#2175668, @SjoerdMeijer wrote:

Eye balling the one test that was changed this indeed makes sense. But I would prefer to see some performance numbers first just to check we haven't missed anything.

In D83745#2175668, @SjoerdMeijer wrote:

Eye balling the one test that was changed this indeed makes sense. But I would prefer to see some performance numbers first just to check we haven't missed anything.

In D83928#2175664, @SjoerdMeijer wrote:

Although I don't mind at all new tests being added, in this case I am really wondering if the code paths are not exercised by existing tests. And also reading the description:

This case will show furture optimization of add-imm & sub-imm.

I am wondering what these future optimizations are and if these tests should simply go in with that then?

ping

ping

ping

The patch depends on https://reviews.llvm.org/D83928, it will show improvements based on it.

This patch does two optimization:

ping

In D83745#2153885, @SjoerdMeijer wrote:

Okay, I had only a quick first look, perhaps multiple uses isn't a problem.
If it's not too much trouble, confirming this with the llvm test-suite would be good.

for C code

unsigned int f0(unsigned int a)
{
        return a-0x2323;
}
unsigned int f1(unsigned int a) 
{
        return a+0x2323;
}

1. Is there a benchmark test suite I can try?

1. RISCV got improved

Change list according to all your comments.

Change list according to all your comments.

Chnage list according to all your comments.

One more change:

Thanks. I have improved the function names according to your suggestion!

Thanks for all of your suggestions. I have uploaded a new patch edition.

This patch will show the optimization by my previous patch https://reviews.llvm.org/D83153

The build failure does not related to my changes, today's llvm master branch also has them after running "make check-all"

My patch at least generates better code x86, aarch64 and riscv.

In D82660#2127626, @lenary wrote:

I'm happy with this optimisation where this patch removes multiply libcalls.

Where the target has a the m extension, and especially for 64-bit multiplies on rv32im, I'm not sure this is an optimisation.

I think that, for the moment, we should add a guard to the hook to avoid this transformation where we do have mul instructions:

if (Subtarget.hasStdExtM())
  return false;

What do you think?

ping ...

Could you please help me review it? I have not got any suggestion for one week :)

Thanks. I have uploaded a new version according to your suggestion!

This patch can not cover all cases (especially "call __mulsi3" on rv32 without M extension), but at least it works well for most cases.

Why "Harbormaster failed remote builds in B61745: Diff 273379!" ???

All done. Thanks for your suggestion. ^_^

My information,

Sorry, it is my mistake. Please close this review request.

for (add i32 %a, 4094), it can be simplfied to
addi a0, a0, 2047
addi a0, a0, 2047.