about summary refs log tree commit diff
path: root/src/rustllvm/RustWrapper.cpp
diff options
context:
space:
mode:
authorMatthieu M <matthieum.147192@gmail.com>2019-02-03 16:58:29 +0100
committerMatthieu M <matthieum.147192@gmail.com>2019-02-03 16:58:29 +0100
commiteb5b09688696562d08ebb35e34ded723e6e44277 (patch)
tree311ca64a210ca1b7a0c624ce9f5f81c6635f823a /src/rustllvm/RustWrapper.cpp
parentcae623c5ce12df8f237264d8f2c31fdaa664c382 (diff)
downloadrust-eb5b09688696562d08ebb35e34ded723e6e44277.tar.gz
rust-eb5b09688696562d08ebb35e34ded723e6e44277.zip
RangeInclusive internal iteration performance improvement.
Specialize Iterator::try_fold and DoubleEndedIterator::try_rfold to
improve code generation in all internal iteration scenarios.

This changes brings the performance of internal iteration with
RangeInclusive on par with the performance of iteration with Range:

 - Single conditional jump in hot loop,
 - Unrolling and vectorization,
 - And even Closed Form substitution.

Unfortunately, it only applies to internal iteration. Despite various
attempts at stream-lining the implementation of next and next_back,
LLVM has stubbornly refused to optimize external iteration
appropriately, leaving me with a choice between:

 - The current implementation, for which Closed Form substitution is
   performed, but which uses 2 conditional jumps in the hot loop when
   optimization fail.
 - An implementation using a "is_done" boolean, which uses 1
   conditional jump in the hot loop when optimization fail, allowing
   unrolling and vectorization, but for which Closed Form substitution
   fails.

In the absence of any conclusive evidence as to which usecase matters
most, and with no assurance that the lack of Closed Form substitution
is not indicative of other optimizations being foiled, there is no way
to pick one implementation over the other, and thus I defer to the
statu quo as far as next and next_back are concerned.
Diffstat (limited to 'src/rustllvm/RustWrapper.cpp')
0 files changed, 0 insertions, 0 deletions