RFR (M): 8036767 PPC64: Support for little endian execution model

[David Holmes]

<trimming>

On 28/02/2015 5:06 AM, Andrew Hughes wrote:
> ----- Original Message -----
>> On 27/02/2015 11:25 AM, Andrew Hughes wrote:
>>> ----- Original Message -----
>>>> <trimming>
>>>> On 26/02/2015 12:31 PM, David Holmes wrote:
>>>>> On 26/02/2015 2:57 AM, Andrew Hughes wrote:
>>>>>>>>> These are the revised versions of the webrevs:
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/root/
>>>>>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/jdk/
>>>>>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/hotspot/
>>>>>>>>>
>>>>>>>>> (HotSpot is unchanged, dropped the sound changes from JDK)
>>>>>>
>>>>>> Ok if I push the jdk and root parts then? I think someone on the Oracle
>>>>>> HS team (David?) needs to push the HotSpot bit.
>>>>>
>>>>> Best to push it all together I think, which I can do through the hs-rt
>>>>> forest. But first I need to see where things settled with all this :) I
>>>>> was quite confused by some of the initial suggestions. Will try to get
>>>>> to this today.
>>>
>>> Well, I'd push it all myself if there weren't still restrictions on pushing
>>> to HotSpot...
>>>
>>>>
>>>> I'm still very confused by these changes and have trouble tracking the
>>>> values of the various "arch" related variables. If I follow this right
>>>> presently the only distinction between ppc64 and ppc64le is the value of
>>>> OPENJDK_TARGET_CPU_ENDIAN. In particular they both use ppc64 as the
>>>> hotspot LIBARCH value and ppc as the ARCH value. (Aside: so ARCH/ppc64
>>>> is either unused or only used by a hotspot-only build?)
>>>>
>>>> The desired change is that the top-level architecture (VAR_CPU which
>>>> becomes OPENJDK_TARGET_CPU) should now be ppc64le not ppc64, but that
>>>> for hotspot the only difference is LIBARCH becomes ppc64le. So to
>>>> achieve this hotspot-spec.gmk switches ARCH to be ppc64 instead of the
>>>> current ppc; and then hotspot's def.make uses that combined with being
>>>> lttle-endian to reset the LIBARCH to ppc64le.
>>>
>>>   From ppc64le. Without the override in hotspot-spec.gmk, the HotSpot build
>>> will get called with ARCH=ppc64le and fail, because make/defs.make will
>>> set SRCARCH to x86
>>
>> No, ARCH comes from $(OPENJDK_TARGET_CPU_ARCH) which comes from
>> $VAR_CPU_ARCH which is still ppc, not ppc64le. So SRCARCH will be set to
>> ppc as per current code. Then BUILDARCH will check LP64 and so become
>> ppc64. Then you can check endian-ness to define LIBARCH to ppc64le.
>>
>
> Ah, not in 8 where this was tested:
>
>   ARCH=$(OPENJDK_TARGET_CPU_LEGACY)
> +# ppc64le uses the HotSpot ppc64 build
> +ifeq ($(OPENJDK_TARGET_CPU), ppc64le)
> +  ARCH=ppc64
> +endif
>
> OPENJDK_TARGET_CPU_LEGACY is set to OPENJDK_TARGET_CPU which is ppc64le in this case.
>
> 9 changed this with:
>
> 8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy value for hotspot ARCH
>
> So it looks like we're going to end up with three different patches for this issue.

That explains all the confusion :)

>> Yes but you can do it based on the value of LIBARCH rather than a
>> modified ARCH.
>
> Yes, with 8046471 in place. Hardly a huge difference though.

Avoiding the need to mess with what happens at the configure level in 
hoptspot-spec.gmk.in makes it a lot simpler to follow IMHO.


>> I don't know if I already had this conversation but it strikes me as
>> really bizarre that the PPC64 port uses two different ARCH values
>> depending on whether it is a configure-based build or not! ???
>>
>
> It's not just that port. Every build either gets ARCH set by
> hotspot-spec.gmk (by way of configure) or by uname -m in
> make/linux/makefiles/defs.make. This is necessary if you're
> going to allow someone to skip configure and just build HotSpot.

It's not the two different mechanisms that I was referring to, but the 
fact that those mechanisms result in two completely different values for 
ARCH for the same port. This just piles complexity on top of complexity.

> If no-one does that any more, then the old stuff that was needed
> for 7 builds (no configure) could be culled.

Eventually the hotspot build will be all configure based. Even now I'm 
not sure why people need to do a hotspot-only build this way rather than 
just running configure and "make hotspot-only".

>> That aside if ARCH == ppc64 from uname then:
>> - SRCARCH = ARCH/ppc64  = ppc
>> - BUILDARCH = ppc64
>>
>> and so the same fix as above would work for this case.
>>
>
> It doesn't, as I said. It's ppc64le. So the uname override is necessary.
> For consistency, it probably should now be overridden to be ppc, not
> ppc64, given the value passed in from configure changed to that in
> 8046471.

Ok.

Thanks,
David
-----

>>> so our addition to hotspot-spec.gmk is just to do the same as this
>>> block for configure builds.
>>>
>>> It was unneeded before because configure would just set the arch
>>> to ppc64 for the entire build, not just HotSpot.
>>
>> AFAICS it set it to ppc not ppc64.
>
> I was referring to:
>
> -      VAR_CPU=ppc64
> +      VAR_CPU=ppc64le
>
> and in turn OPENJDK_TARGET_CPU_LEGACY, not VAR_CPU_ARCH/OPENJDK_TARGET_CPU_ARCH.
>
>>
>> David
>> -----
>>
>>
>>>> Thanks,
>>>> David
>>>>
>>>>
>>>> Given the LIBARCH switcheroo that happens in hotspot/make/def.make, why
>>>> bother also doing the switcheroo in
>>>> <top>/common/autoconf/hotspot-spec.gmk.in when you could just do
>>>> everything in hotspot/make/defs
>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>
>>>>>> Thanks,
>>>>>>
>>>>
>>>
>>
>