search for: dpnes

...email addresses? > > I suspect designing away these failures would fix most of the > problems. > > Since the purpose of this Phab instance is to support on-list reviews, > we should make it hard to get that wrong (even if it means making > off-list reviews harder). > > -- dpnes

Hi, I wrote a pass in LLVM and would like to test it on the programs in LLVM test-suite. To be specific, I would like to get the stats upon running my pass on these programs. What are the commands to run my pass on the test suite? -- Rekha -------------- next part -------------- An HTML attachment was scrubbed... URL:

...oat`) and we can remove hard-floats entirely by using these classes as drop-in replacements. The long-term answer (for most passes) is mapping to `uint64_t`, but this gets rid of undefined behaviour *now*, and provides a simple and practical alternative to hard-floats going forward. Thoughts? -- dpnes

...res would fix most of the >> > problems. >> > >> > Since the purpose of this Phab instance is to support on-list reviews, >> > we should make it hard to get that wrong (even if it means making >> > off-list reviews harder). >> > >> > -- dpnes >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > > _______________________________________________ > LLVM...

On 25/06/2014 21:18, Eli Bendersky wrote: > > > > On Wed, Jun 25, 2014 at 11:10 AM, Alp Toker <alp at nuanti.com > <mailto:alp at nuanti.com>> wrote: > > > On 25/06/2014 21:03, Eli Bendersky wrote: > > On Wed, Jun 25, 2014 at 10:44 AM, Alp Toker <alp at nuanti.com > <mailto:alp at nuanti.com> <mailto:alp at nuanti.com

...as drop-in replacements. The long-term answer (for most > > passes) is mapping to `uint64_t`, but this gets rid of undefined > > behaviour *now*, and provides a simple and practical alternative to > > hard-floats going forward. > > > > Thoughts? > > > > -- dpnes > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developer...

On Jun 18, 2014, at 1:20 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > I'm certainly not suggesting this would be better in general than IEEE 754. > > But I think it's suitable for the sorts of places we currently use > hard-floats. I guess you (and Philip) are saying there are dragons here? Numerical analysis is hard. Every numerics expert I have

Sorry if I was unclear. There are currently no “known incompatibilities” that I am aware of, although I fully admit to not being an expert on the topic. The idea is that we add versioning information to the bitcode so that if an issue were discovered, it could be easily detected and dealt with. Douglas Yung From: Bob Wilson [mailto:bob.wilson at apple.com] Sent: Friday, September 26, 2014 16:39

Dear all, The below has been tested quite thoroughly by now, including performance-testing by the way of using a modified compiler that triggers the below while compiling at least an old part of LLVM ["Function.cpp"] and sorting a symbol table with >7000 global variables. Unfortunately, the optimization I have been working on for which I _thought_ I needed the ability to sort a

...nsformation pass (`bool` representing "did-change") was useful. Are there any others? Is the API using `PreservedAnalyses::all()` as a stand-in for "did-not-change"? If so, does that conflict with adding more nuanced API for on-the-fly invalidation of analyses? -- dpnes [1]: http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-June/073767.html [2]: http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-June/073785.html

Hi Duncan, I came across something like the following recently which I guess might be related to your recent work. Any ideas? $ clang++-tot -cc1 crash_on_invalid.cpp -g -emit-obj -fexceptions -fcxx-exceptions crash_on_invalid.cpp:13:1: error: C++ requires a type specifier for all declarations x; ^ 1 error generated. *** Error in `clang++-tot': corrupted double-linked list: 0x000000000754f340