RFR (M): Enable HotSpot build with Clang
Vladimir Kozlov
vladimir.kozlov at oracle.com
Mon Jun 3 14:51:19 PDT 2013
> I have no idea where this stuff is supposed to be. Maybe we should move
> the mulnode one to {i486,amd64}.make as well. Vladimir pushed this
> change in 2009.
gcc.make is place when you want lower optimization for all builds
(product, fastdebug, debug) on all platforms. I played safe back then to
avoid problems in all cases which may be overkill. And compiler code is
not critical part of VM (not GC code) when we should worry about its
performance.
Vladimir
On 6/3/13 2:21 PM, Christian Thalinger wrote:
>
> On Jun 3, 2013, at 6:31 AM, Volker Simonis <volker.simonis at gmail.com
> <mailto:volker.simonis at gmail.com>> wrote:
>
>> On Fri, May 31, 2013 at 7:47 PM, Christian Thalinger
>> <christian.thalinger at oracle.com
>> <mailto:christian.thalinger at oracle.com>> wrote:
>>
>>
>> On May 31, 2013, at 12:41 AM, David Holmes
>> <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
>>
>> > I think this is mainly targetted at Volker but ...
>> >
>> > On 31/05/2013 4:32 AM, Christian Thalinger wrote:
>> >>> Here is what I have after merging in your new changes:
>> >>>
>> >>> http://cr.openjdk.java.net/~twisti/8015252/webrev/
>> >>>
>> >>> I see two problems:
>> >>>
>> >>> 1) It's not possible to turn off precompiled headers because
>> of this:
>> >>>
>> >>> + ifeq ($(USE_CLANG), true)
>> >>> + # clang has precompiled headers support by default, but
>> the user can switch
>> >>> + # it off by using 'USE_PRECOMPILED_HEADER=0' on the
>> compile command line.
>> >>> + ifdef LP64
>> >>> + USE_PRECOMPILED_HEADER=1
>> >>> + else
>> >>
>> >> Let me rephrase that: at least not with an environment variable.
>> >
>> > In this block:
>> >
>> > ! ifeq ($(USE_CLANG), true)
>> > ! # clang has precompiled headers support by default, but the
>> user can switch
>> > ! # it off by using 'USE_PRECOMPILED_HEADER=0' on the compile
>> command line.
>> > ! ifdef LP64
>> > ! USE_PRECOMPILED_HEADER=1
>> > ! else
>> > ! # We don't support precompiled headers on 32-bit builds
>> because there some files are
>> > ! # compiled with -fPIC while others are compiled without
>> (see 'NONPIC_OBJ_FILES' rules.make)
>> > ! # Clang produces an error if the PCH file was comiled with
>> other options than the actual compilation unit.
>> > ! USE_PRECOMPILED_HEADER=0
>> > ! endif
>> >
>> > I think the LP64 case should be guarded by "ifeq
>> ($(USE_PRECOMPILED_HEADERS),)".
>>
>> Yes, will change that.
>>
>> >
>> > The comment "on the compile command line" should be "on the make
>> command line" I think.
>>
>> I removed the comment since with the above guard it works with either.
>>
>> >
>> > Typo: comiled
>>
>> Fixed.
>>
>> >
>> > David
>> > -----
>> >
>> >> -- Chris
>> >>
>> >>>
>> >>> 2) If I compile with clang on Mac and run the compiler
>> regression tests a lot of them fail but they work with a debug VM.
>> So it seems that one of the files is broken with optimization on
>> (-Os or -O3; -O0 is okay).
>>
>> I had some time yesterday to figure which file it is:
>> opto/loopTransform.cpp. Compiling this one with NO_OPT makes
>> everything to work.
>>
>>
>> I can confirm this on Linux.
>
> Good.
>
>>
>> How did you fix it exactly? Have you added:
>>
>> OPT_CFLAGS/loopTransform.o = $(OPT_CFLAGS/NOOPT)
>>
>> to 'amd64.make'
>
> No. I added it to gcc.make because there was already this one:
>
> *+ # 6835796. Problem in GCC 4.3.0 with mulnode.o optimized compilation.*
> *+ ifneq "$(shell expr \( \( $(CC_VER_MAJOR) = 4 \) \& \( $(CC_VER_MINOR) = 3 \) \))" "0"*
> *+ OPT_CFLAGS/mulnode.o += -O0*
> *+ endif*
>
> I have no idea where this stuff is supposed to be. Maybe we should move
> the mulnode one to {i486,amd64}.make as well. Vladimir pushed this
> change in 2009.
>> and excluded 'loopTransform.o' from precompiled header compilation in
>> 'gcc.make' with:
>>
>> PCH_FLAG/loopTransform.o = $(PCH_FLAG/NO_PCH)
>
> Yes.
>
> Here is an updated webrev:
>
> http://cr.openjdk.java.net/~twisti/8015252/webrev/
>
> -- Chris
>
>>
>> That's what I've done to solve solve the problem.
>>
>> Here are some build time numbers for my MacBook Pro:
>>
>> debug:
>> ------
>>
>> llvm-g++:
>>
>> real 2m28.831s
>> user 12m58.277s
>> sys 2m6.650s
>>
>> clang:
>>
>> real 1m28.552s
>> user 8m4.760s
>> sys 0m56.263s
>>
>> product:
>> --------
>>
>> llvm-g++:
>>
>> real 2m16.939s
>> user 12m32.473s
>> sys 1m47.061s
>>
>> clang:
>>
>> real 1m35.744s
>> user 8m50.101s
>> sys 0m53.294s
>>
>> I think I know which I'm going to use… :-)
>>
>> -- Chris
>>
>> >>>
>> >>> Do you have any problems on Linux?
>> >>>
>> >>> -- Chris
>> >>>
>> >>>>
>> >>>>>
>> >>>>> David
>> >>>>> -----
>> >>>>>
>> >>>>>> Please notice that I won't be in the office until the 3rd
>> of June.
>> >>>>>> Should you have any further change requests please feel
>> free to edit the
>> >>>>>> patch yourself if you like.
>> >>>>>>
>> >>>>>> Regards,
>> >>>>>> Volker
>> >>>>>>
>> >>>>>> -- Chris
>> >>>>>>
>> >>>>>>> -- Chris
>> >>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>> But you can say the exact same thing about the Solaris
>> >>>>>>>> gcc support.
>> >>>>>>>>
>> >>>>>>>> Btw. I just trying to resurrect this.
>> >>>>>>>>
>> >>>>>>>> -- Chris
>> >>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> David
>> >>>>>>>>> -----
>> >>>>>>>>>
>> >>>>>>>>>> Once it's in we could start with the JDK forest and
>> >>>>>>>> the configure part
>> >>>>>>>>>> in the base repository. That would require two extra
>> >>>>>>>> change sets anyway.
>> >>>>>>>>>> The HotSpot build currently isn't very
>> >>>>>>>> configure-agnostic anyway and
>> >>>>>>>>>> once the other parts have been completed, configure
>> >>>>>>>> could just pass
>> >>>>>>>>>> USE_CLANG=true (plus perhaps some extra variables in
>> >>>>>>>> the case we have
>> >>>>>>>>>> more than one clang version on the system) to the
>> >>>>>>>> HotSpot build and
>> >>>>>>>>>> everything should work.
>> >>>>>>>>>> As a last step we would have to test on Mac as well.
>> >>>>>>>> I currently don't
>> >>>>>>>>>> have one at hand, but sponsors are always welcome:)
>> >>>>>>>>>>
>> >>>>>>>>>> Volker
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> David H.
>> >>>>>>>>>>
>> >>>>>>>>>> -- Chris
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> David
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>
>> >>>
>> >>
>>
>>
>
More information about the hotspot-runtime-dev
mailing list