search for: uwtables

On 20 March 2014 02:09, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > I think this is just 2. It uses .eh_frame for unwinding proper. The > only difference in .eh_frame is that there is a personality function > defined. If there is no debug information, it should still be possible to unwind the stack via the saved LR on the stack, no? If there is only line info, you

...sly with DwarfCFIException until very recently. There has to be a way to disable unwind tables, so either the "no attribute" behaviour above is wrong or we need a new attribute "noehtable". There has to be a way to emit CantUnwind, so if the behaviour above is right, the "uwtables" attribute is only related to forced unwind (debug, profiler), not exception handling. There has to be a way to map "throw()" into IR, and "nounwind" seems to be the one to use. The fact that CantUnwind is only emitted without "uwtable" reinforces the idea that &...

> I disagree on this. Table emission by itself doesn't involve code > generation and I don't think it makes sense as a per function attribute > either. You either want it for all functions or only when needed (e.g. > exceptions are possible). As such, it makes perfect sense to me as a > global flag. It has to be an attribute because of LTO. You can LTO a file compiled with

Hi, in r176827 the optimization that turns invokes with empty landing pads into plain calls was disabled for invocations of function with the "uwtable" attribute. But given this code: struct S { ~S() {}; }; void blackbox(); __attribute__((__noinline__)) void inner() { blackbox(); } int foo() { S s; inner(); return 0; } int bar() {

Hi all, I feel that there are two problems with the existing infrastructure: * The nounwind attribute is ambiguous for (1) not throwing exceptions and (2) not performing stack unwinding. I feel that it will be better to separate this in two different attributes * There is some problem when the function has both uwtable and nounwind. Although, I think it fine to keep the current definition of

...> emitted in x86_64. Strange. I see it even with simple C testcases: void bar(void); void zed(void) { bar();} produces define void @zed() #0 .... attributes #0 = { nounwind uwtable... >The rules on what to emit in beginFunction() are a > bit convoluted, and I guess that's because uwtables' semantics is not > definite. I was hoping for something a bit stronger, because we do > lose a lot of information in the back-end, such as what exception > style is has (depending on the target, language, flags). > > Is there any definitive explanation on the complete semantics...

...;ll have to figure out what to do based on its impressions on what language is being used to produce similar results. I believe that emitting the tables on anything that could potentially interact with exceptional code makes sense, but that's clearly a front-end decision. To LLVM, nounwind and uwtables should be absolute: IF (uwtables) IF (nownwind) CantUnwind ELSE Unwind Table ELSE do nothing ENDIF 2. .fnstart/.fnend+friends Another problem is that the emission of unwinding tables (based on .fnstart/.fnend symbols and others) is conditional *only* to the existence (or not) of a...

Dear All, I am trying to understand the process followed for converting GIMPLE IR to LLVM IR in LLVM-GCC/DragonEgg - more importantly conversion of OpenMP extended GIMPLE IR to LLVM IR. It would be great if anybody points me to some documentation before I my-self delve into the understanding of related source code. -- Cheers -mahesha -------------- next part -------------- An HTML attachment

> On 2015-May-15, at 13:15, Teresa Johnson <tejohnson at google.com> wrote: > > What isn't clear to me is what all uses the available > externally linkage type currently - do you happen to know? It's used for the `inline` keyword in the C language. If you do a `git grep available_externally -- test/` inside a clang checkout you might find some other uses. $ cat

While comparing debug info between GCC and Clang I found a section that only Clang produces and GCC never produces: debug_frame. It seems (though I haven't verified this with absolute certainty) as though GCC just always uses eh_frame. LLVM on the other hand sometimes uses eh_frame and sometimes uses debug_frame. Here's an example: int f1(); int i = f1(); void func() { } Compiled with

Hello Duncan Sands, >From your reply, what I can understand is that there is no any new OPENMP specific instructions introduced into LLVM IR as a part of DragonEgg project since GCC has already done the job of lowering OpenMP directives into GOMP runtime library calls at LOW GIMPLE IR level. Now, it throws up following questions. 1. Am I correct that DragoEgg should logically supports

...+ code and which itself calls C++ code and you wish the C++ exception to propagate through the C code. > I believe that emitting the tables on anything that could potentially interact > with exceptional code makes sense, but that's clearly a front-end decision. > To LLVM, nounwind and uwtables should be absolute: > IF (uwtables) > IF (nownwind) > CantUnwind > ELSE > Unwind Table > ELSE > do nothing > ENDIF This certainly appears to me a sensible sequence of decision. > 2. .fnstart/.fnend+friends > > Another problem is that the emission of unw...

Folks, I'm sorry for getting at this again, but this will not be the last discussion on the topic, so let's just get to business. We're about to merge the last critical patch to make EHABI compatible with other EH mechanisms in LLVM (D3079), and that has unearthed a few issues with the function attributes. Logan's blog post [1] contains a proposal to split unwinding from

I'd love to hear more details. Are you saying that this infinite loop is a limitation of EHABI table format, and not something that can be fixed in the compiler? Meanwhile, please notice that gcc behavior matches current clang behavior that I described above. We would not want to create an incompatibility. On Fri, Feb 14, 2014 at 8:42 PM, Logan Chien <tzuhsiang.chien at gmail.com>

Hi LLVM developers, $ cat hello.c #include <stdio.h> void foo() { } int main(int argc, char *argv[]) {   for (int i = 0; i < 10; i++) {     printf("%d\n", i);   }   return 0; } $ /opt/llvm-svn/bin/clang --version Fedora clang version 6.0.0 (trunk 316308) (based on LLVM 6.0.0svn) Target: x86_64-redhat-linux Thread model: posix InstalledDir: /opt/llvm-svn/bin $

Hi all, I'm trying to obtain a .ll with parameters name for every function. My simple c C is the following: int sum(int a, int b) { return a+b; } int main() { sum(1,2); } I obtain the .ll with the following commands: clang -emit-llvm sum.c -c llvm-dis-7 sum.bc The obtained .ll is: cat sum.ll ; ModuleID = 'sum.bc' source_filename = "sum.c" target datalayout =

To reproduce the issue, please use the command line "opt -simplifycfg filename". target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-unknown-linux-gnu" %struct.G = type { %struct.ordered_index_node*, i32 } %struct.ordered_index_node = type { %struct.B, %struct.F } %struct.B = type { i32 } %struct.F = type { i32*, i32* }

On Thu, Mar 20, 2014 at 10:41 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > On 19 March 2014 17:31, David Blaikie <dblaikie at gmail.com> wrote: >> While comparing debug info between GCC and Clang I found a section >> that only Clang produces and GCC never produces: debug_frame. >> >> It seems (though I haven't verified this with absolute

Hi Hal, Thanks for your hint! $ /opt/llvm-svn/bin/opt -S -internalize -internalize-public-api-list=main -globaldce hello3.ll -o hello3.dce.ll    it works :) But I argue that `main` Function should be inserted into ExternalNames by default: Index: lib/Transforms/IPO/Internalize.cpp =================================================================== --- lib/Transforms/IPO/Internalize.cpp 

Hello Everyone, This is my first attempt to getting used with the submission process. Trying to get the "good practice" with the coding standard, tools, mailing lists... and already a few questions: - Is it possible to "link" 2 related entries in Phabricator ? one for LLVM and one for CFE ? what's the best way of posting 2 related or dependent patches ? - I'd