[llvm-dev] llvm.set.loop.iterations

[Sam Parker via llvm-dev]

Hi Markus,

It's fair to expect there's going to be slight differences between each target, so HardwareLoopInfo is there to communicate these between the backend and the transform. I would suggest adding a flag in that struct to prevent the HardwareLoops pass from adding one to the 'ExitCount' as this is cleaner than adding another intrinsic.

Regards,
sam


Sam Parker

Compilation Tools Engineer | Arm

. . . . . . . . . . . . . . . . . . . . . . . . . . .

Arm.com

________________________________
From: Markus Lavin <markus.lavin at ericsson.com>
Sent: 11 July 2019 14:40
To: llvm-dev at lists.llvm.org
Cc: Sam Parker
Subject: llvm.set.loop.iterations

After playing a bit with the newly introduced hardware loop framework I realize that the llvm.set.loop.iterations intrinsic takes as argument the number of iterations the loop will execute. In fact it goes all the way to, on IR, insert an addition of constant 1 to the number of taken backedges returned by SCEV.

If the machine instruction realizing the loop is interested in the number of branches-to-make / backedges-taken then this is slightly awkward as we need to subtract the constant 1. Of course if the iteration count was constant this is trivial but if it is passed in register then it is not so nice to have to insert these subtract instructions from a MIR pass (where the hwloop finalization is being done).

I wonder what would be the best way to deal with this.

One way would be to add a TTI hook gating the original addition but then the intrinsic will have two meanings depending on what this hook returns which is not good.

Another way would be to introduce a second intrinsic, say llvm.set.loop.backedges that corresponds to that value, but then we have yet another intrinsic.

A third option could be to have the original intrinsic take both values as arguments.

Any thoughts on this?

regards
Markus


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190711/2f408087/attachment.html>