[PATCH] D86005: [NewPM][LoopFullUnroll] Make LoopFullUnrollPass required

Yuanfang Chen via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Aug 17 17:48:02 PDT 2020


ychen added a comment.

In D86005#2222884 <https://reviews.llvm.org/D86005#2222884>, @aeubanks wrote:

> In D86005#2221998 <https://reviews.llvm.org/D86005#2221998>, @ychen wrote:
>
>> This is to say optnone does not work for these 3 passes all the time. Could we do this in the optnone callback by checking the metadata of the branch inst in latch block? That is precisely what we meant here.
>
> Do you mean don't have the optnone pass instrumentation say that the pass should be skipped if it sees the proper metadata?

Yes, that's what I meant because we're overriding optnone's decision based on "llvm.loop.unroll.full" here. The patch in its current shape means the three passes are immune to the `optnone` which seems stronger than necessary.

> I think the metadata is specific just to this one pass and checking it doesn't belong in the optnone pass instrumentation.

Yeah, it is a little bit out of place. I'm running out of idea here. However, putting the logic there is very explicit about the intention.

> There may be some semantic meaning to fully unrolling a loop, and that should happen regardless of optnone/opt-bisect, whatever else.

Fully unrolling loops is just a regular transformation pass. It happens to have a user knob that should be respected (pragma). I could not think of other scenarios that it is special but I'm not sure. @asbirlea thoughts?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D86005/new/

https://reviews.llvm.org/D86005



More information about the llvm-commits mailing list