[LLVMdev] Memory Allocation Optimized away with new by not with ::operator new
mats petersson
mats at planetcatfish.com
Mon May 4 04:50:17 PDT 2015
If the compiler can't say for sure that your operator new is identical (has
no side-effects beyond allocating memory), it would be correct for the
compiler to NOT optimise it out - as it can't determine that it has no
other effect that your program rely on in some way.
--
Mats
On 4 May 2015 at 11:37, François Fayard <fayard.francois at icloud.com> wrote:
> Hi,
>
> I’ve made my own version of std::vector which is called il::Vector. Due to
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3664.html, LLVM
> can optimise away memory allocation. Therefore, the following code optimise
> away all memory allocation for w resulting in a single allocation during
> the whole program (for v).
>
> When using my own vector implementation, I realised that the allocation
> were not optimized away because I was using ::operator new. When I’ve
> switched back to new, the optimisation came back.
>
> Is it expected or a bug from LLVM?
>
> François
>
> =====
>
> #include <iostream>
> #include <vector>
>
>
> std::vector<double> f_val(std::size_t i, std::size_t n) {
> auto v = std::vector<double>(n);
> for (std::size_t k = 0; k < v.size(); ++k) {
> v[k] = static_cast<double>(i);
> }
> return v;
> }
>
> int main (int argc, char const *argv[])
> {
> const auto n = std::size_t{10};
> const auto nb_loops = std::size_t{300000000};
>
> auto v = std::vector<double>( n, 0.0 );
> for (std::size_t i = 0; i < nb_loops; ++i) {
> auto w = f_val(i, n);
> for (std::size_t k = 0; k < v.size(); ++k) {
> v[k] += w[k];
> }
> }
> std::cout << v[0] << " " << v[n - 1] << std::endl;
>
> return 0;
> }
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150504/2355e1a9/attachment.html>
More information about the llvm-dev
mailing list