LLVM 3.9.1 is now packaged in mason: https://github.com/mapbox/mason/issues/308
Upgrade our Clang compiler to the latest stable release.
Keeps clang-format at 3.8.1 for consistency.
This disables the `-flto` LTO flag by default since we're seeing
segfaults in compiler lto plugins, binutils and linker errors again and
again for various clang / gcc / binutils combinations.
Pass `-DNEBALE_LTO` to `cmake` in order to re-enable LTO.
LTO situation in short:
- LTO does not work at all for gcc<4.9
- With gcc>=4.9 the "slim" LTO format is getting used dumping IR
- Older binutils need LTO plugins which know how to read this IR
- Recent binutils handle this format all by themselves
- LLVM is more or less the same with some Clang versions segfaulting
If you need the performance benefit of LTO, make sure your compiler and
binutils are up to date and see for yourself if LTO builds work for you.
References:
- https://gcc.gnu.org/wiki/LinkTimeOptimizationFAQ
- https://github.com/Project-OSRM/osrm-backend/pull/3481#issuecomment-270618997
- https://github.com/Project-OSRM/osrm-backend/issues/3501
- https://github.com/Project-OSRM/osrm-backend/issues/3441
(and a ton of other LTO tickets if you search for them)
Lane Anticipation currently triggers on quick steps with lanes. This
changeset makes the "quick" part more dynamic by taking lanes left and
right of the turn into account. The reasoning for this is as follows.
The user can drive on the leftmost or rightmost lane and has to cross
all lanes left or right of the turn, respecitvely.
We scale our threshold appropriately, which now means the threshold
describes the duration the user needs for crossing _a single lane_.
Note: this is a heuristic and assumes the worst case. Which in my
opinion is fine to do since triggering Lane Anticipation in complex
scenarios is desirable.
This keep the metadata reader flag disabled by default unless explicitly specified.
Signed-off-by: FILLAU Jean-Maxime <jean-maxime.fillau@mapotempo.com>
