similar to: Getting consistent block frequency information

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. >

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

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

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 to flush the coverage at > any point by calling `__llvm_gcov_flush` the same way `__gcov_flush` > works for gcc. > > If there is another way of doing this, I might of missed it but I was > looking for

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 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 installed. I am trying to get some LLVM transform > passes running on my machine. After having compiled the LLVM source > without making changes to the configuration files I am able to run the > LLVM gcc and clang. But I am

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: >

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 1/2/2013 11:05 AM, Tom Roeder wrote: > Hi, > > I'm currently writing an opt module for fast indirect call checks > using a table of allowed indirect call targets. The code replaces > function pointers with offsets into the table then masks the offset > for the table size and restores the function pointer before the call. > I have some ways of dealing with some kinds of

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 directive to the assembler) if it causes a > specific sequence of bytes to be

On 6/15/2012 8:12 PM, Mikael Lyngvig wrote: > > Not having an AV or swithching it off at times is not a sign of > stupidity. The best antivirus is a mindful, knowledgeable user. > And the > antivirus doesn't really protect you in case of risky behavior. > > > I couldn't have said it better myself. I've had three viruses in 29 > years and

On 4/24/2012 1:50 PM, Justin Holewinski wrote: > > Hi LLVMers, > > We at NVIDIA would like to contribute back to the LLVM open-source > community by up-streaming the NVPTX back-end for LLVM. This back-end > is based on the sources used by NVIDIA, and currently provides > significantly more functionality than the current PTX back-end. Some > functionality is currently

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

On 11/23/2013 12:18 AM, Mikael Lyngvig wrote: > Thanks, you have a lot of valid points there. I have myself long ago > abandoned the path of using C as a backend language due to the very > factors you mention. > > However, as I said, the document was put together in 30 minutes. Not > exactly ready for prime time :-) > > I do agree that all of the things you mention

Thanks for the followup. If I understand the suggestion correctly, this doesn't solve the problem of building a jump table to call into other functions, since, as you note, indirectbr can only call into blocks in the same function. Is the conclusion then that there is no way to do this in LLVM IR? It looks like these kind of restrictions (no branching between functions and no instructions

For a pass that we're implementing, we want to do symbolic evaluation of LLVM values as if certain intrinsics were given constants. The scalar evolution pass already lets us compute these values for loop iterations, but it still doesn't let us do it if the SCEV in question corresponds to an IntrinsicInst. It seems that the easiest way to do this is to modify the IR to replace the

On 8/27/2012 9:57 PM, Hongbin Zheng wrote: > I think the C backend also allow people performing source-to-source > transform with LLVM (instead of Clang). I do not believe that this would be the case nor that it should be a goal. Source-to-source transformation requires a lot of accurate information about the AST, and conversion to LLVM IR is way too lossy. Signedness, for example, is

On 9/17/2012 11:59 AM, Yiannis Tsiouris wrote: > Hi all, > > I recently updated my LLVM tree and I have a strange issue with the use > of blockaddress. The LLVM file that I try to compile is [1]. Taking the address of a block by itself has zero guarantees about whether or not that block will exist by the time the code is emitted. If the block no longer exists by the end, it gets

On 11/14/2012 2:22 AM, Shuxin Yang wrote: > I do some google, I cannot find the answer... > I check C std, I cannot find answer either. The C++11 standard explicitly allows compilers to assume that all loops will eventually terminate: [intro.multithread] 24: The implementation may assume that any thread will eventually do one of the following: — terminate, — make a call to a library I/O

On 12/3/2012 3:09 PM, R P Herrold wrote: > Yes, actually, I did -- it boils down to: it's old, and Python 3 is > coming Python 3.x is being made the default version of python on some systems, so getting python 2.x/3.x concurrent compatibility will probably be imminently needed. From experience, Python 2.4/Python 3.x concurrent compatibility is just plain impossible. Also, I will