Displaying 6 results from an estimated 6 matches for "addbits".
Did you mean:
addr_bits
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 i...
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 is...
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)