search for: mikushin

...m> > If we're keeping the state locally now, perhaps we should store it in a > per-thread variable. I know rand() isn't thread safe to begin with, but it > seems like rand_r() can be since it should keep no external state. > > > On Sat, Dec 1, 2012 at 11:17 AM, Dmitry Mikushin <dmitry at kernelgen.org>wrote: > >> Dear all, >> >> In our LLVM-based compiler pipeline a major part of code generation is >> taken into application runtime. One side-effect of this organization is a >> need to be very careful about using code that might dive...

Correcting my patch, reg. __thread stuff I'm not very familiar with. - D. 2012/12/1 Dmitry Mikushin <dmitry at kernelgen.org> > Agreed, done. > > One thing I'm not sure about is this statement in docs: > > POSIX.1-2008 marks *rand_r*() as obsolete. > > - And... what is the replacement? > > > 2012/12/1 Justin Holewinski <justin.holewinski at gmail.com&gt...

...oes not yet handle up-casting an i1 to an appropriate type for storage. The memory space is not bit-addressable, so a direct store of an i1 does not make sense. In the short term, I would recommend that you manually zext from/to i8 and load/store those. On Sun, Jul 1, 2012 at 10:14 AM, Dmitry N. Mikushin <maemarcus at gmail.com>wrote: > Hi Duncan, > > Sorry I don't understand your point, could you please explain a little bit > more? > Why i1 should be declared illegal? Operations on byte-wide types like > char or bool are pretty legal, according to PTX spec: > > &...

...aggBuffer->addZeros(Bytes-ElementSize); } - else if (isa<ConstantAggregateZero>(CPV)) - aggBuffer->addZeros(Bytes); - else - llvm_unreachable("Unexpected Constant type"); break; } It it OK, how do you think? Thanks, - D. 2012/9/4 Dmitry N. Mikushin <maemarcus at gmail.com>: > 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&quot...

On Wed, Apr 8, 2015 at 10:12 AM, Dmitry Mikushin <dmitry at kernelgen.org> wrote: > A tool of this kind here: https://github.com/apc-llc/nvcc-llvm-ir > > 2015-04-08 19:01 GMT+02:00 Ahmed ElTantawy <ahmede at ece.ubc.ca>: > >> Hi, >> >> I wanted to ask whether there is ongoing effort (or an already >&g...

> On Aug 8, 2020, at 3:32 PM, Dmitry Mikushin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Cool, thanks! > > вс, 9 авг. 2020 г. в 00:27, Petr Hosek <phosek at chromium.org <mailto:phosek at chromium.org>>: > You can set the LLVM_PARALLEL_LINK_JOBS CMake variable to restrict the number of link jobs. I...

...h the libdevice implementation shipping with 5.5 (and as far as I know, it is). It's just not an officially supported configuration. Also, I've been meaning to address your -drvcuda issue. How would you feel about making that a part of the triple? On Wed, Jun 5, 2013 at 5:10 AM, Dmitry Mikushin <dmitry at kernelgen.org>wrote: > Dear all, > > FWIW, I've tested libdevice.compute_20.10.bc and > libdevice.compute_30.10.bc from /cuda/nvvm/libdevice shipped with CUDA 5.5 > preview. IR is compatible with LLVM 3.4 trunk that we use. Results are > correct, performance...

...MVT::i1, Custom); > > > > is the right way to go. > > > > Yuan > > > > > > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On > Behalf Of Justin Holewinski > > > Sent: Monday, July 02, 2012 9:55 AM > To: Dmitry N. Mikushin > Cc: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] [NVPTX] Backend failure in LegalizeDAG due to > unimplemented expand in target lowering > > > > Okay, few issues here: > > > > First, i1 is used in the NVPTX back-end to map to the predicate (.pred) > type. W...

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

...5 preview. IR is compatible with LLVM 3.4 trunk that we use. Results are correct, performance - almost the same as what we had before with cicc-sniffed IR, or maybe <10% better. Will test libdevice.compute_35.10.bc once we will get K20 support. Thanks for addressing this, - D. 2013/2/17 Dmitry Mikushin <dmitry at kernelgen.org> > > The issue is really that there is no standard math library for PTX. > > Well, formally, that could very well be true. Moreover, in some parts CPU > math standard is impossible to accomplish on parallel architectures, > consider, for example err...

