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

Carsten Mattner carstenmattner at gmail.com
Wed Oct 24 00:37:58 PDT 2012


On Mon, Oct 22, 2012 at 6:52 PM, Carsten Mattner
<carstenmattner at gmail.com> wrote:
> On Sat, Oct 13, 2012 at 6:43 PM, Carsten Mattner
> <carstenmattner at gmail.com> wrote:
>> On Sat, Oct 13, 2012 at 2:55 AM, Eli Friedman <eli.friedman at gmail.com> wrote:
>>> On Thu, Oct 11, 2012 at 11:36 AM, Carsten Mattner
>>> <carstenmattner at gmail.com> wrote:
>>>> On Wed, Oct 3, 2012 at 12:37 PM, Carsten Mattner
>>>> <carstenmattner at gmail.com> wrote:
>>>>> On Thu, Sep 27, 2012 at 4:10 PM, Carsten Mattner
>>>>> <carstenmattner at gmail.com> wrote:
>>>>>> On Sat, Sep 22, 2012 at 5:28 PM, Carsten Mattner
>>>>>> <carstenmattner at gmail.com> wrote:
>>>>>>> On Sat, Sep 22, 2012 at 4:51 PM, James Molloy <james at jamesmolloy.co.uk> wrote:
>>>>>>>> Hi Carsten,
>>>>>>>>
>>>>>>>> He's asking for preprocessed source. If you run clang -cc1 in '-E'
>>>>>>>> mode instead of the normal '-c', it will run only the preprocessor and
>>>>>>>> emit source that is easy to compile elsewhere without dependencies.
>>>>>>>
>>>>>>> Mailed it privately to Eli, Rafael and you as it's a large file
>>>>>>> and may contain info not meant for the public.
>>>>>>>
>>>>>>> Thanks for the help.
>>>>>>
>>>>>> Sending the files again, now publicly. Can you test and try to fix
>>>>>> the infinite loop now?
>>>>>>
>>>>>> Any news on the slow and memory intensive compile of beam_emu.c
>>>>>> mentioned earlier?
>>>>>
>>>>> Was somebody able to inspect the issues?
>>>>
>>>> Anybody?
>>>
>>> I took a quick look at wxe_funcs.cpp; it doesn't hang for me with
>>> trunk clang.  -ftime-report does show us spending an insane amount of
>>> time in the loop-unswitch pass, and it's using a lot of memory (around
>>> 500 megabytes?), but it does complete successfully.
>>
>> Thanks Eli, I did another test today and noticed two things.
>>
>> When I was just building erlang via 'make all' wxe_funcs.cpp
>> didn't seem to take long to compile but this step in the erlang/lib/wx
>> build process didn't seem to end:
>> clang -shared -fPIC  i686-pc-linux-gnu/gl_funcs.o
>>  i686-pc-linux-gnu/egl_impl.o -lGL -lGLU -o ../priv/erl_gl.so
>> Then I interrupted the build process and touched wxe_funcs.cpp and
>> all other C and C++ files lib/wx and ran '/usr/bin/time make' in the top
>> directory. This time around wxe_funcs.cpp didn't finish quickly as
>> before. I can't reproduce the quick compile of wxe_funcs.cpp in such
>> a tree but maybe it's reproducible when building lib/wx for the first
>> time. This sounds random and non-conclusive but I'm just writing up
>> what I saw.
>>
>> So the timing for letting lib/wx finish is:
>> 2543.73user 3.62system 42:30.43elapsed 99%CPU (0avgtext+0avgdata
>> 347264maxresident)k
>> 45904inputs+39360outputs (4major+1975612minor)pagefaults 0swaps
>>
>> Eli, yes it looks like it does at some point finish to build.
>> I can also confirm that the resulting build does work with the
>> wxWidgets binding including OpenGL functionality.
>>
>> So I'd say once clang does finish building the "hard to build"
>> parts of Erlan/OTP the result looks basically functional.
>>
>> What can we do to fix the build time and space use?
>>
>> Do you have an idea what could have made the first build of
>> lib/wx process wxe_funcs.cpp quickly but stall at building erl_gl.so?
>> That looks similar to the long 'ar ...' step in Erlang's erts/
>> directory.
>>
>> llvm/clang version info:
>> clang version 3.2
>>  (http://llvm.org/git/clang.git e5a934d3c840872d58724383a83443ed38f1d831)
>>  (http://llvm.org/git/llvm.git  c2fcf1a67126a079e34f04bd09a50ae85fdd9469)
>
> Any news on these issues? If nobody is working or planning to work
> on it, I'll unsubscribe from the list. Have been hanging around to
> track the Erlang build compatibility.

OK, I'm unsubscribing. Please CC me if there's any news related
to this thread. Thanks.



More information about the cfe-dev mailing list