search for: valarray

I am now getting an X86ATTAsmPrinter error in compiling libstdc++-v3 right near the end of compiling llvm-gcc in valarray-inst.cc. assertion "IndexReg.getReg() != X86::ESP && "X86 doesn't allow scaling by ESP" Does this build on Linux ? My remote Linux box has died and not a ble to reset it for a day or two. /home/ang/build/llvm-gcc/./gcc/xgcc -shared-libgcc -B/home/ang/build/llvm-gc...

This looks like pr4572. Evan On Jul 27, 2009, at 3:25 AM, Aaron Gray wrote: > I am now getting an X86ATTAsmPrinter error in compiling libstdc++-v3 > right near the end of compiling llvm-gcc in valarray-inst.cc. > > assertion "IndexReg.getReg() != X86::ESP && "X86 doesn't allow > scaling by ESP" > > Does this build on Linux ? > > My remote Linux box has died and not a ble to reset it for a day or > two. > > /home/ang/build/llvm-gcc/....

...bit, but it is not important, dead code elimination was out of my scope. >> In terms of C++: there should be a possibility to regenerate >> non-static member functions for a given instantiated object >> of the classes where performance is critical, e.g. for classes >> like valarray. CL> Sure, but you still need the 'this' pointer, to know WHICH valarray you CL> are talking about... ? sure. But what if this `this' was set once for 1mio calls? Today I have a lot heavy math function working with two spectra and every time I have to think twice before making a...

...al code implementations for every top-level call of `rec_func' to avoid big number of extra `push'. In terms of C++: there should be a possibility to regenerate non-static member functions for a given instantiated object of the classes where performance is critical, e.g. for classes like valarray. So, my questions are: Q1. should/might the optimization like this be resolved at LLVM layer? if "yes" then Q2. is LLVM capable of doing things like that today? Thanks. -- Valery

...t; varray's do not have any recursive function calls, and the > methods tend to be simple. For that reason, they are > typically all inlined, eliminating > the parameter passing completely... you are right. However, my classes for spectra analysis I deal with should be as fast as valarray is, but they may not be so oversimplified as valarray... I have to break my fat non-static member functions into smaller pieces and those simple pieces are called a lot of times with the same `this'. So, the `valarray'-like classes in real life are not always that nice. > I really a...

...his kind of thing, the functional language community has a lot of ways to deal with this. > In terms of C++: there should be a possibility to regenerate > non-static member functions for a given instantiated object > of the classes where performance is critical, e.g. for classes > like valarray. Sure, but you still need the 'this' pointer, to know WHICH valarray you are talking about... ? > So, my questions are: > Q1. should/might the optimization like this be resolved at LLVM layer? Yes, LLVM is designed for spiffy optimizations like this. :) > if "yes" th...

We recently found an issue when using the full restrict implementation developed by Jeroen; it surfaces when compiling an obscure combination of std::valarray and std::indirect_array but I don't want to bore you with all the details. What it boils down to is this basic question about restrict: Given one restrict pointer based on another, should they never alias? As far as I understand the formal definition of "restrict" in section 6.7.3.1...

....com>; hfinkel at anl.gov > *Subject:* Given one restrict pointer based on another, should they never > alias? > > > > We recently found an issue when using the full restrict implementation > developed by Jeroen; it surfaces when compiling an obscure combination of > std::valarray and std::indirect_array but I don't want to bore you with all > the details. What it boils down to is this basic question about restrict: > > Given one restrict pointer based on another, should they never alias? > > As far as I understand the formal definition of "restrict&q...

...cxx_objects.dir/__/src/system_error.cpp.o projects/libcxx/lib/CMakeFiles/cxx_objects.dir/__/src/thread.cpp.o projects/libcxx/lib/CMakeFiles/cxx_objects.dir/__/src/typeinfo.cpp.o projects/libcxx/lib/CMakeFiles/cxx_objects.dir/__/src/utility.cpp.o projects/libcxx/lib/CMakeFiles/cxx_objects.dir/__/src/valarray.cpp.o projects/libcxx/lib/CMakeFiles/cxx_objects.dir/__/src/variant.cpp.o -lpthread -lc -lm -lrt Please suggest how to fix these linking errors. Regards, Dmitry -------------- next part -------------- A non-text attachment was scrubbed... Name: libcxxlinking.txt.gz Type: application/x-gzip Size:...

...d > CL> translate it to use an explicit stack: > then I have to dig LLVM docs about explicit stack :) I just mean you have an explicit stack data structure to store just the elements the recursive call needs. > CL> Sure, but you still need the 'this' pointer, to know WHICH valarray you > CL> are talking about... ? > > sure. But what if this `this' was set once for 1mio calls? > Today I have a lot heavy math function working with two spectra and > every time I have to think twice before making another member function > which is invoked in deeper stack...

...every top-level call of `rec_func' to avoid big number of > extra `push'. > > In terms of C++: there should be a possibility to regenerate > non-static member functions for a given instantiated object > of the classes where performance is critical, e.g. for classes > like valarray. > > So, my questions are: > > Q1. should/might the optimization like this be resolved at LLVM layer? > > if "yes" then > > Q2. is LLVM capable of doing things like that today? > > Thanks. > -- > Valery > _____________________________________________...

...peinfo.cpp.o > [ 34%] Building CXX object lib/CMakeFiles/cxx.dir/__/src/locale.cpp.o > [ 46%] [ 38%] Building CXX object lib/CMakeFiles/cxx.dir/__/src/regex.cpp.o > Building CXX object lib/CMakeFiles/cxx.dir/__/src/utility.cpp.o > [ 42%] Building CXX object lib/CMakeFiles/cxx.dir/__/src/valarray.cpp.o > Building CXX object lib/CMakeFiles/cxx.dir/__/src/hash.cpp.o > Building CXX object lib/CMakeFiles/cxx.dir/__/src/bind.cpp.o > [ 53%] [ 57%] [ 50%] Building CXX object > lib/CMakeFiles/cxx.dir/__/src/mutex.cpp.o > Building CXX object lib/CMakeFiles/cxx.dir/__/src/thread.cpp.o...

On 10/3/14 10:16 AM, Dan Albert wrote: >> >> I try to build libc++ and libc++abi for host x86_64(linux) and target >> arm(linux) but fail. >> > > Failing in what way? If this isn't working out of the box, we've done > something wrong. Yeah, it would help to know more specifics about where you're getting stuck. > > jroelofs might know more... For