search for: addbit

Displaying 6 results from an estimated 6 matches for "addbit".

Did you mean: oddbit
2012 Feb 18
3
[LLVMdev] We need better hashing
...alues is inherently unstable. > > This makes perfect sense. > > It should, as the comment was copied verbatim from FoldingSetNodeID :) > + /// Add an ArrayRef of arbitrary data. > + template<typename T> > + GeneralHash& add(ArrayRef<T> ArrayVal) { > + addBits(ArrayVal.begin(), ArrayVal.end()); > + return *this; > + } > > Doesn't this have the same host-specificity problem, except that it will > cause things that *are* stable to vary, such as arrays of char, or is the > alignment check enough? > > I thought about whether...
2012 Feb 17
0
[LLVMdev] We need better hashing
...endianness that + /// depend on the host. It doesn't matter however, because hashing on + /// pointer values is inherently unstable. This makes perfect sense. + /// Add an ArrayRef of arbitrary data. + template<typename T> + GeneralHash& add(ArrayRef<T> ArrayVal) { + addBits(ArrayVal.begin(), ArrayVal.end()); + return *this; + } Doesn't this have the same host-specificity problem, except that it will cause things that *are* stable to vary, such as arrays of char, or is the alignment check enough? + /// Add a float + GeneralHash& add(float Data) { It i...
2012 Feb 18
0
[LLVMdev] We need better hashing
On Feb 18, 2012, at 1:11 AM, Talin wrote: > + /// Add an ArrayRef of arbitrary data. > + template<typename T> > + GeneralHash& add(ArrayRef<T> ArrayVal) { > + addBits(ArrayVal.begin(), ArrayVal.end()); > + return *this; > + } > > Doesn't this have the same host-specificity problem, except that it will cause things that *are* stable to vary, such as arrays of char, or is the alignment check enough? > > I thought about whether it would...
2012 Feb 17
4
[LLVMdev] We need better hashing
...uple of things I don't like: First, there's too many levels of inlined function calls - my experience is that compilers aren't as good at inlining nested calls as is often advertised, however I couldn't figure out a way to get the same effect without the nested calls. Similarly the addBitsImpl helper types are a little too complex and magical for my taste, but again I couldn't think of a better way to automatically detect whether to use the aligned vs. unaligned hashing routine. On Wed, Feb 15, 2012 at 12:01 PM, Chris Lattner <clattner at apple.com> wrote: > On Feb 14...
2008 May 23
0
[PATCH] x86/paravirt: add pte_flags to just get pte flags
...pte) & _PAGE_GLOBAL; + return pte_flags(pte) & _PAGE_GLOBAL; } static inline int pte_exec(pte_t pte) { - return !(pte_val(pte) & _PAGE_NX); + return !(pte_flags(pte) & _PAGE_NX); } static inline int pte_special(pte_t pte) @@ -304,7 +304,7 @@ return __pgprot(preservebits | addbits); } -#define pte_pgprot(x) __pgprot(pte_val(x) & ~PTE_MASK) +#define pte_pgprot(x) __pgprot(pte_flags(x) & ~PTE_MASK) #define canon_pgprot(p) __pgprot(pgprot_val(p) & __supported_pte_mask)
2008 May 23
0
[PATCH] x86/paravirt: add pte_flags to just get pte flags
...pte) & _PAGE_GLOBAL; + return pte_flags(pte) & _PAGE_GLOBAL; } static inline int pte_exec(pte_t pte) { - return !(pte_val(pte) & _PAGE_NX); + return !(pte_flags(pte) & _PAGE_NX); } static inline int pte_special(pte_t pte) @@ -304,7 +304,7 @@ return __pgprot(preservebits | addbits); } -#define pte_pgprot(x) __pgprot(pte_val(x) & ~PTE_MASK) +#define pte_pgprot(x) __pgprot(pte_flags(x) & ~PTE_MASK) #define canon_pgprot(p) __pgprot(pgprot_val(p) & __supported_pte_mask)