search for: 20171003

...be appreciated. Cheers, Graham Yiu LLVM Compiler Development IBM Toronto Software Lab Office: (905) 413-4077 C2-707/8200/Markham Email: gyiu at ca.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171003/18c2b6f6/attachment.html>

...johnson at google.com 408-460-2413 | -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171003/29d9b5af/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171003/29d9b5af/attachment.gif>

...aSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=zEValqMYe9FvZq I-GQUgWPmVUgbEq8OBAjTrBjz9xhY&s=1h4Cw3vDlJBIknkn0Ts3R_e3PU64h_dyvEkyCdonAVo& e= -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171003/043a505d/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 105 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171003/043a505d/attachment.gif>

Hi, I noticed some performance gains in some spec benchmarks without significant code size bloat when aggressively performing partial inlining, especially when the original callee spill CSRs in the entry block. I guess the partial inlining is not enabled mainly due to the code size. Is there any other issue which prevent the pass from being enabled? Do we have any plan or any on-going works

...lvm pass manager to know execute all dependencies without having to specify explicitly.? I suspect i am doing something wrong in my code, May be. Thanks Mahesh -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171003/31ddc6f5/attachment.html>

..._________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171003/3a64b9eb/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171003/3a64b9eb/attachment.gif>

On Tue, Oct 3, 2017 at 12:08 PM, Davide Italiano <davide at freebsd.org> wrote: > On Tue, Oct 3, 2017 at 11:57 AM, Graham Yiu via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Hello, >> >> I recently noticed that the new pass manager was not enabled at regular/thin >> LTO link step even if '-fexperimental-new-pass-manager' was specified in the

https://bugs.freedesktop.org/show_bug.cgi?id=102352 Bug ID: 102352 Summary: nv4x fan run whole time at 100%, stable patch existing since about 1 year, please merge Product: xorg Version: unspecified Hardware: All OS: Linux (All) Status: NEW Severity: trivial Priority: medium

...tp://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > -- Kind regards, Charith Mendis Graduate Student, CSAIL, Massachusetts Institute of Technology -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171003/e71f41e6/attachment.html>

...johnson at google.com 408-460-2413 | -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171003/d89f26e7/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171003/d89f26e7/attachment.gif>

...______________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171003/795cdc9d/attachment.html>

...>> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171003/eac8aacc/attachment.html>

...n the code accessing this structure are also updated. Thank You -- Kind regards, Charith Mendis Graduate Student, CSAIL, Massachusetts Institute of Technology -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171003/827a828e/attachment.html>

The distinction between the LLVMTargetMachine and TargetMachine classes has become somewhat muddy recently. So I created: https://reviews.llvm.org/D38482 to clean things up. During review it was noted that we may rather merge the two instead which looks like this: https://reviews.llvm.org/D38489 <https://reviews.llvm.org/D38489> We really should choose one of the two over the status quo.

...>> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171003/e7903fc7/attachment-0001.html>

Solenwin at freshdesk.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/virtualization/attachments/20171003/5f06d339/attachment.html>

Solenwin at freshdesk.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/virtualization/attachments/20171003/5f06d339/attachment.html>

On 10/01/2017 06:05 PM, Sanjay Patel wrote: > Are we confident that we just need those 7 bits to represent all of > the relaxed FP states that we need/want to support? > > I'm asking because FMF in IR is currently mapped onto the > SubclassOptionalData of Value...and we have exactly 7 bits there. :) > > If we're redoing the definitions, I'm wondering if we can

On 10/02/2017 11:10 AM, Bruce Hoult via llvm-dev wrote: > Is there anything that means, in particular, "go fast, even if it > means not all bits are significant"? > > I'm currently working on an llvm-based compiler for a GPU that is > optomised for OpenGL, where 16 bit FP may not be quite accurate enough > (or may be in some cases), but 32 bit FP is overkill. A

I have some programs crashing when I upgraded from clang 3.9.1 to clang 4.0.1. Debugging this I found the reason for the crash. This is happening in the following assembly fragment for a piece of code allocating a class object (size: 24 bytes) using operator new and then initializing it: 0x00002aaaafc145f3 <+35>: callq 0x2aaaafdf5f90 <operator new(unsigned long)>