Refactor EventFactory, Compilers and Parsers

[xeren]

Mostly cleans up some imports, but also

• outlines some memory barrier generations in compilers.
• outlines uses of ProgramBuilder.addChild in litmus parsers.
• integrates FenceNameRepository into EventFactory

Modifications to EventFactory

Added

• AArch64.newRMWLoadExclusive, AArch64.newRMWStoreExclusive
• X86.newLoadFence, newStoreFence (still not implemented, but merges two places)
• RISCV.newRMWLoadExclusive
• Power.newRMWLoadExclusive

Modified

• newRMWStoreExclusive, newRMWStoreExclusiveWithMo
• AArch64.newDmbBarrier, etc.
• AArch64.newBarrier(String,String) (moved from newFenceOpt)
• RISCV.newRMWStoreConditional
• newFakeCtrlDep(Register) (returns List<Event> and does no longer accept a Label)

[hernanponcedeleon]

@xeren can you please rebase and fix the conflicts?

[hernanponcedeleon]

Why are you adding newRMWLoadExclusive for each arch if they all end up calling the general case? While I could see an argument in the factory for having the method for each arch, we do have other "common" events that use a single method, e.g. newRMWStoreExclusiveWithMo

[ThomasHaas]

Why are you adding newRMWLoadExclusive for each arch if they all end up calling the general case? While I could see an argument in the factory for having the method for each arch, we do have other "common" events that use a single method, e.g. newRMWStoreExclusiveWithMo

I agree with you but maybe from a different point of view. I think it becomes more and more unclear of whether a XYZ.newEvent factory method generates a core event or not. For parsers, you want to NOT generate core events to support compilation(*), but for the Compilation passes you need to ensure to generate only core events.
I think this is particularly true for the C11.newThreadFence events which should NOT be called by the parser (for the most part) and only during Compilation. And those can reasonably well be moved in the dedicated compilation pass.
For example, the LKMM compiler has some helper methods for the lowering that are not otherwise exposed to parsers/other callers.

(*) It is fine to generate core events from the parser, but not if you intend to support compilation to other targets on those events (at least in our current architecture).

[xeren]

With the different newRMWLoadExclusive methods, I wanted to group all the usages in the program target-wise. It should have made them easier to be altered per-architecture. Ideally, Common, newRMWLoadExclusive, newLoadWithMo, newStoreWithMo and newFence are never used directly by parsers. As you noticed, my refactoring was incomplete.

[xeren]

In the latest commit I removed the individual barrier constructors in EventFactory, like AArch64.newDmbIshBarrier(). There is no use in having them around. The only users were the respective compilers, where I added individual methods in earlier commits.

From my side, this PR should be ready to merge.

[ThomasHaas]

Looks good to me. @hernanponcedeleon might want to take look once he has time.