search for: forward_list

...es is currently a `SmallVector<, 12>`, but a histogram Pete ran shows that half of DIEs have 2 or fewer values, and 85% have 4 or fewer values. We're paying for 12 (!) upfront right now for each DIE. Instead, we should optimize for 2-4 DIEValues. Not sure whether a std::forward_list would suffice, or if we should do something fancy like: struct List { DIEValue Values[2]; PointerIntPair<List *, 1> NextAndSize; }; Either way we should move the allocations to a BumpPtrAllocator (trivial if it's a list instead of vector)....

...m certain I'm missing something, but I don't know what. To be absolutely clear, a Result is calculated of type: std::unique_ptr<CFLAndersAAResult> Result; And CFLAndersAAResult contains member fields: DenseMap<const Function *, Optional<FunctionInfo>> Cache; std::forward_list<cflaa::FunctionHandle<CFLAndersAAResult>> Handles; The DenseMap Cache is empty, and so is Handles. I can do -print-alias-sets, and that prints something, but I don't think it's the result of the Andersen analysis. Because when I do commands with --cfl-anders-aa taken out, I st...

...or<, 12>`, but a >> histogram Pete ran shows that half of DIEs have 2 or fewer values, >> and 85% have 4 or fewer values. We're paying for 12 (!) upfront >> right now for each DIE. Instead, we should optimize for 2-4 >> DIEValues. Not sure whether a std::forward_list would suffice, or if >> we should do something fancy like: >> >> struct List { >> DIEValue Values[2]; >> PointerIntPair<List *, 1> NextAndSize; >> }; >> >> Either way we should move the allocations to a BumpPtrA...

...-arm/include/c++/v1/./cinttypes > -- Installing: > /home/cschen/test/libcxx-scripts/out-arm/include/c++/v1/./limits > -- Installing: > /home/cschen/test/libcxx-scripts/out-arm/include/c++/v1/./type_traits > -- Installing: > /home/cschen/test/libcxx-scripts/out-arm/include/c++/v1/./forward_list > -- Installing: > /home/cschen/test/libcxx-scripts/out-arm/include/c++/v1/./sstream > -- Installing: > /home/cschen/test/libcxx-scripts/out-arm/include/c++/v1/./cwchar > -- Installing: > /home/cschen/test/libcxx-scripts/out-arm/include/c++/v1/./stack > -- Installing: > /hom...

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

Inline George > On Jan 26, 2015, at 1:05 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > George, given that, can you just build constexpr handling (it's not as easy as you think) as a separate funciton and have it use it in the right places? Will do. :) > FWIW, my current list of CFLAA issues is: > > 1. Unknown values (results from ptrtoint, incoming

George, given that, can you just build constexpr handling (it's not as easy as you think) as a separate funciton and have it use it in the right places? FWIW, my current list of CFLAA issues is: 1. Unknown values (results from ptrtoint, incoming pointers, etc) are not treated as unknown. These should be done through graph edge (so that they can be one way, otherwise, you will unify

...----===// + #include "StratifiedSets.h" #include "llvm/ADT/BitVector.h" #include "llvm/ADT/DenseMap.h" @@ -46,6 +47,7 @@ #include "llvm/Support/ErrorHandling.h" #include <algorithm> #include <cassert> +#include <memory> #include <forward_list> #include <tuple> @@ -220,12 +222,13 @@ public: if (LocA.Size == LocB.Size) { return MustAlias; } else { - return PartialAlias; + return MayAlias; } } // Comparisons between global variables and other constants should be // ha...