similar to: [LLVMdev] Integer divide by zero

On 4/5/2013 1:23 PM, Cameron McInally wrote: > Hey guys, > > I'm learning that LLVM does not preserve faults during constant > folding. I realize that this is an architecture dependent problem, but > I'm not sure if it's safe to constant fold away a fault on x86-64. > > A little testcase: > > #include <stdio.h> > > int foo(int j, int d) { >

On Fri, Apr 5, 2013 at 2:40 PM, Joshua Cranmer 🐧 <Pidgeot18 at gmail.com>wrote: ... > Per C and C++, integer division by 0 is undefined. That means, if it > happens, the compiler is free to do whatever it wants. It is perfectly > legal for LLVM to define r to be, say, 42 in this code; it is not required > to preserve the fact that the idiv instruction on x86 and x86-64 will

On Apr 5, 2013, at 1:42 PM, Cameron McInally <cameron.mcinally at nyu.edu> wrote: > On Fri, Apr 5, 2013 at 2:40 PM, Joshua Cranmer 🐧 <Pidgeot18 at gmail.com> wrote: > ... > Per C and C++, integer division by 0 is undefined. That means, if it happens, the compiler is free to do whatever it wants. It is perfectly legal for LLVM to define r to be, say, 42 in this code; it is

On Fri, Apr 5, 2013 at 1:42 PM, Cameron McInally <cameron.mcinally at nyu.edu>wrote: > This is quite a conundrum to me. Yes, I agree with you on the C/C++ > Standards interpretation. However, the x86-64 expectations are orthogonal. > I find that other compilers, including GCC, will trap by default at high > optimization levels on x86-64 for this test case. Hardly scientific, but

Hey again, I have a nagging thought that my past comments may not have enough meat to them. So... On Mon, Apr 8, 2013 at 12:01 PM, Cameron McInally <cameron.mcinally at nyu.edu>wrote: ... > I was just writing Chandler about a similar implementation. With my > current understanding of the problem, my constant division will end up as > either a trap call or a load of an undefined

Ah, my mistake. So this already works. I guess that bug is out of date, since this feature works already. -- John Harrison On Wed, Feb 6, 2013 at 10:00 AM, Joshua Cranmer <pidgeot18 at gmail.com> wrote: > On 2/6/2013 11:43 AM, John Harrison wrote: > >> The way `-ftest-coverage -fprofile-arcs` works at the moment it only >> flushes via `atexit()`. This patch allows you

On 6/21/2012 1:21 PM, Douglas Gregor wrote: > > On Jun 20, 2012, at 5:13 PM, Nick Lewycky <nlewycky at google.com > <mailto:nlewycky at google.com>> wrote: > >> Is there anybody who is certain that our autoconf dependency needs to >> stay around? Are there developers stuck on systems that don't have a >> recent enough cmake in their most recent

Why does __gcov_flush only flush the current compilation unit? For gcc __gcov_flush flushes all of the loaded files. Is there a way to have __gcov_flush flush everything? -- John Harrison On Wed, Feb 6, 2013 at 10:24 AM, John Harrison <ash.gti at gmail.com> wrote: > Ah, my mistake. So this already works. I guess that bug is out of date, > since this feature works already. >

On Fri, Apr 5, 2013 at 6:49 PM, Joe Groff <arcata at gmail.com> wrote: ... The platform is irrelevant; division by zero is undefined, and compilers > are allowed to optimize as if it can't happen. > Understood. I don't mean to nag, but I'm not arguing which is [more] correct: the Standards or the platform. Both have their own merits. At least to me they both have merits.

Thank you. The edit made no difference. I did a clean install and the same error is reported. Any other suggestions? regards, Ashwin On Aug 21, 2012, at 2:59 PM, Joshua Cranmer <pidgeot18 at gmail.com> wrote: > On 8/21/2012 3:52 PM, Ashwin kumar wrote: >> Hi everyone, >> >> This is Ashwin. I have a mac running osx 10.8. I am new to LLVM and have the version 3.1

On 3/12/2013 11:55 AM, James Courtier-Dutton wrote: > I already know how to handle the case you describe. > I am not converting ASM to LLVM IR without doing quite a lot of analysis first. > 1) I can already tell if a register is refering to a pointer or an > integer based on how it is used. Does it get de-referenced or not? So, > I would know that "p" is a pointer. What if

On Apr 5, 2013, at 8:02 PM, Cameron McInally <cameron.mcinally at nyu.edu> wrote: > I'm less concerned about "where" the trap happens as I am about "if" it happens. For example, a Fortran program with division-by-zero is, by the Standard, non-conforming. Pragmatically, not a Fortran program. Rather than wrong answers, I would like to see a hard error indicating

Yikes! It only flushes the counts for the current compilation unit? That sounds like a terrible bug. Can you file a bugzilla report, please? On Feb 6, 2013, at 12:05 PM, John Harrison <ash.gti at gmail.com> wrote: > Why does __gcov_flush only flush the current compilation unit? For gcc __gcov_flush flushes all of the loaded files. > > Is there a way to have __gcov_flush flush

On Oct 23, 2012, at 6:22 PM, Joshua Cranmer <pidgeot18 at gmail.com> wrote: > On 10/23/2012 1:58 PM, John Criswell wrote: >> Dear All, >> >> I'm enhancing a MachineFunctionPass that enforces control-flow integrity. One of the things I want to do is to set the alignment of an instruction (by adding NOPs before it in the MachineBasicBlock or by emitting an alignment

A division intrinsic with defined behavior on all arguments would be awesome! Thanks for considering this. On Sat, Apr 6, 2013 at 11:27 AM, Joe Groff <arcata at gmail.com> wrote: > On Saturday, April 6, 2013, Jeff Bezanson wrote: >> >> >> Presumably the optimizer benefits from taking advantage of the >> undefined behavior, but to get a consistent result you need

On 4/29/2013 9:13 AM, Jovi Zhang wrote: > We arrived the key part: offsetof and sizeof are resolved to a > constant by Clang before they are lowered to LLVM IR, so that's the > main reason why there have a high-level IR file except LLVM IR file, > that high-level IR file contain unresolved structure field reference > info and unresolved sizeof, that high-level IR file

Have you tried to pass --enable-shared to configure? It works for me. $ opt -load /usr/local/lib/LLVMHello.dylib -help | grep hello -hello - Hello World Pass -hello2 - Hello World Pass (with getAnalysisUsage implemented) - xi On Aug 21, 2012, at 5:55 PM, Ashwin kumar <ashwinkumar18 at gmail.com> wrote: >

On 12 March 2013 16:39, Óscar Fuentes <ofv at wanadoo.es> wrote: > > This is not possible, except for specific cases. > > Consider this code: > > long foo(long *p) { > ++p; > return *p; > } > > The X86 machine code would do something like > > add %eax, 4 > > for `++p', but for x86_64 it would be > > add %rax, 8 > > But you

On Saturday, April 6, 2013, Jeff Bezanson wrote: > > Presumably the optimizer benefits from taking advantage of the > undefined behavior, but to get a consistent result you need to check > for both zero and this case, which is an awful lot of checks. Yes they > will branch predict well, but this still can't be good, for code size > if nothing else. How much performance can

Does anyone know of any loop strip-mining passes implemented in LLVM? -- Joshua Cranmer News submodule owner DXR coauthor