[aarch64-port-dev ] RFR(s): 8251930: AArch64: Native types mismatch in hotspot

[Anton Kozlov]

On 19.08.2020 12:42, Anton Kozlov wrote:
> On 19.08.2020 11:45, Andrew Haley wrote:
>> On 18/08/2020 16:21, Anton Kozlov wrote:
>>> Another approach is to leave a single overload for integer type, but
>>> literal integer could still be ambiguously promoted to e.g. pointer
>>> or int64. So every user will have to explicitly cast literal
>>> integers to a certain type.
>>
>> Maybe a template function for mov() ?
>>
> 
> A template is interesting, it may save as a few lines and reduce the amount of
> choices to several. I'll try to do that.
> 

A template is complicated by the existing mov(Register, Address) overload.  We
need a single template to capture all integer types and the other template or
overload to handle Address() and its subclasses. For example

    template<class T>
    inline void mov(Register dst, T imm) {
      mov_immediate64(dst, (uint64_t)imm);                                      
    }                                                                           
   
    void mov(Register dst, Address a);

doesn't compile for mov(r0, RuntimeAddress()) without an explicit cast of
RuntimeAddress to Address.

With C++14, it is possible to avoid casts with use something like enable_if[1],
so the code in macroassembler would look like 

    template<class T, typename std::enable_if_t<std::is_integral<T>::value>* = nullptr>
    void mov(Register r, T imm) { ... }

    template<class T, typename std::enable_if_t<std::is_class<T>::value>* = nullptr>
    void mov(Register r, T addr) { ... }

Compared to the current patch, I don't think such template would be less
error-prone or more maintainable. I would stick to the current version.

Thanks,
Anton

[1] https://en.cppreference.com/w/cpp/types/enable_if