similar to: [LLVMdev] idempotence

Hi all, Just a quick question about the idempotence of an intrinsic function. Is there a way to specify that an intrinsic function is idempotent? I am trying to give as much information about the intrinsic function I added to LLVM so that LLVM can do optimizations otherwise disabled. Thanks a lot in advance. Bin

As part of PhD research I integrated support for code generation of idempotent (re-executable) code regions into LLVM, along with a supporting IR-level analysis to identify and demarcate large "semantically" idempotent regions [1]. Some have expressed interest the code, so here is a link that contains some documentation and pointers to the source hosted on GitHub:

Hey that is great to hear that the volatile stuff is helping someone. Just broadly speaking do you know if the instcombine bug involves pointer code vs. scalar? I ask because intensive random testing has not found the bug that you are seeing. That says that either (1) the bug lies in a part of the program space we don't explore or (2) it does, but we haven't run the tests for long

On Mon, Nov 24, 2008 at 10:51 AM, John Regehr <regehr at cs.utah.edu> wrote: >> was wrong. At the time (~ 1 year ago) it was almost always >> instcombine and almost always volatile related. Now bugpoint has some >> ways to run the code by some external agent which I haven't >> investigated yet. > > People have fixed a ton of bugs (volatile and otherwise)

LLVM doesn't know about any of this C/C++ specific stuff. If g++ do something (such as the load), so will llvm-g++. I'd suggest you send this to the clang mailing list. BTW, this issue is very interesting. I've never used C++ for embedded systems so never realised this difference. On Sat, Mar 6, 2010 at 1:47 AM, John Regehr <regehr at cs.utah.edu> wrote: > The question is,

On 07/22/2015 01:28 PM, Sean Silva wrote: > > > On Wed, Jul 22, 2015 at 12:54 PM, Hal Finkel <hfinkel at anl.gov > <mailto:hfinkel at anl.gov>> wrote: > > One thing that is important to consider is where in the pipeline > these kinds of optimizations fit. We normally try to put the IR > into a canonical simplified form in the mid-level optimizer.

One thing that is important to consider is where in the pipeline these kinds of optimizations fit. We normally try to put the IR into a canonical simplified form in the mid-level optimizer. This form is supposed to be whatever is most useful for exposing other optimizations, and for lowering, but only in a generic sense. We do have some optimizations near the end of our pipeline (vectorization,

I'm getting the error below on Ubuntu Hardy on ia32 on r55688. John make[3]: Entering directory `/home/regehr/llvm-gcc/build/gcc' gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H -I. -I. -I../../gcc

Hi Peter, On Thu, Jun 8, 2017 at 9:41 AM, Peter Lawrence <peterl95124 at sbcglobal.net> wrote: > >> On Jun 7, 2017, at 2:23 PM, Nuno Lopes <nunoplopes at sapo.pt> wrote: >> >> Since most add/sub operations compiled from C have the nsw attribute, we cannot simply restrict movement of these instructions. > > Nuno, > I’m not saying the operations

> was wrong. At the time (~ 1 year ago) it was almost always > instcombine and almost always volatile related. Now bugpoint has some > ways to run the code by some external agent which I haven't > investigated yet. People have fixed a ton of bugs (volatile and otherwise) in instcombine since then. I will be very interested to hear what pass ends up being the problem here, and

On Dec 16, 2009, at 1:26 AM, Paolo Bonzini wrote: > On 12/16/2009 03:21 AM, John Regehr wrote: >> Hopefully the results are more fair and useful now. Again, feedback is >> appreciated. > > I would also avoid testcases using volatile. Smaller code on these > testcases is often a sign of miscompilation rather than optimization. > For example, >

On Tue, Jan 26, 2010 at 12:36 PM, John Regehr <regehr at cs.utah.edu> wrote: > 2. > Sometimes not: > > http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/EC/ECC74C0C.shtml The primary issue here is that scalar evolution doesn't know how to deal with loops using "sle" for the exit condition. Shouldn't be too hard to fix now that we have overflow flags

My InlineCost refactoring has been noticed in this aspect; that may or may notbe the culprit here. A quick thing you can do is to compile with -ftime-report and compare the top few passes between versions. Dan On Oct 19, 2009, at 8:47 PM, John Regehr <regehr at cs.utah.edu> wrote: > As part of routine testing, I run clang and llvm-gcc a lot of times. > Something happened

Cool! Looks like we do lots of provably unnecessary alignment checks. :) On Tue, Nov 25, 2014 at 9:03 AM, John Regehr <regehr at cs.utah.edu> wrote: > Actually, let me save you some time by pointing out the thing that is > perhaps immediately useful about our recent work, which is the fact that > Souper now supports "optimization profiling". > > If you build an

On 12/16/2009 03:21 AM, John Regehr wrote: > Hopefully the results are more fair and useful now. Again, feedback is > appreciated. I would also avoid testcases using volatile. Smaller code on these testcases is often a sign of miscompilation rather than optimization. For example, http://embed.cs.utah.edu/embarrassing/src_harvested_dec_09/076389.c is miscompiled on GCC 3.4 and SunCC

The question is, what should C and C++ compilers do with this code? volatile int x; void foo (void) { x; } This question is not totally stupid: embedded systems use code like this when reading a hardware register has a useful side effect (usually clearing the register). It is reasonably clear that a C compiler should load from x and throw away the value. clang and llvm-gcc do

Hi, I'd like to see what parts of LLVM/Clang are being executed. I know that "make ENABLE_COVERAGE=1" used to just work, but so far (on 64-bit Ubuntu 14.04) I've had no luck building either 3.4.x or SVN head using any of Clang 3.4, Clang head, or a recent GCC. The first error that I get when building with GCC is this:

I strongly suspect pointer union and pointer int pair style classes are the source of these... But perhaps I'm wrong On Nov 26, 2014 9:29 AM, "Michael Zolotukhin" <mzolotukhin at apple.com> wrote: > John, > > That’s a great post and really interesting data, thank you! > > On Nov 25, 2014, at 9:58 AM, Reid Kleckner <rnk at google.com> wrote: > >

I'm away from my Linux machines, if this hasn't been resolved by tonight I'll send more details. THe problem in cplus-dem.c is that CPP is conditionally including code that comes when HAVE_STDLIB is not defined, including an alternate protptype for malloc() that conflicts with the existing one. This is just what causes the error I sent-- no idea what the root cause is. Thanks,

We have a bitwidth analysis that can be downloaded. It is not in LLVM. There should be a link in the paper: http://www.cs.utah.edu/~regehr/papers/pldi075-cooprider.pdf John Regehr