In order to prepare a clean patch, I have to know what do the options
-OPT:Olimit=0 -WOPT:lpre=off:spre=off:epre=off do on the machines that
support it? Also, what is the meaning of -MALLOC_USE_HASH(1)?

Overall, thumbs up to the OTP team for making cross compilation very easy.
:)

---

-OPT:Olimit=0 -WOPT:lpre=off:spre=off:epre=off
tile-gcc 4.4.3 does accept these options:

cc1: error: unrecognized command line option
"-WOPT:lpre=off:spre=off:epre=off"

MALLOC_USE_HASH is not defined anywhere in the mentioned build
environment.
---
 erts/emulator/Makefile.in    |    1 -
 erts/emulator/sys/unix/sys.c |    6 ------
 2 files changed, 7 deletions(-)

diff --git a/erts/emulator/Makefile.in b/erts/emulator/Makefile.in
index 985ef72..644ca18 100644
--- a/erts/emulator/Makefile.in
+++ b/erts/emulator/Makefile.in
@@ -633,7 +633,6 @@ endif
 ifneq ($(filter tile-%,$(TARGET)),)
 $(OBJDIR)/beam_emu.o: beam/beam_emu.c
        $(CC) $(subst -O2, $(GEN_OPT_FLGS), $(CFLAGS)) \
-         -OPT:Olimit=0 -WOPT:lpre=off:spre=off:epre=off \
          $(INCLUDES) -c $< -o $@
 else
 # Usually the same as the default rule, but certain platforms (e.g. win32) mix
diff --git a/erts/emulator/sys/unix/sys.c b/erts/emulator/sys/unix/sys.c
index c1fa00b..4c168b6 100644
--- a/erts/emulator/sys/unix/sys.c
+++ b/erts/emulator/sys/unix/sys.c
@@ -398,12 +398,6 @@ void sys_tty_reset(int exit_code)
   }
 }

-#ifdef __tile__
-/* Direct malloc to spread memory around the caches of multiple tiles. */
-#include <malloc.h>
-MALLOC_USE_HASH(1);
-#endif
-
 #ifdef USE_THREADS

 #ifdef ERTS_THR_HAVE_SIG_FUNCS
--
1.7.9.5

"'malloc_use_hash' only affects malloc (specifically, it affects the
flags it passes to 'mmap' when it allocates more memory from Linux).
You can also explicitly malloc memory with various caching attributes
using custom mspaces.

The 'hash_default' argument in the .hvconfig file affects 'mmap' calls
that do not specify homing information.  Because malloc*does*  specify
homing information, at least when you are pthreaded, 'hash_default' is
ignored and malloc_use_hash is required to get hash-for-home."

This was something included in TileraMDE 2.0 beta (perhaps removed since
then).
I found it in TileraMDE-2.1.2/tile64/tile/usr/include/malloc.h though.

I guess it would be safe to remove "-OPT:Olimit=0
-WOPT:lpre=off:spre=off:epre=off ".
It is an optimization for tile-cc when compiling on target machine.
An earlier comment in Makefile.in seems to have been removed, it said:

+ifneq ($(filter tile-%,$(TARGET)),)
+# Some tile-cc optimizations take pathologically long for beam_emu.c,
+# so disable them.
+$(OBJDIR)/beam_emu.o: beam/beam_emu.c
+       $(CC) $(subst -O2, $(GEN_OPT_FLGS), $(CFLAGS)) \
+         -OPT:Olimit=0 -WOPT:lpre=off:spre=off:epre=off \
+         $(INCLUDES) -c $< -o $@
+endif

Patch was supplied by Tilera Corp.

Regards,
Bj�rn-Egil Dahlberg
Erlang/OTP

I think it would make sense to conditionalize it during configuration
phase. But how to test for its existence/absence?

diff --git a/erts/emulator/sys/unix/sys.c b/erts/emulator/sys/unix/sys.c
index 37dfcb1..176a5af 100644
--- a/erts/emulator/sys/unix/sys.c
+++ b/erts/emulator/sys/unix/sys.c
@@ -408,8 +408,10 @@ void sys_tty_reset(int exit_code)
  #ifdef __tile__
  /* Direct malloc to spread memory around the caches of multiple tiles. */
  #include <malloc.h>
+#if defined(MALLOC_USE_HASH)
  MALLOC_USE_HASH(1);
  #endif
+#endif

  #ifdef USE_THREADS

This was a problem Tilera had when they compiled in their environment,
i.e. uploading all code to the card and compiling it there (With their
specific cards). Here at OTP we cross-compiled everything and did not
see this problem. Hopefully this was a problem that has been remedied
since then though.

Also, tag - you’re it!

It would be greatly appreciated if you could summarize problems and
solution you have found for building and using Erlang on the Tilera card
or if you find something we can change to make anyones experience just a
bit easier. I don't know exactly where we should put this documentation
but my suggestion would either be in the documentation for cross
compiling or as a specific page on the GitHub Wiki. If the information
arrives, we will surely find a place to put it. =)

Then everything in documentation makes sense and is really clear.

However, if one wants to cross-compile using ./configure[⚗], then you have
to know the cpu-vendor-os triplet. I got it while invoking GCC on the
target machine:

    $ tile-monitor --resume --pci --resume --root -- gcc -v
    Using built-in specs.
    Target: tile-unknown-linux-gnu
    ...

Is there a better way? Anyway, this or the better way, I think, could be
documented.

If people run into compilation problems, usually it is not Erlang
specific. It's a missing macro, invalid compiler flag, missing function
during linking.. Standard stuff which is common to any C project. I am
afraid it does not make sense to add help to the Erlang building
documentation. Like "try removing stuff that is complaining and see
what happens" (the way I did) is too easy to be misinterpreted, and
whilst if you provide more aid you just repeat general C knowledge.

Sadly, specific questions are asked, without a reply[1].

Anyway, regarding code. Should I "prepare" a new patch with an updated
commit message, or what you have is good enough to be merged?

Regards,
Motiejus

Or I can make the changes with the additional small changes I proposed.