The ARM backend uses several tricks to support selection of
VFP3_D16/VFP3_D32 when ocamlopt is invoked, which introduces
interferences with non-existing floating-point registers when
the VFP3_D16 fpu option is used. These invalid interferences
must be skipped while coloring the graph.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@13229 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
This fixes the following warnings generated by ld on Mac OS X:
- ld: warning: could not create compact unwind for _caml_raise_exn: stack subq instruction is too different from dwarf stack size
- ld: warning: could not create compact unwind for _caml_raise_exception: stack subq instruction is too different from dwarf stack size
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@13227 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
Mac OS X ships with a really old version of as, which does not support
the CFI directives. LLVM itself provides an assembler that is certainly
way more up to date, but currently there's no dedicated frontend, so we
simply use clang in this case.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@13226 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
The interference graph no longer contains "ill-typed" interferences
between registers of different class, so we no longer need to test
in the coloring algorithm.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@13208 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
The coloring algorithm uses only the "well-typed" interferences (registers
with same class). This is because we don't assign the same stack slot to
registers of different register class.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@13207 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
Use rev16/movt to implement direct 16-bit byte-swap operation
(ARMv6T2 and above) and rev to implement the 32-bit byte-swap
operation (ARMv6 and above).
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@13203 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
-native flag semantics are currently different to that what the user
expects, and what was attempted to be fixed. The semantics of -native
are not to completely disable generation of dependencies for bytecode
instead make the compilation to native code more efficient.
Most of the project are expected to be buildable with both versions of
the compiler. So ocamldep is expected to always generate the
dependencies in both cases. When the .mli file is absent ocamldep
needs to still generate dependencies in bytecode to build the cmi only
and to build cmi and cmx for the dependent compilation unit . Because
of some make tool pecularities, handling of two different rules that
include the same depenency is problematic, so instead when the -native
flag is not used the cmo file is used as a proxy to build cmi, when
the -native enabled however, the cmx file is used as proxy to build
cmi file for the dependencies to avoid recompilation of the dependent
.cmo file just to get .cmi file.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@13202 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
Is enabled by saying:
# make OCAMLBUILD_NOBOOT=yes world.opt
currently just works for bytecode only.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@13189 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
Still requires some work, in particular:
* native build of ocamlbuild
* building Camlp4 still is not working
* not vpath leftover files break the further build
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@13188 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
Nowdays all the Windows operating systems accept both, more over it's
being passed to our toolchain as a relative path (not UNC), so I see
no harm if we want to be a little bit more portable. The only reason
to not doing so is conventiob and IDEs which might parse Makefile.nt
and not recognise it.
Proposed by Adrien Nader.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@13176 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
camlp4.opt works only with native plugins therefore the fix will break bytecode camlp4 plugins.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@13167 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02