...accuracy modes can be used to pick the proper library function in the > latter case, but I still think library function choice is better left up to > the front-end, and the accuracy attributes are a better fit to drive > optimization. > > > On Sun, Feb 17, 2013 at 9:48 AM, Dmitry Mikushin <dmitry at kernelgen.org>wrote: > >> Hi Justin, >> >> I don't understand, why, for instance, X86 backend handles pow >> automatically, and NVPTX should be a PITA requiring user to bring his own >> pow implementation. Even at a very general level, this limi...

No, I am running the LLVM pass at the compilation step. So by the time I reach the link step, the transformed bitcode has been generated. Ashay On Mon, Sep 12, 2011 at 4:12 PM, Dmitry N. Mikushin <maemarcus at gmail.com>wrote: > I see. And what's the purpose for outputting bitcode into *.o and *.a > files? Do you want to perform an LLVM pass on linking step? > > 2011/9/13 Ashay Rane <ashay.rane at tacc.utexas.edu>: > > Hmm.. I didn't explain the proble...

...8 bit. setOperationAction(ISD::LOAD, MVT::i1, Custom); setOperationAction(ISD::STORE, MVT::i1, Custom); is the right way to go. Yuan From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Justin Holewinski Sent: Monday, July 02, 2012 9:55 AM To: Dmitry N. Mikushin Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] [NVPTX] Backend failure in LegalizeDAG due to unimplemented expand in target lowering Okay, few issues here: First, i1 is used in the NVPTX back-end to map to the predicate (.pred) type. We definitely do not want to declare this type as illegal....

Unfortunately, I cannot reproduce this. Based on your bugzilla comment, it does look like a mis-compile with your system compiler. Does the same issue occur if you build LLVM as static libraries? On 08/03/2012 12:24 AM, Dmitry N. Mikushin wrote: > Dear NVPTX community, > > I've create a bug http://llvm.org/bugs/show_bug.cgi?id=13521 with > reprocase for this issue. > > Please, help us to fix it. Last 1,5 months we regularly encounter & > workaround or fix 1-2 bugs per week in NVPTX backend. This is >...

...#39; files is a bit ugly. llvm-ld handles the archive (.a) files without any manual extraction but I fear that because llvm-ld is not a full-featured linker, I might run into a wall because of incompatible options between gfortran/gcc and llvm-ld. Ashay On Mon, Sep 12, 2011 at 3:38 PM, Dmitry N. Mikushin <maemarcus at gmail.com>wrote: > Sorry, at what step do you need archive? llc emits binary, it does not > perform any linking, thus it does not need anything except the input > bytecode file. Then during linking you can link whatever archives of > binaries you want. > > 201...

...nternalLinkage); 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 arguments - in other functions. - D. 2012/4/8 John Criswell <criswell at illinois.edu>: > 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 in...

Hi Dmitry, On 15/01/13 22:22, Dmitry Mikushin wrote: > Hi Duncan, > > You mean - what happens if DragonEgg is invoked with GCC optimization? I tried > -O3 and -fplugin-arg-dragonegg-llvm-ir-optimize=1, but nothing changed. no, I meant if you run gcc with optimization and don't use dragonegg at all. If I understand right, your...

...the needs of the source > program/language. Users should be free to use any math library > implementation they choose. Intrinsics are meant for functions that > compile down to specific isa features, like fused multiply add and square > root. > On Feb 16, 2013 8:46 PM, "Dmitry Mikushin" <dmitry at kernelgen.org> wrote: > >> Dear Yuan, >> >> Sorry for delay with reply, >> >> Answers on your questions could be different, depending on the math >> library placement in the code generation pipeline. At KernelGen, we >> currently h...

...lvm-ld handles the > archive (.a) files without any manual extraction but I fear that because > llvm-ld is not a full-featured linker, I might run into a wall because of > incompatible options between gfortran/gcc and llvm-ld. > Ashay > > On Mon, Sep 12, 2011 at 3:38 PM, Dmitry N. Mikushin <maemarcus at gmail.com> > wrote: >> >> Sorry, at what step do you need archive? llc emits binary, it does not >> perform any linking, thus it does not need anything except the input >> bytecode file. Then during linking you can link whatever archives of >> bi...

...latforms have you tested this on? Is it available on Windows, Mac, BSDs? If not touching global state is important enough, perhaps we should add a (simple) random number generator to the Support library. I don't think LLVM would require anything fancy. On Sat, Dec 1, 2012 at 2:25 PM, Dmitry Mikushin <dmitry at kernelgen.org>wrote: > Correcting my patch, reg. __thread stuff I'm not very familiar with. > > - D. > > > 2012/12/1 Dmitry Mikushin <dmitry at kernelgen.org> > >> Agreed, done. >> >> One thing I'm not sure about is this stateme...