RFR (M): Enable HotSpot build with Clang

Volker Simonis volker.simonis at gmail.com
Mon Jun 3 06:31:27 PDT 2013


On Fri, May 31, 2013 at 7:47 PM, Christian Thalinger <
christian.thalinger at oracle.com> wrote:

>
> On May 31, 2013, at 12:41 AM, David Holmes <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.

How did you fix it exactly? Have you added:

OPT_CFLAGS/loopTransform.o = $(OPT_CFLAGS/NOOPT)

to 'amd64.make' and excluded 'loopTransform.o' from precompiled header
compilation in 'gcc.make' with:

    PCH_FLAG/loopTransform.o = $(PCH_FLAG/NO_PCH)

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
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>
> >>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130603/4690ad74/attachment.html 


More information about the hotspot-runtime-dev mailing list