similar to: [LLVMdev] LLMV demo page

Hello, I have a simple program using aliases to functions, and it seems that the CallGraph doesn't follow these aliases. Here is the example: @alias = alias void ()* @realfunc define void @realfunc() { entry: ret void } define i32 @main() { entry: call void @alias() ret i32 0 } ******* Output of the CallGraph ******* Call graph node <<null

I think you're looking for an inter-procedural post dominator analysis. I don't think there is one in LLVM already, but it should be relatively straightforward. This gives a sound approximation (i.e. no false positives) of something sort-of equivalent to the halting problem: if the program terminates, then block Y was executed. Cheers, Scott On Tue, Oct 2, 2012 at 7:43 PM, Jim Grosbach

Is there any inter-procedural analysis that could tell me if some BasicBlock Y is guaranteed to execute based on my knowledge that BasicBlock X will execute? For example: extern int x; void foo() { } int main() { if (x) { foo(); } else { foo(); } } I want to be told that the entry block of foo is guaranteed to be

On Thu, Oct 11, 2012 at 3:56 PM, Stephen Schiffli <sschiffli at gmail.com> wrote: > Hello, I have a simple program using aliases to functions, and it seems that > the CallGraph doesn't follow these aliases. Here is the example: > > @alias = alias void ()* @realfunc > > define void @realfunc() { > entry: > ret void > } > > define i32 @main() { >

Okay thanks for the info. The term program termination was probably a poor choice of words. I'm really just trying to build an inter-procedural BasicBlock graph, and then look for postdominance as Scott suggested. I'll go about making my own since it doesn't sound like there is one out there already. Thanks, -Stephen On Tue, Oct 2, 2012 at 5:06 PM, Scott Moore <sdmoore at

Isn't this effectively the halting problem? Consider the case where block Y is the exit block of main() and block X is the entry block of main(). Jim On Oct 2, 2012, at 4:29 PM, Stephen Schiffli <sschiffli at gmail.com> wrote: > Is there any inter-procedural analysis that could tell me if some BasicBlock Y is guaranteed to execute based on my knowledge that BasicBlock X will

Hello, I am trying to compile some code to LLVM IR with a simple "__thread int x" but hitting this error: test.cpp:1:1: error: thread-local storage is unsupported for the current target I'm using both the -S and -emit-llvm options on clang, and was expecting to see "@x = thread_local global i32 0" come out of clang. I am curious why clang even cares about this since

On Aug 10, 2018, at 1:28 PM, Marshall Clow via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > * The clock stuff being added in C++20 has already been discussed here. I’ve missed the discussions on file_time_type, however I thought I should throw in my opinion here before it is too late to do anything about it. I believe it is a mistake to model file_time_type with 128 bits. It

On Sun, May 11, 2014 at 8:19 AM, Stephan Tolksdorf <st at quanttec.com> wrote: > Hi, > > When clang/LLVM can't prove that a noexcept function only contains > non-throwing code, it seems to insert an explicit exception handler that > calls std::terminate. Why doesn't clang leave it to the eh personality > function to call std::terminate when an exception is thrown

Lately I've been using some utilities to increase the number of logic errors caught at compile time. I thought they might be useful to the LLVM project. I'd appreciate feedback on the below proposal. Would the community find these useful? -David RFC: Strong typedef utilities for LLVM -------------------------------------- Abstract -------- This proposal

On 9 Feb 2017, at 08:41, Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Wed, Feb 8, 2017 at 5:45 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > What isn’t clear to me still is : why shouldn't this be transitive? > In the example you’re showing, for a caller of f() in bar, what is the advantage of knowing that f() is nounwind if it an

I am nuilding that now. CC=clang CXX=clang++ cmake -DCMAKE_INSTALL_PREFIX=$HOME/opt/llvm11-git \ -DCMAKE_BUILD_TYPE=Release \ -DBUILD_SHARED_LIBS=ON \ -DLLVM_ENABLE_EH=ON \ -DLLVM_ENABLE_RTTI=ON \ -DLLVM_HOST_TRIPLE=x86_64-pc-linux-gnu \ -DLLVM_TARGETS_TO_BUILD="AMDGPU;MSP430;WebAssembly;X86" \

Hi, Using master at b0a1c0b72c9c61f8b0a223e08f43498abb64f5e8, I cannot build LLVM. I configured with: CC=clang CXX=clang++ cmake -DCMAKE_INSTALL_PREFIX=$HOME/opt/llvm11-git \ -DCMAKE_BUILD_TYPE=Release \ -DLLVM_BUILD_LLVM_DYLIB=ON \ -DLLVM_LINK_LLVM_DYLIB=ON \ -DBUILD_SHARED_LIBS=OFF \ -DLLVM_ENABLE_EH=ON \ -DLLVM_ENABLE_RTTI=ON \

There is a fair amount of dispute and detail here, and real benchmarks can be difficult to write, because you often end up in arguments about whether or not the two styles of coding are equivalent or not. But I agree with Dave--exceptions generally inhibit optimization. One way to think about this is that, generally speaking, the less the compiler can prove about a program, the less aggressive

On Thu, Aug 13, 2020 at 4:38 PM Haoran Xu <haoranxu510 at gmail.com> wrote: > > Hello David and Sterling, thanks for the reply! > > I have no intention to heat up the discussion, please pardon me if I asked questions that might sound silly to you -- it's just that I truly didn't understand since I'm not expert in llvm or optimizer or exception handling at all. >

Looks like pinsr is not being generated on llvm-x86_64-ubuntu... jabbey at davinci:~$ /home/jabbey/src/osuosl/buildbot/sandbox/llvm-x86_64-ubuntu/llvm-x86_64-ubuntu/llvm/Debug+Asserts/bin/llc < /home/jabbey/src/osuosl/buildbot/sandbox/llvm-x86_64-ubuntu/llvm-x86_64-ubuntu/llvm/test/CodeGen/X86/mmx-pinsrw.ll -mtriple=x86_64-linux -mattr=+mmx,+sse2 produces: .file "<stdin>"

On Wed, Jan 10, 2018 at 5:21 AM, James Y Knight <jyknight at google.com> wrote: > > On Fri, Jan 5, 2018 at 9:58 PM, Ryan Prichard via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> 2. *Termination landing pads.* >> >> Clang sometimes uses a landing pad that calls __clang_call_terminate to >> terminate the program. GCC instead leaves a gap in

On Thu, Aug 13, 2020 at 6:11 PM Haoran Xu <haoranxu510 at gmail.com> wrote: > > Thanks for the insights David! > > For your first 3 points, is it correct to understand it as following: the external function prototypes are missing reliable information on whether the function throws and what exceptions it may throw (due to C++'s design failures and that it is impractical to

This URL mentions using LLVM IR to perform code analysis. https://stackoverflow.com/questions/9939794/how-to-use-llvm-to-generate-a-call-graph But the first problem to solve is how to convert the commands used in Makefiles to the corresponding LLVM commands. https://pastebin.com/RcnA14Qa The above URL shows the makefile screen output from the bash source code. Where `gcc -c`, `gcc` (link with

On Fri, May 15, 2015 at 5:27 PM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > I like the way this sorts out with regard to funclet code generation. > It feels very natural for Windows EH, though obviously not as natural for > non-Windows targets and I think it is likely to block some optimizations > that are currently possible with those targets. > Right, it will