In D52508#1341166, @lebedev.ri wrote:

Are you still working on this?

Sounds good to me. Just adding Sjoerd/Sam who might know more about this code.

Looks sensible to me.

Some of D56386 seems to be mixed up in here I think?

LGTM, with a couple of minor points.

Perhaps we add a MIR test? To test this more directly.

Great stuff. This looks like it will be very useful. I have a few thoughts/questions/nits.

Looks good to me. Apologies for the delay.

This looks find to me then, especially at aggressive opt level. IIRC, there is a test for the pass pipeline I would expect needs updating.

Do you have any compile time numbers for this?

Oh, yeah, that looks wrong! It should be testing a powerpc target.

This looks fine, of course, to go alongside D49281.

When @dmgreen is happy with the unrolling changes, I think you're good to go.

I ran a few bootstraps to check compile time (on AArch64). It didn't seem to make any noticable difference there, and this certainly looks like its good for codesize.

Thanks for the fix!

Thanks for the fix!

Hello, Another one for you, this time to do with LCSSA not being preserved, run with "opt -loop-simplifycfg -indvars simplified.ll -S":

target datalayout = "e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128"
target triple = "aarch64-arm-none-eabi"

Hello. I have an error from this, which I think may well be a knock-on affect for the code later in the pass. Something like this:

I'm happy to change stuff around. I believe it's the way it is at the moment because of the place this is called, half way into a constructor (making virtuals difficult) and some archs requiring different pieces of info (like aarch64 being different for JIT's). I figured if in doubt, don't change too much at once.

Hello. I agree that this looks like an improvement. Can you add a testcase?

Cleanup using tablegen classes.

Unfortunately, this also increased codesize a little at -Oz, which I will have to look into.

(but can cause problems for cases where the blocks are not in the form they will appear in assembly).

I'm not sure what sort of issue you're running into here?

Hello! Drive by comments. I've not looked in any depth.

Friendly Ping

I've managed to convince myself that this looks OK. A couple of nits depending on what you think of them.

Nice cleanup. LGTM

I was thinking about how this might affect other little cores like the A53/A55, especially around the dual issue on q registers. I don't think it will make much difference though, and the CSE benefits look like a bigger win.

Now ignores loops that will never be executed. I also have some code that uses SCEV to calculate if the backedge count is <= 1 and allow inlining there. It doesn't seem to come up very often though and needed some plumbing to get SE's/TLI's in the right places.

Anyway, this looks good to me.

Interesting. I didn't realise it worked like that. I had presumed that lot of passes would have to be taught about the optional defs, as opposed to them not being marked as dead correctly.

Yep, this came up a few times in the tests I ran. Looks like a nice improvement, and I don't think it complicate things too much.

This looks like something that would be useful for us, where some of our benchmarks are very low noise. I currently have a couple of test-ish LNT instances with changes similar to this, either changing this value or setting ignore_small=False from the daily report page.

I think we should deal with do while in another patch.

Yeah, defo. I just need to come up with a sensible way to fix it. I feel some of this is pushing against the edges of what instcombine should be doing, but I'll keep pushing until someone tells me to stop.

Interesting. Nice improvements. What about small trees? It would seem that any tree less that 75 nodes would always be recalculated. Do the timings you ran include things to show that this is better? Or was that just looking at larger trees at the time?

Yeah, I agree. LGTM.

Nice idea. The rtabi seems to says:

Write functions return the value written, read functions the value read.

Yeah, that looks like similar IR to what I was looking at. The vectorised version on Skylake (https://godbolt.org/z/RBS2Os) has a lot of shuffling, perhaps that's deemed unprofitable on Goldmont?

Oh, no. That's not what I wanted to hear. I presume we are looking at the same bit of code!

Whilst we're here, can anyone think of a good way to simplify:
(S + -32) - (-32 & (S + umax(31 - S, -32)))
That's the "do" case. I think if we distribute the -32& through the add, that with the rest of instcombine + cse + instcombine again does get us down to:
S & 31

OK, now one bit ol' matcher. Thanks for the suggestions.

This is the page I look at as reference for alive coding:
https://github.com/nunoplopes/alive/blob/newsema/rise4fun/language

I ran some benchmarks for thumb1, they look great.

Just added a new test, and changed some of the others around a little.

I've taken the demand parts parts out of this, and added some extra tests for the do / while and signed /unsigned cases.

Luckily, it appears that Alive can do countLeadingOnes too (although I don't see it anywhere in the sources I have).
https://rise4fun.com/Alive/O9i

Updated to use activeBits. Thanks for the suggestions.

Ah, I must have been looking at the wrong bit of code. Thanks!

It turns out the other case I ran into above ((S + -32) - (32 & (S + umax(31 - S, -32)))) was from do loops, not while loops. Signed will also be different to unsigned, with signed cases not having quite as small simplified forms.
These are the cases:
https://godbolt.org/z/SE-xhD
With some possible simplifications:
https://rise4fun.com/Alive/slxj

Hello, see the part about context in https://llvm.org/docs/Phabricator.html#phabricator-request-review-web. It's easier to review things if we can see the code around the patch as well as the code in the patch.

Hello. Very nice. I don't think I can speak to much of the detail here, especially the Hexagon parts, but can you:

• Add full context to the patch (-U99999)
• Replace the copyright headers to be more "llvmy"

I've added a new memcpy test from the original reproducer. It's a byte memcpy (people seem to love writing those), which I think is worth focusing on because its small, but still increases codesize. It expands to:

Unfortunately, since I did this everything seems to have changed and we now end up with something like:
(S + -32) - (32 & (S + umax(31 - S, -32)))

Let me know if you see anything funny from this patch.

For loop-noinline.ll the "Simplified" instructions (the ones that cost nothing) appear to be:
br %body
3 x phis
one of the geps in the loop
the gep outside the loop
the ret

Yep sure, with 52177, I no longer have a motivating case for this.

LGTM, Thanks

LGTM