This is an archive of the discontinued LLVM Phabricator instance.

[AArch64] Register passes so they can be run by llc
ClosedPublic

Authored by rovka on Jul 27 2016, 8:30 AM.

Details

Summary

Initialize all AArch64-specific passes in the TargetMachine so they can be run
by llc. This can lead to conflicts in opt with some command line options that
share the same name as the pass, so I took this opportunity to do some cleanups:

  • rename all relevant command line options from "aarch64-blah" to "aarch64-enable-blah" and update the tests accordingly
  • run clang-format on their declarations
  • move all these declarations to a common place (the TargetMachine) as opposed to having them scattered around (AArch64BranchRelaxation and AArch64AddressTypePromotion were the only offenders)

Diff Detail

Event Timeline

rovka updated this revision to Diff 65744.Jul 27 2016, 8:30 AM
rovka retitled this revision from to [AArch64] Register passes so they can be run by llc.
rovka updated this object.
rovka added reviewers: t.p.northover, gberry.
rovka added subscribers: llvm-commits, rengolin.
t.p.northover edited edge metadata.Jul 27 2016, 9:31 AM

Why are only some names conflicting? I'm not quite sure why registering a pass would add an option, at least not in all cases (it seems particularly inappropriate for llc, which doesn't work like that).

It would also be good to be consistent if possible rather than having some with "-aarch64-enable-whatever" and some just "-aarch64-whatever".

Why are only some names conflicting? I'm not quite sure why registering a pass would add an option, at least not in all cases (it seems particularly inappropriate for llc, which doesn't work like that).

Right, I wasn't very clear about this - the conflicts are in opt. I'm not particularly excited about the fact that llc and opt work in different ways, nor about the fact that you need to do *some stuff* to see your pass in print-before-all and *some other stuff* so you can use print-before=BlahPass, but I guess that's not the point here.
You only get conflicts in some cases because not all registered passes have an option defined in AArch64TargetMachine [1], or the options have a different name than the one the passes are registered with (e.g. "aarch64-stp-suppress" vs "aarch64-store-pair-suppress").

It would also be good to be consistent if possible rather than having some with "-aarch64-enable-whatever" and some just "-aarch64-whatever".

Now that you mention it, I guess I could get creative about the names we use to register the passes, and then we'd avoid the conflicts in the first place. Alternatively, we could be a bit more tidy and rename all the options to "-aarch64-enable-whatever", because that describes their effect better. Do you have any preference here?

Another inconsistency here is *where* the options are defined - a bunch of them are in AArch64TargetMachine, but that's not the case for all of the passes, e.g. AArch64BranchRelaxation defines the option in its own file. I'm slightly in favor of keeping the option in the same file as the pass. I'm volunteering to move all of them if you think it's a good idea.

Thanks for having a look.

[1] e.g. AFAICT the local-dynamic TLS cleanup pass doesn't have an option; although there is a flag that sounds like it in AArch64ISelLowering, it doesn't seem to affect it

Ah, that makes sense.

Alternatively, we could be a bit more tidy and rename all the options to "-aarch64-enable-whatever", because that describes their effect better. Do you have any preference here?

I think this option is probably simplest.

Another inconsistency here is *where* the options are defined - a bunch of them are in AArch64TargetMachine, but that's not the case for all of the passes, e.g. AArch64BranchRelaxation defines the option in its own file.

I think we've noticed this in the past, but I can't find the thread now. It would be good to get everything consistent. Either way seems about the same to me, so you get to choose as the one doing the work!

Cheers.

Tim.

rovka updated this revision to Diff 66106.Jul 29 2016, 4:27 AM
rovka updated this object.
rovka edited edge metadata.

Went ahead and renamed the command line options and moved them all to TargetMachine. In the end I preferred this solution because there's no point in adding passes to the PassConfig if they've been disabled on the command line.

Thanks Diana! Looks good to me.

t.p.northover accepted this revision.Jul 29 2016, 6:53 AM
t.p.northover edited edge metadata.
This revision is now accepted and ready to land.Jul 29 2016, 6:53 AM
rovka closed this revision.Aug 1 2016, 12:13 AM

r277322.