similar to: Llvm-mca library.

Hi Lorenzo, I’ll answer the first question you have: > I would like to use llvm-mca to estimate the IPC of a given code region. I am interested in the library version

Hi Sjoerd, On Fri, May 3, 2019 at 8:19 AM Sjoerd Meijer via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > I read that out-of-order cores are supported. How about in-order cores? > Would it be easy/difficult to add support for that? > > Cheers, > Sjoerd. > > I don't think that it would be difficult to support in-order superscalar cores. However, it would

Hi, In sanitizer code we have two notions of stack unwinders: fast and slow. [1] In the context of sanitizers, stack unwinding is most often for printing error reports that include a stack trace. I am currently trying to fix an issue that is related to some platforms (Darwin) only supporting the fast unwinder, but calling code not being aware of that possibility. My mental model was that

Thank you for the explanation, Ben! I realized I didn’t give enough context for my question: As you noted, the slow/fast unwinder can only do its work if there is enough (runtime) information. Otherwise stack printing usually does exactly what you suggested: printing the one frame corresponding to the recent pc. When I asked if “platforms are required to at least support one kind of unwinder” I

Judging by this path: needed by 'tools/lld/Common/VCSVersion.inc' It looks to me like this is **not** a monorepo layout (if it were, lld would not appear in the tools directory). Therefore the LLVM_ENABLE_PROJECTS=lld is not even doing anything. I don't know how to build without a monorepo these days, and I also don't know what the most recent guidance setting up a monorepo is,

I tried deleting my build directory and restarting from scratch $ cd llvm-project $ mkdir build && cd build $ cmake -G "Unix Makefiles" -DLLVM_ENABLE_PROJECTS=lld ../llvm $ make I got this error: make[2]: *** No rule to make target 'llvm/cmake/modules/GenerateVersionFromVCS.cmake', needed by 'tools/lld/Common/VCSVersion.inc'. Stop. CMakeFiles/Makefile2:57166:

I haven't tried it on RaspberryPi, but if there's some specific Tripp Lite information I can help with, let me know. David Zomaya Tripp Lite ________________________________ From: Nut-upsuser <nut-upsuser-bounces+david_zomaya=tripplite.com at alioth-lists.debian.net> on behalf of Charles Lepple <clepple at gmail.com> Sent: Sunday, December 8, 2019 8:36 PM To: Layne Fowler

Looks like I have run into the same issue reported in: https://bugs.llvm.org/show_bug.cgi?id=20871 Is there a fix or work-around for it? The bug report seems to be still open. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171005/46c1282d/attachment.html>

Hi, we at Arm have noticed that assembly can differ when compiling for AArch64 depending on whether debug information is generated or not. The issue is reproducible for the following small example compiled with `-O1` for `aarch64-arm-linux-gnu`: a() { b(a); for (;;) c("", b); } The reason for the difference is that AArch64 frame lowering emits CFI

Thought I'd follow up in case someone else runs into this issue. In the end what worked for me was tweaking the udev rules. I have had no USB disconnects or stale data warnings so far. I only used one rule for my UPS: # /etc/udev/rules.d/62-nut-usbups.rules SUBSYSTEM!="usb", GOTO="nut-usbups_rules_end" # TrippLite # e.g. TrippLite SMART1500LCD - usbhid-ups

See https://reviews.llvm.org/D63036 for the full patch and description. Essentially, the Constant::canTrap API is going away. To make this work, the semantics of division and remainder constant expressions are changing slightly, so division by zero produces poison, not undefined behavior. (The corresponding instructions still have undefined behavior.) This change should make writing and

Hi Graham, Thanks for sharing this. Are you planning on enabling the pass only on PGO? Even in non-PGO, I noticed some performance gains when we are aggressive in partially inlining the early return part, especially when the callee spill CSRs in the entry block. At a high level, I have two questions: 1. What is the main obstacle that prevent the pass from being enabled by default? 2.

All: There will be a BoF talk at the EuroLLVM conference regarding Numerics (FMF and module flags which control fp behavior and optimization). Even if you are not going to be in attendance, please reply to this thread as we are collecting open issues and ideas for future direction in all layers of LLVM for which optimizations are controlled by numerics flags. Please read over the numerics blog

Charles, thank you for that link to David's earlier message. I tried adding those udev rules and changing the pollinterval. I need to do some tinkering but I don't think the part RUN+="/sbin/upsdrvctl stop; /sbin/upsdrvctl start" is working right. If I manually run the commands then the USB disconnects stop and there are no kernel messages. Running "sudo /lib/nut/usbhid-ups

On 12/8/19 8:18 PM, David Zomaya wrote: > > I haven't tried it on RaspberryPi, but if there's some specific Tripp > Lite information I can help with, let me know. > We had that discussion about the SMART1500LCDT  & USB a long time ago:-( I bought mine in 2013 (still going strong on the second set of batteries) and in August 2016 we had some discussions about the USB

Thanks Marco, I may try this if I can't get David's udev rules to work. On Mon, Dec 9, 2019 at 12:58 AM Marco Walther <marco at sonic.net> wrote: > On 12/8/19 8:18 PM, David Zomaya wrote: > > I haven't tried it on RaspberryPi, but if there's some specific Tripp Lite > information I can help with, let me know. > > We had that discussion about the

My UPS is connected to a Raspberry Pi by USB. After a few hours of working, the service fails. Looking at kernel messages I noticed that the device is repeatedly disconnecting and reconnecting. I have tried using a different USB port and using a brand new USB cable. I have not had success by changing config parameters like pollfreq/pollinterval/etc. What is causing the UPS to keep disconnecting?

Hi *, when I try to start this config kernel = "/boot/vmlinuz-2.6.11-xenU" memory = 128 name = "Virtual1" vif = [ ''mac=aa:00:00:00:00:11, bridge=xen-br0'' ] disk = [ ''phy:vg00/domu01_lv,sda1,w'' ] root = "/dev/sda1 ro" extra = "4" I get this errors in xend.log (tried two times): [2005-05-23 13:37:22 xend] INFO