search for: maemarcus

...andle 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: > > "Registers...

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 problem completely l...

...andle 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<mailto: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: "Registers...

...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. > > 2011/9/13 Ashay R...

...s 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 wan...

On Fri, Jun 29, 2012 at 2:11 PM, Dmitry N. Mikushin <maemarcus at gmail.com> wrote: > Hi again, > > Kind people on #llvm helped me to utilize bugpoint to reduce the > previously submitted test case. For record, it code be done with the > following command: > > $ bugpoint -llc-safe test.ll > > The resulting IR is attached, and it i...

...er->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", "WED&q...

Hi, LLVM C backend as of revision 136600 suffers from the following issues: * Forward structs declarations block is missing (it was there previously, why was it removed?) * Anonymous container structs are not generated for array types, resulting into declarations being placed directly into functions prototypes (previously it was not happening as well) I'm not very familiar with llvm

...ere is a comment "If you don't want this behavior, don't use outs().", outs() is a static instance which always exists and creates problems, even if not used. - D. 2012/11/29 Dan Gohman <dan433584 at gmail.com> > On Wed, Nov 28, 2012 at 10:54 PM, Dmitry N. Mikushin <maemarcus at gmail.com>wrote: > >> Dear all, >> >> Consider there is a program that writes to stdout using two different >> raw_fd_ostream-s: > > > raw_fd_ostream does buffered I/O, so it's not really meant to be used like > this. > > >> #include &quo...

...priate 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: > > &quot...

...; Anyway, if this is a defect, then it's a blocker for us, and we'd much >>> appreciate a fix. >>> >>> - D. >>> >>> 2012/6/29 Eli Friedman <eli.friedman at gmail.com>: >>>> On Fri, Jun 29, 2012 at 2:11 PM, Dmitry N. Mikushin <maemarcus at gmail.com> wrote: >>>>> Hi again, >>>>> >>>>> Kind people on #llvm helped me to utilize bugpoint to reduce the >>>>> previously submitted test case. For record, it code be done with the >>>>> following command: >&gt...

...aggBuffer->addZeros(Bytes); > - else > - llvm_unreachable("Unexpected Constant type"); > break; > } > > It it OK, how do you think? What is the type of CPV that you are seeing? > > 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&quo...

...but that is different). Ciao, Duncan. > > Anyway, if this is a defect, then it's a blocker for us, and we'd much > appreciate a fix. > > - D. > > 2012/6/29 Eli Friedman <eli.friedman at gmail.com>: >> On Fri, Jun 29, 2012 at 2:11 PM, Dmitry N. Mikushin <maemarcus at gmail.com> wrote: >>> Hi again, >>> >>> Kind people on #llvm helped me to utilize bugpoint to reduce the >>> previously submitted test case. For record, it code be done with the >>> following command: >>> >>> $ bugpoint -llc-safe...

Thats correct. But using llc becomes a problem when I have archives (.a files). I could, in theory, extract its contents to a tempdir and then use llc and link but just wondering if there is a more elegant solution. Ashay On Mon, Sep 12, 2011 at 3:00 PM, Dmitry N. Mikushin <maemarcus at gmail.com>wrote: > Ashay, > > If I understand correctly, in hw.o you would have llvm bytecode, while > linker expects regular object binary. Probably first you need to emit > asm out of bytecode using llc? > > - D. > > 2011/9/12 Ashay Rane <ashay.rane at tacc.ut...

Dear all, Consider there is a program that writes to stdout using two different raw_fd_ostream-s: #include "llvm/LLVMContext.h" #include "llvm/Module.h" #include "llvm/Support/raw_ostream.h" using namespace llvm; int main() { raw_fd_ostream S(STDOUT_FILENO, false); outs() << "Hello"; S << ", world!";

...lection of test cases attached. To build everything execute make in the top directory. Files with logs show how compilation fails/succeeds, depending on patched/unpatched version of llvm. Could we setup this test suite as a regular test for C backend? Thanks, - D. 2011/8/5 Dmitry N. Mikushin <maemarcus at gmail.com>: > Hi, > > LLVM C backend as of revision 136600 suffers from the following issues: > > * Forward structs declarations block is missing (it was there > previously, why was it removed?) > * Anonymous container structs are not generated for array types, > resul...

On Fri, Aug 5, 2011 at 10:33 AM, Dmitry N. Mikushin <maemarcus at gmail.com> wrote: > Hi, > > Please see the collection of test cases attached. To build everything > execute make in the top directory. Files with logs show how > compilation fails/succeeds, depending on patched/unpatched version of > llvm. > > Could we setup this test...

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 found the usual implementation...

"Dmitry N. Mikushin" <maemarcus at gmail.com> writes: > Proposal made by Tobias is very elegant, but it seems to be addressing > the case when host and sub-architectures' code exist in the same time. I don't know why that would have to be the case. Couldn't your accelerator backend simply read in the propo...

Does not work and same error even on old r157485 build. - D. 2012/11/10 Eli Friedman <eli.friedman at gmail.com>: > On Fri, Nov 9, 2012 at 5:01 PM, Justin Holewinski > <justin.holewinski at gmail.com> wrote: >> I'm experiencing a weird issue during .ll file parsing, and I'm not sure if >> it's a bug in the .ll parser, or if I'm just not understanding