similar to: [LLVMdev] Privatize global variables

Hi John, > The -internalize pass changes globals to have internal linkage. Does this > not suffice for your needs? To my understanding, it does not. The -internalize pass performs: I->setLinkage(GlobalValue::InternalLinkage); which means it only changes the linkage mode, while global variables remain in place. And we need to *replace* globals with local variables in main and

On 4/7/12 7:28 PM, Dmitry N. Mikushin wrote: > Dear LLVM, > > To workaround the GPU modules visibility rules, we need to lower > global variables into scope-variables of main entry and arguments in > other functions. For example, The -internalize pass changes globals to have internal linkage. Does this not suffice for your needs? -- John T. > > int foo = 0; > > int

Hi, Is it possible to make up a ConstantArray containing a "const char*" string and pass it directly to the function "char*" argument *without* creating a GlobalVaribable? I looked around and found the usual implementation is array->globalVar->gep. If we omit globalVar & gep, then the argument type would be [ i8 x N ], where N is set to the exact string length, and

Dear LLVM NVPTX maintainers, Just to have the issue recorded, I don't know how important it is: clang generates linkonce_odr out of __inline__, and NVPTX generates .weak out of linkonce_odr (how it happens - a big question, btw, because I can't find anything related in NVPTX asm printer - does it chain to some other printer?), and finally ptxas (both 4.2 and 5) fails to compile it to

I think our test case demonstrates that requiring the array item being initialized to be constant is incorrect. NVPTX does not crash anymore and produces correct result with the following change: --- NVPTXAsmPrinter.cpp 2012-09-03 15:14:00.000000000 +0200 +++ NVPTXAsmPrinter.cpp 2012-09-04 15:47:17.859398193 +0200 @@ -1890,17 +1890,15 @@ case Type::ArrayTyID: case Type::VectorTyID: case

What memory would the pointer argument point to? ― Gordon On Nov 20, 2011, at 16:58, "Dmitry N. Mikushin" <maemarcus at gmail.com> wrote: > Hi, > > Is it possible to make up a ConstantArray containing a "const char*" > string and pass it directly to the function "char*" argument *without* > creating a GlobalVaribable? > I looked around and

Dear all, I've also noticed C backend was removed a little bit... silently. In the end of March I only got open bugs closed by Benjamin Kramer in bugzilla, but they sounded like "decision is made". So the question is: it such silent removal a normal practice? In times of 3.0 release there were long discussions on what to drop and what to preserve, e.g. sparc backend, if I remember

Dear LLVM, Might be a easy question for someone, but not for me now. Consider there is a TargetMachine instance. Having this target, how could you get a corresponding Mangler class instance? Mangler depends on MCContext, which is connected with LLVMTargetMachine inherited from TargetMachine. However, LLVMTargetMachine is only available for targets machines implementations, and not available

Dear all, Looks like the NVPTX backend cannot handle array-of-arrays contant (please see the reporocase below). Is it supposed to work? Any ideas how to get it working? Important for our target applications. Thanks, - Dima. $ cat test.ll ; ModuleID = '__kernelgen_main_module' target datalayout =

On 09/04/2012 09:57 AM, Dmitry N. Mikushin wrote: > I think our test case demonstrates that requiring the array item being > initialized to be constant is incorrect. NVPTX does not crash anymore > and produces correct result with the following change: > > --- NVPTXAsmPrinter.cpp 2012-09-03 15:14:00.000000000 +0200 > +++ NVPTXAsmPrinter.cpp 2012-09-04 15:47:17.859398193 +0200 >

On Tue, Jun 12, 2012 at 6:11 PM, Dmitry N. Mikushin <maemarcus at gmail.com>wrote: > Dear LLVM NVPTX maintainers, > > Just to have the issue recorded, I don't know how important it is: > > clang generates linkonce_odr out of __inline__, and NVPTX generates .weak > out of linkonce_odr (how it happens - a big question, btw, because I can't > find anything related

OK, thanks. For our project I implemented a similar workaround: extend each i1 memory item to i8 and load/store i1 to i8 with a type cast. Still, the issue in NVPTX remains. I don't know whether NVIDIA or community fellows have any reasonable priority to fix it (or at least put an NYI assertion!). It seems to be quite more complex, than implementing custom lowering handler, that's why

> Welcome, and this is a frequent newbie question: [...] If not already there, could you find an appropriate place to put this in the documentation? --Sean Silva On Thu, Jul 5, 2012 at 2:29 PM, Dmitry N. Mikushin <maemarcus at gmail.com> wrote: > Hi John, > > Welcome, and this is a frequent newbie question: in LLVM names are > more for human readability of the code, they

NVCC successfully handles the same IR, if we try to process the same .cu file with clang+nvptx and nvcc: CLANG/NVPTX: ============= $ cat dayofweek.cu __attribute__((device)) char yweek[7][4] = { "MON", "TUE", "WED", "THU", "FRI", "SAT", "SUN" }; $ clang -cc1 -emit-llvm -fcuda-is-device dayofweek.cu -o dayofweek.ll $ cat

Dear LLVM, The TargetData pass needs target data layout to be specified in constructor, and therefore its normal ctor is defined, but always gives a fatal error. Still, is there any way to make it loadable into the opt tool? I need this to make use of bugpoint in reducing backend test case. Thanks, - Dima.

Dear Jim and Owen, Thanks for replies, I only kindly suggest some discussion on the maillist in such cases. Just in general, nasty precedents sometimes happen, for example on IRC I've recently seen some commits to Objective C were requested to be reverted, because they were commited without any discussion. Here things are certainly not that hard, but the point is the same: it is always nice

Hi Dmitry, Where were you expecting notice to have been given? If I recall correctly, the obsolescence of the C backend was mentioned many times on this mailing list, and as Owen notes, in the release notes since 2.8. I'm not trying to be snarky. You were obviously genuinely surprised by its removal, and that makes me wonder if where the core open source devs are expecting people to look for

Hi John, Welcome, and this is a frequent newbie question: in LLVM names are more for human readability of the code, they are not really used as references internally. Instead engine operates instructions, which could be "used by" or "user of" other instructions (see use_iterator of Value.h). Also the Function class has an iterator of BasicBlocks, and each BasicBlock has an

Dear NVPTX community, PTXAS fails to compile the ptx code generated by NVPTX. Is it an issue of backend or an issue of PTXAS or a known reasonable restriction? Thanks, - Dima. > cat test.ll ; ModuleID = '__kernelgen_main_module' target datalayout = "e-p:64:64-i64:64:64-f64:64:64-n1:8:16:32:64" target triple = "ptx64-unknown-unknown" %struct.__st_parameter_dt.0.4

Dear LLVM, I'm trying to understand why the attached IR code works for x86_64 target and fails for nvptx64, because of unimplemented expand during the target lowering. Any ideas? Just change the target triple to x86_64-unknown-unknown, and the same IR code could we successfully codegen-ed for x86_64. Thanks, - Dima. dmikushin at dmikushin-desktop:~/Desktop$ gdb ~/sandbox/bin/llc GNU gdb