[cfe-dev] computed goto/labels as values in interpreters

Carsten Mattner carstenmattner at gmail.com
Thu Aug 23 09:14:06 PDT 2012


On Sat, Aug 18, 2012 at 1:55 PM, Carsten Mattner
<carstenmattner at gmail.com> wrote:
> On Fri, Aug 17, 2012 at 8:50 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
>> On Fri, Aug 17, 2012 at 11:42 AM, Carsten Mattner
>> <carstenmattner at gmail.com> wrote:
>>> On Fri, Aug 17, 2012 at 7:40 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
>>>> On Fri, Aug 17, 2012 at 8:14 AM, Carsten Mattner
>>>> <carstenmattner at gmail.com> wrote:
>>>>> After searching list archives and bug reports I wasn't able to conclude
>>>>> whether computed goto/labels as values as used in Erlang and other (Guile)
>>>>> interpreters is supported in clang 3.1. With some BSDs working to make
>>>>> clang/clang++ the base cc/c++ this is going to be even more important.
>>>>>
>>>>> Is clang 3.1 supposed to compile beam_emu.c correctly and with the
>>>>> same or comparable optimization result?
>>>>>
>>>>> https://github.com/erlang/otp/blob/master/erts/emulator/beam/beam_emu.c
>>>>
>>>> Yes, it's supposed to.
>>>
>>> Yes, seems to work but with some interesting differences compared to
>>> gcc. While gcc-4.7 takes 6s to recompile Erlang's emulator if I
>>> 'touch beam_emu.c', clang takes 2m11s and consumes around 141MB RES vs
>>> 40MB gcc.
>>
>> IIRC, there's been some work in this area since 3.1.  If you're still
>> seeing issues on trunk, please file a bug.
>
> Thanks for the info. From what I can see beam_emu did get built and
> I was able to run the emulator. I didn't do any performance test because
> AFAIR previously it didn't result in a runnable executable at all. This
> result with enough success for now.
>
>>> Not sure why but clang also seemed to result in a longer
>>> time to run ar. Tests were conducted on i386 linux 3.5.1 with
>>> glibc-2.15 against erlang's maint branch. Next, a process which is
>>> known to be slow is building some of the generated C++ files in lib/wx
>>> (wxWidgets Erlang bindings). Now, when linking erl_gl.so with clang
>>> it took forever to finish (didn't time). This is similar to the ar
>>> archive step in erts/emulator. Is there anything inherently slow with
>>> gcc-4.7, glibc-2.15, and binutils-2.22? ar and ld from binutils at
>>> fault? While linking erl_gl.so RES of clang was at 265MB. It seemed
>>> to be an infinite loop and I stopped it after more than 5 minutes.
>>
>> I'm not following this... linking shouldn't be spending any
>> substantial amount of time in the "clang" process.  clang just invokes
>> ld.
>
> Me neither, it's totally unexpected and surprising.
>
>> If you have a reproducible infinite loop, please file a bug.
>
> I won't be able to conduct another set of tests including clang trunk
> before the middle of next week, sorry.
>
> If anyone wants to try in the meantime here are the steps:
>
> $ git clone git://github.com/erlang/otp.git
> $ cd otp
> $ export ERL_TOP=$PWD
> $ export PATH=$ERL_TOP/bin:$PATH
> $ export CC=clang
> $ export CXX=clang++
> $ ./otp_build setup -a --prefix=$PWD/localinstall
> $ make install
> You can run and test the emulator without installing locally.
> If you want to build the emulator only to see about beam_emu.c
> $ ./otp_build autoconf && ./otp_build configure --prefix=$PWD/localinstall
> $ cd erts && make
> erl_gl.so is built in lib/wx
> $ cd lib/wx && make
> This naturally requires wxWidgets

Could the long and in wxErlang's case never ending link phase be explained
by the use of the gold linker in this linux distro's clang 3.1 package?
Are there known issues/incompatibilities with that?



More information about the cfe-dev mailing list