similar to: [LLVMdev] Issues in compiler-rt __truncdfsf2 and __extendsfdf2 functions?

On Jun 12, 2012, at 7:20 AM, Jordy Potman <jordy.potman at recoresystems.com> wrote: > > So in the volatile case the latency of the chain dependency is 0, while > in the non volatile case it is 1. > > I am using ScheduleDAGInstrs in a scheduler for a VLIW target and in the > volatile case the load gets incorrectly scheduled in the same cycle as > the store. Is

Hi all, I have a question regarding the latency of the true dependency of a store followed by an aliased load in ScheduleDAGInstrs. The latency seems to depend on the store and load being volatile or not as can be seen in the post-RA-sched debug output of the attached ARM example: $ llc -O3 -debug-only=post-RA-sched store_load_latency_test.ll ... SU(2): STRi12 %R2<kill>,

Hi all, llvm-test fails on me in the first test (and many subsequent tests, but I hope that fixing the first test will allow me to continue). I see syntax errors from the C compiler and core dumps from llc. Is any of this supposed to happen? This is still on my amd64 machine. However, the build process is using the right incantation to compile (gcc-4.2 -m32 -Wl,-melf_i386). The llvm-gcc

On Oct 24, 2015, at 6:02 PM, Chris Lattner <clattner at apple.com> wrote: > > >> On Oct 23, 2015, at 7:43 PM, Matthew Fernandez via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> On 21/10/15 00:15, Stephen Canon wrote: >>> Yup, this is UB. If you want to propose a patch, I would do something like the following: >>> >>> rep_t sign

Thanks for the confirmation, Steve. Your suggestion looks good to me, but I don't have an environment set up to build the test suite so it may take me a little while to get back to you with a validated patch. A bit of creative grepping yields the following that also look problematic to me: compiler-rt/test/builtins/Unit/absvsi2_test.c: expected = -expected;

On 26/10/15 02:54, Joerg Sonnenberger wrote: > On Sun, Oct 25, 2015 at 06:46:48AM -0400, Steve Canon via llvm-dev wrote: >> On Oct 24, 2015, at 6:02 PM, Chris Lattner <clattner at apple.com> wrote: >>> >>> >>>> On Oct 23, 2015, at 7:43 PM, Matthew Fernandez via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>>>> On 21/10/15 00:15,

Hi all, Thanks for your feed-backs :-) @Andrew: In fact, I've reused most of the postRA list scheduler code and the resource priority queue. Every time it needs to move forward, either because of a res hazard (HazardRec) or an invalid combination of instructions in the current packet (DFA), it closes the current bundle and advances to the next cycle. The non-interlocked nature of our

>>>>> Florent Angly <florent.angly at gmail.com> >>>>> on Tue, 20 Dec 2016 13:26:36 +0100 writes: > Hi all, > I have noticed incorrect parsing of very small hexadecimal numbers > like "0x1.00000000d0000p-987". Such a hexadecimal representation can > can be produced by sprintf() using the %a flag. The return value is

Hi, In ConvergingScheduler::checkResourceLimits on line 1535 of MachineScheduler.cpp setLatencyPolicy is called as follows: // Set ReduceLatency to true if needed. Bot.setLatencyPolicy(TopCand.Policy); Top.setLatencyPolicy(BotCand.Policy); So the Bot scheduling boundary is used to set the latency policy of the Top candidate and the other way around. I think this should be: //

TB --- 2013-10-31 19:50:43 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2013-10-31 19:50:43 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-10-31 19:50:43 - starting RELENG_10 tinderbox run for i386/pc98 TB --- 2013-10-31 19:50:43 - cleaning the

Hi, I am trying to get icecast running on a ARM processor. I have managed to cross compile all of the required libraries (libxml2, libxslt, libogg, libvorbis, etc.). However I am bumping up against a problem that I can't find any info on. Here is the generated output from the icecast build. I was wondering if any of you has seen this and knows of a fix. I apologize if the problem is obvious

I noticed some odd behavior with APFloat's convertFromString method. 1. If I pass the hex representation of the closest value to 0.1 (0x19999Ap-24), everything is fine and opOk is returned. However, if I pass the same value as a decimal string (0.10000002384185791015625), opInexact is set. 2. On the lower end of the scale, the smallest denormal 0x1p-149 returns opOk, but the

Hi, I recently came across the following in __floatsidf in compiler-rt: __floatsidf(int a) { ... if (a < 0) { ... a = -a; In the case where a == INT_MIN, is this negation not undefined behaviour? AIUI this function is used for software emulation on targets that have no hardware floating point support. Perhaps there is an in-built assumption

Hi all, I have noticed incorrect parsing of very small hexadecimal numbers like "0x1.00000000d0000p-987". Such a hexadecimal representation can can be produced by sprintf() using the %a flag. The return value is incorrectly reported as 0 when coercing these numbers to double using as.double()/as.numeric(), as illustrated in the three examples below:

I stumbled onto this working on an update to coxph. The last 6 lines below are the question, the rest create a test data set. tmt585% R R version 2.12.2 (2011-02-25) Copyright (C) 2011 The R Foundation for Statistical Computing ISBN 3-900051-07-0 Platform: x86_64-unknown-linux-gnu (64-bit) # Lines of code from survival/tests/singtest.R > library(survival) Loading required package: splines

Hi, LLVM. I have a question I'd like to get put into the official style guidelines: do we prefer NULL or 0 for C++ objects? I've seen both throughout the code. Personally I prefer NULL, since it establishes that something is a pointer and not an integer (or integer-constructed object, but thankfully we avoid implicit conversions in LLVM/Clang). But I think I read somewhere that 0 is more

What I can think of: 1. Anonymous struct, to avoid a copy. 2. Use stdarg.h...dangerous but accomplishes what you're looking for. 3. Split up F: giant switch statements often indicate that your function is doing several different things. (IMHO...) 4. Don't worry about it, it's probably not a bottleneck. (Or rather, profile first...) But no, there's no standard way to do this. Even