similar to: [LLVMdev] Changes in LLVM 3.4 llc name mangling?

On Mon, Feb 3, 2014 at 11:55 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > This is a bug. The asm printer should be adding escapes so that you > would get a symbol named "$(foo)". What is the target triple? x86_64-unknown-linux-gnu I've attached a simple test case: source test.ll file and the .s output files produced with llc from LLVM 3.3 and 3.4,

Albert Graef wrote: > One thing I noticed is that writing LLVM assembler code (print() > methods) seems to be horribly slow now (some 4-5 times slower than in > LLVM 2.5). This is a real bummer for me, since Pure's batch compiler > uses those methods to produce output code which then gets fed into llvmc. Let me follow up with some concrete figures. Unfortunately, I don't have

Jeffrey Yasskin wrote: > See Owen's email about docs for the 2.6 release, but it's really not > that hard to keep up with trunk. I recently merged trunk LLVM into > Unladen Swallow, and the changes I needed to make are at > http://code.google.com/p/unladen-swallow/source/detail?r=724. Thanks Jeffrey, that was really very helpful! I have Pure working with both the LLVM 2.6

On 11/26/2012 10:35 PM, Kaylor, Andrew wrote: > So when you say 'lazy compilation' you mean 'deferred compilation of individual functions within a module until that function is needed,' right? That's certainly what 'lazy compilation' meant in the legacy JIT. Yes. Let's not forget what JIT actually means; this *is* what makes a compiler a JIT compiler. In Pure

I think so. There have been other reports lately related to this being wrong. http://llvm.org/bugs/show_bug.cgi?id=14410 CC'ing Timur since he might know more about this. On Wed, Feb 20, 2013 at 5:27 PM, David Nadlinger <code at klickverbot.at>wrote: > On Tue, Feb 19, 2013 at 2:13 PM, Duncan Sands <baldrick at free.fr> wrote: > >> My question: Is there an easy way

2013/2/21 Anton Korobeynikov <anton at korobeynikov.info>: > The patch looks incorrect. The code just needs to handle \1 properly > and clang extended to add explicit \1 to the names which does not > require mangling. I think clang already adds \01 to __stdcall names, so only the LLVM change is remaining. > I do not think that moving whole mangling to clang is a good idea, >

On Tue, Feb 19, 2013 at 2:13 PM, Duncan Sands <baldrick at free.fr> wrote: >> My question: Is there an easy way of disabling the name-mangling part >> but keep the rest of the CC that I missed? > if you use "\1" + "usual name", it will disable name mangling if you are > lucky. A leading \1 is LLVM's way of saying: leave this name alone! Seems like

The patch looks incorrect. The code just needs to handle \1 properly and clang extended to add explicit \1 to the names which does not require mangling. I do not think that moving whole mangling to clang is a good idea, because then everyone who uses LLVM to call WinApi functions will need to mangle by hands. On Wed, Feb 20, 2013 at 11:25 PM, Timur Iskhodzhanov <timurrrr at google.com>

Anton, what do you think of David's patch with this test case? OK to commit that? On Wed, Feb 20, 2013 at 12:43 PM, Anton Korobeynikov < anton at korobeynikov.info> wrote: > The patch looks incorrect. The code just needs to handle \1 properly > and clang extended to add explicit \1 to the names which does not > require mangling. > > I do not think that moving whole

I don't remember anything other that what I've written in the bug João has mentioned. Probably something like this patch http://llvm.org/bugs/show_bug.cgi?id=14410#c6 ? 2013/2/20 João Matos <ripzonetriton at gmail.com>: > I think so. There have been other reports lately related to this being > wrong. > > http://llvm.org/bugs/show_bug.cgi?id=14410 > > CC'ing

Hi all, I run samba 3.6.6 from debian wheezy (version 3.6.6) and i am experiencing some troubles with file name mangling. If i try "dir /x" on a mapped folder it gives me unexpected mangled names: the name mangling matches only the first character and not the first 5 as i expect. For example: if the long file name is LONGFILENAME.TXT, i expect the mangled sholud be something like

Hi all, I'm currently working on getting our (LDC) compiler to run on Win32/MinGW, now that DW2-style EH is available for it. The D programming language has a feature equivalent to LLVM module level inline assembly, so we need to at least partly follow the x86 D calling convention (http://dlang.org/abi.html). Most notably, the ABI mandates that the callee cleans the stack. On the various

> The Clang mangler, however, does what you want. But, you'll need to > feed it a clang AST in order to get a name out. Depending on the > parameters of your function, this may be easy or hard. By the way, does anyone know of a project which *does* call into Clang's mangling framework from outside? I'd be interested to know purely out of curiosity. Cheers. Tim.

The Identifiers section in the LLVM language manual states: "The "\01" prefix can be used on global variables to suppress mangling." Is this for global variables only, or global values in general, such as functions also? In implementation LLVM seems to have this behavior of suppressing mangling even for functions and aliases. Thanks, Gautam

Hi all ! I'm new on this mailing list... We have just installed samba v1.9.18p4. But we have problems with mangling of file names. We would like to preserve the case of windows files > 8 char. when copying files to the server. However, we want to keep 8.3 format files in lower case. The question is : how to configure all the

I've installed Samba 3.0.7 (stock Debian package), but I'm having some wierd problems with name mangling. The relevant lines in smb.conf are: preserve case = yes short preserve case = yes mangled names = yes mangle prefix = 5 mangling method = hash2 In a share, I did "touch test-file.GHO" to create a long filename. When I do a "dir" under DOS,

Hi, Nikita pointed me to an issue in the full restrict patches, related to name mangling used for llvm-ir functions (See [0, 3]). The problem is the following: Given: %0 = type { i32 } %1 = type { i32 } Creating an intrinsic @llvm.FOO that accepts 'a pointer to %0' cannot be distinguished from the intrinsic accepting 'a pointer to %1': ;For a %0* ptr0, %1* ptr1

Hi, I’d like to make sure my understanding of the name mangling in the ORC examples is correct. In the ORC lazy examples, each function gets IR’ed into its own separate LLVM module, and each module is compiled separately. So, in the name resolver, all functions need to be resolved by their mangled name, as they are linked with external linkage. I’m still not clear on what exactly performs the

Hi All, In this thread we would like to review the built-ins and name mangling approach which we chose for SPIR. Specifically, I think a discussion on the atomics and memcpy should be interesting. *****OpenCL Built-ins Introduction****** OpenCL provides a huge set of utility functions (>6000 built-ins) which are available for the developers of OpenCL. These functions are called built-ins.

Hi, I just tried changing a samba 3.0.9 server's config from mangling method = hash2 to mangling method = hash and on a WinXP client I see a filename ".foo" change to it's mangled form "FOO~00.___". Is this a bug? -- Steve Bennett, Systems Support, Lancaster University