This is an archive of the discontinued LLVM Phabricator instance.

RFC: Target-specific loop idiom recognition
AbandonedPublic

Authored by kparzysz on Aug 5 2015, 2:40 PM.

Details

Summary

Hexagon has certain library functions and intrinsics that are specific to that target, and that are equivalent to a code written using loops. To fully exploit these features, the loop-idiom recognition pass would be the best candidate to handle these opportunities, but since it is a target-independent pass, polluting it with target-specific code does not seem like a good idea.

I'm guessing that Hexagon is likely not the only platform with these properties, and certainly there is nothing in the way for any other target to provide their own implementation of some common loop idioms (via hand-optimized library functions, for example).

This is an attempt to create a target-independent interface by which individual targets can provide their own functions to recognize loop idioms. Also, included is a do-nothing demo of how a Hexagon's pass could be hooked up using this interface.

Diff Detail

Repository
rL LLVM

Event Timeline

kparzysz updated this revision to Diff 31396.Aug 5 2015, 2:40 PM
kparzysz retitled this revision from to RFC: Target-specific loop idiom recognition.
kparzysz updated this object.
kparzysz set the repository for this revision to rL LLVM.
kparzysz added a subscriber: llvm-commits.

You have made significant contributions to either the loop idiom recognition or the target transform info. Could you let me know what you think about this?

hfinkel edited edge metadata.Aug 12 2015, 1:37 AM

Is there any aspect of this that is (or will be) specific to loop idiom recognition, or is this just a way for a target to insert a pass at some point early in the pipeline?

The target-provided function is invoked in the loop idiom recognition pass, so that's the connection here. It does not have to be that way, and inserting a target-specific pass into the pipeline would also work, but there is no way to accomplish this at the moment.

Hi,

I agree with Hal's comment here. I don't see the value-add for other targets from this approach.

What's the value of calling this from LIR? Your hook isn't leveraging off of any of LIR's infrastructure, and that is the usual goal. "Take out what is target independent, and keep what is not" - There's no target independent stuff being hoisted here, you're just running a pass on a loop. You can do that without LIR.

I think you'd have to describe some functionality being shared here before I'll be fully convinced.

Cheers,

James

See also my comments here: http://lists.llvm.org/pipermail/llvm-dev/2015-August/089190.html

-Hal

  • Original Message -----

From: "James Molloy" <james.molloy@arm.com>
To: kparzysz@codeaurora.org, chandlerc@gmail.com, "benny kra" <benny.kra@gmail.com>, aschwaighofer@apple.com,
echristo@gmail.com, sanjoy@playingwithpointers.com, hfinkel@anl.gov
Cc: "james molloy" <james.molloy@arm.com>, "ted woodward" <ted.woodward@codeaurora.org>, llvm-commits@lists.llvm.org
Sent: Thursday, August 13, 2015 2:54:43 AM
Subject: Re: [PATCH] D11782: RFC: Target-specific loop idiom recognition

jmolloy added a subscriber: jmolloy.
jmolloy added a comment.

Hi,

I agree with Hal's comment here. I don't see the value-add for other
targets from this approach.

What's the value of calling this from LIR? Your hook isn't leveraging
off of any of LIR's infrastructure, and that is the usual goal.
"Take out what is target independent, and keep what is not" -
There's no target independent stuff being hoisted here, you're just
running a pass on a loop. You can do that without LIR.

I think you'd have to describe some functionality being shared here
before I'll be fully convinced.

Cheers,

James

Repository:

rL LLVM

http://reviews.llvm.org/D11782

What's the value of calling this from LIR?

As per my previous reply---the value is that the target-specific hook runs at the same time as the regular LIR. This is important not because there is anything shared between the two, but because the loops are "in the right shape" for doing such transformation. Also, as I said earlier, inserting a target-specific pass into the optimization sequence at that point would work, but there is no way of doing it right now: there is no extension point at where LIR runs right now. If the approach described in the email that Hal added in his comment was implemented (including an extension point for LIR), this would work for me just fine.

sanjoy resigned from this revision.Aug 16 2015, 5:48 PM
sanjoy removed a reviewer: sanjoy.

You have made significant contributions to either the loop idiom recognition or the target transform info.

No I haven't. :)

kparzysz abandoned this revision.Mar 3 2016, 2:28 PM