Displaying 7 results from an estimated 7 matches for "fastish".
Did you mean:
fastis
2008 Nov 11
2
[LLVMdev] Validating LLVM
Lately our random C program generator has seemed quite successful at
catching regressions in llvm-gcc that the test suite misses. I'd suggest
running some fixed number of random programs as part of the validation
suite. On a fastish quad core I can test about 25,000 programs in 24
hours. Our hacked valgrind (which looks for volatile miscompilations) is
a bottleneck, leaving this out would speed up the process considerably.
We've never tested llvm-gcc for x64 using random testing, doing this would
likely turn up a nice...
2008 Nov 11
0
[LLVMdev] Validating LLVM
...onday 10 November 2008 22:17, John Regehr wrote:
> Lately our random C program generator has seemed quite successful at
> catching regressions in llvm-gcc that the test suite misses. I'd suggest
> running some fixed number of random programs as part of the validation
> suite. On a fastish quad core I can test about 25,000 programs in 24
The problem with random tests is that they're just that -- random. You can't
have a known suite to validate with. Now, if we gbenerate some tests
that cause things to fail and then add those to the LLVM test suite, I'd be
all for it....
2008 Nov 11
0
[LLVMdev] Validating LLVM
On Nov 10, 2008, at 12:59 PM, David Greene wrote:
> I've written up a detailed proposal and attached it to this message.
Yeah, mirrors in many ways something I've thought about for a while
now. Roughly, cron (or while :; do) testers that figure out quality
and create tags when that quality is met. Release branching can then
just happen from the `prerelease' tag, and largely
2019 Nov 07
0
[PATCH v2 02/15] mm/mmu_notifier: add an interval tree notifier
...spin_unlock(&mmn_mm->lock);
>>> + return;
>>> + }
>>> +
>>> + mmn_mm->invalidate_seq++;
>>
>> Is this the right place for an assertion that this is now an even value?
>
> Yes, but I'm reluctant to add such a runtime check on this fastish path..
> How about a comment?
Sure.
>
>>> + need_wake = true;
>>> +
>>> + /*
>>> + * The inv_end incorporates a deferred mechanism like
>>> + * rtnl_lock(). Adds and removes are queued until the final inv_end
>>
>> Let me point out...
2019 Nov 07
1
[PATCH v2 02/15] mm/mmu_notifier: add an interval tree notifier
...ting(mmn_mm)) {
> > + spin_unlock(&mmn_mm->lock);
> > + return;
> > + }
> > +
> > + mmn_mm->invalidate_seq++;
>
> Is this the right place for an assertion that this is now an even value?
Yes, but I'm reluctant to add such a runtime check on this fastish path..
How about a comment?
> > + need_wake = true;
> > +
> > + /*
> > + * The inv_end incorporates a deferred mechanism like
> > + * rtnl_lock(). Adds and removes are queued until the final inv_end
>
> Let me point out that rtnl_lock() itself is a one-liner...
2008 Nov 10
10
[LLVMdev] Validating LLVM
Back during the LLVM developer's meeting, I talked with some of you about a
proposal to "validate" llvm. Now that 2.4 is almost out the door, it seems a
good time to start that discussion.
I've written up a detailed proposal and attached it to this message. The goal
is to ease LLVM use by third parties. We've got consideral experience with
LLVM and the community
2019 Nov 07
5
[PATCH v2 02/15] mm/mmu_notifier: add an interval tree notifier
On 10/28/19 1:10 PM, Jason Gunthorpe wrote:
...
> include/linux/mmu_notifier.h | 98 +++++++
> mm/Kconfig | 1 +
> mm/mmu_notifier.c | 533 +++++++++++++++++++++++++++++++++--
> 3 files changed, 607 insertions(+), 25 deletions(-)
>
> diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
> index 12bd603d318ce7..51b92ba013ddce