RFR: Implement better address lowering for AArch64
doug.simon at oracle.com
Mon Apr 3 16:25:43 UTC 2017
> On 3 Apr 2017, at 17:37, Andrew Dinn <adinn at redhat.com> wrote:
> Hi Doug,
> Hmm, this is getting trickier.
> I looked at the option of subclassing HotSpotSuitesProvider to define
> this subclass hierarchy:
> AMD64HSSP -----\
> SPARCHHSSP -----+-- HSSP
> AArch64HSSP --/
> (n.b. HotSpotSuitesProvider and its prospective subclasses names have
> been abbreviated to <XXX>HSSP merely so I can fit the class hierarchy on
> the page -- I really intended the new classes to be
> AMD64HotSpotSuitesProvider, etc).
> Unfortunately, I found that there is a name clash with an existing class
> in the following hierarchy:
> AMD64HSSP -- AMD64SuitesProvider ----\
> SPARCSuitesProvider -----+-- DefaultSuitesProvider
> AArch64SuitesProvider ---/
> I can (sort of) see why the two AMD64 children in this latter hierarchy
> are distinguished -- each adds a phase to the LIR suites at a slightly
> different level of generality. However, the names belie the fact that
> this is happening in the DefaultSuitesProvider hierarchy rather than the
> HotSpotSuitesProvider hierarchy.
> I think these subclasses of DefaultSuitesProvider might have been named
> better as
> or, better still, AMD64DefaultSuitesCreator etc since they are only
> needed to implement the interface SuitesCreator which is used to type
> the first argument to the constructor for HotSporSuitesProvider (n.b.
> use of the Creator names is going to require yet more revision of naming
> -- the rot set in for this whole hierarchy at the root of the class tree
> above these classes above DefaultSuitesProvider where its parent,
> SuitesProviderBase, implements SuitesCreator).
> Would it be best to rename these 4 classes to include the name Default
> as above? Or would you recommend some other naming scheme for the
> subclasses of HotSpotSuitesProvider I need to create?
Hmm, the existing hierarchies are indeed ripe for confusion! I think you're suggestion for AMD64DefaultSuitesCreator etc is the best to clean this up.
@Roland: I think you were involved with creation/evolution of the existing code. Does the *DefaultSuitesCreator clean up suggested by Andrew make sense to you?
Once we agree on the cleanup, I'm fine with it being done in the same PR.
More information about the graal-dev