search for: cwriter

Hi, My recent refactoring of the (machine-dependent) use of <alloca.h> does not attempt to change CWriter's behavior of emitting a #include for <alloca.h>. FreeBSD does not have <alloca.h>, so this would cause trouble. We could change it to emit an #ifndef __FreeBSD__...#endif around #include <alloca.h>. I suggest this because, I'm guessing, whether or not the CWriter output...

On Mon, 2003-06-16 at 17:33, John Criswell wrote: > What would be better yet is to modify the code so that it does not use > alloca() at all. There seems to be little reason to use it aside from > convenience (but perhaps I have missed something). I think the idea is that alloca can give (probably significant) performance gains when used properly. In the cases where you need

Brian R. Gaeke wrote: > Hi, > > My recent refactoring of the (machine-dependent) use of <alloca.h> > does not attempt to change CWriter's behavior of emitting a #include > for <alloca.h>. FreeBSD does not have <alloca.h>, so this would cause > trouble. > > We could change it to emit an #ifndef __FreeBSD__...#endif around > #include <alloca.h>. I suggest this because, I'm guessing, whether...

...t; > alloca() at all. There seems to be little reason to use it aside from > > convenience (but perhaps I have missed something). > > I think the idea is that alloca can give (probably significant) > performance gains when used properly. There are two different issues here. CWriter *outputs* alloca() calls so that it can be sure to output C code that correctly corresponds to the LLVM bytecode, which may have alloca instructions in it. I think we have little choice but to continue using alloca() here. I'm going to hack in an ifndef for FreeBSD around the declaration output...

...ound gcc: /usr/lib/ccache/gcc Running the code generator to test for a crash: <cbe>*** Debugging code generator crash! Error running tool: /usr/local/bin/llc -o bugpoint-test-program.bc.cbe.c -march=c -f bugpoint-test-program.bc llc: CBackend.cpp:487: llvm::raw_ostream&<unnamed>::CWriter::printSimpleType(llvm::formatted_raw_ostream&, const llvm::Type*, bool, const std::string&): Assertion `NumBits <= 128 && "Bit widths > 128 not implemented yet"' failed. 0 llc 0x09017572 1 llc 0x090173e7 2 0x0044a400 __kernel_sigreturn +...

...the code generator to test for a crash: <cbe>*** Debugging code > generator crash! > > Error running tool: > /usr/local/bin/llc -o bugpoint-test-program.bc.cbe.c -march=c -f > bugpoint-test-program.bc > llc: CBackend.cpp:487: > llvm::raw_ostream&<unnamed>::CWriter::printSimpleType(llvm::formatted_raw_ostream&, > const llvm::Type*, bool, const std::string&): Assertion `NumBits <= 128 > && "Bit widths > 128 not implemented yet"' failed. try the -llc-safe option. It will use llc to compile code rather than gcc, and...

The LLVM asm parser doesn't support multiple alternative constraints; you need to have Clang pick one tuple in the front end. See ChooseConstraintTuple in llvm-gcc for prior art. On Jul 29, 2010, at 11:36 AMPDT, John Thompson wrote: > I'm trying to fix the handling of multiple alternate constraints in > Clang (see

I'm trying to fix the handling of multiple alternate constraints in Clang (see http://gcc.gnu.org/onlinedocs/gcc/Multi_002dAlternative.html#Multi_002dAlternative ). How should the constraints be represented in the .ll file? Clang currently will assert because the code generator sees a constraints string with the wrong number of comma-separated items. Basically, after some editing, it just

...s a plan to add calling conventions to llvm functions. See: http://nondot.org/sabre/LLVMNotes/CustomCallingConventions.txt If you are interested in tackling this it, it would be a great contribution to LLVM! > Even if llvm basically does ignore any "unsupported" attributes the > CWriter could still use a number of them without major changes. This will limit the C backend's portability. We would like to avoid using anything out of ANSI C if we can. -- Alkis

...cz/lib/Target/X86' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/scratch/scratch0/gaeke/llvm-497cz/lib/Target/X86' gmake[2]: Leaving directory `/scratch/scratch0/gaeke/llvm-497cz/lib/Target' gmake[2]: Entering directory `/scratch/scratch0/gaeke/llvm-497cz/lib/CWriter' gmake[2]: Nothing to be done for `all'. gmake[2]: Leaving directory `/scratch/scratch0/gaeke/llvm-497cz/lib/CWriter' gmake[2]: Entering directory `/scratch/scratch0/gaeke/llvm-497cz/lib/Reoptimizer' gmake[3]: Entering directory `/scratch/scratch0/gaeke/llvm-497cz/lib/Reoptimizer/Ma...

...cz/lib/Target/X86' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/scratch/scratch0/gaeke/llvm-497cz/lib/Target/X86' gmake[2]: Leaving directory `/scratch/scratch0/gaeke/llvm-497cz/lib/Target' gmake[2]: Entering directory `/scratch/scratch0/gaeke/llvm-497cz/lib/CWriter' gmake[2]: Nothing to be done for `all'. gmake[2]: Leaving directory `/scratch/scratch0/gaeke/llvm-497cz/lib/CWriter' gmake[2]: Entering directory `/scratch/scratch0/gaeke/llvm-497cz/lib/Reoptimizer' gmake[3]: Entering directory `/scratch/scratch0/gaeke/llvm-497cz/lib/Reoptimizer/Ma...

...vc7.1 >Date: Tue, 14 Sep 2004 11:13:10 +0200 > >Hi all, > >Attached to this email you can find the diffs versus current CVS that makes >all the touched files compile under Microsoft Visual C 7.1 > >The following libs are now building: >vmcore, transformutils, transform, cwriter, lli-jit, executionengine, >selectiondag, modulosched, sched, bcwriter, datastructure, ipa > >Next patch will be the conversion of some C99 dynamic array to std::vector, >if nobody complains about it... ><< diff.txt >> > >--- >Paolo Invernizzi > >On Sep 7...

...renaming changes made: 1. They are all prefixed with LLVM 2. They use upper and lower case to match the library directory they came from. In general they should be recognizable to you. For example: libtarget.a -> libLLVMTarget.a However, a few of them changed outright to make it consistent: cwriter.o -> LLVMCBackend.o profpaths.o -> LLVMProfilePaths.o Sparcv9Sched.o -> LLVMSparcV9InstrSched.o The changes have all been made to the necessary makefiles in llvm proper, but not in any of the projects. The adjustment should be pretty straight forward: capitalize first letters and prefix...

...004-12-22 at 21:42, Markus F.X.J. Oberhumer wrote: > Hello folks, > > with the small patch attached below the whole llvm toolchain (llvm & llvm-gcc) > will compile and run under AMD64 Linux in native 64-bit LP64 mode. > > This means that compilation, bytecode management and CWriter output all work > as expected. Of course there is no JIT, and the bytecode interpreter is still > very much untested - more patches may follow. > > Cheers, > Markus > > -- > Markus F.X.J. Oberhumer > oberhumer.com, http://www.oberhumer.com/ > Space-Grade Technology...

Hi, I'm reading the code in CBackend.cpp and found some wired chunk in void CWriter::printConstant(Constant *CPV) 938 if (ConstantInt *CI = dyn_cast<ConstantInt>(CPV)) { 939 const Type* Ty = CI->getType(); 940 if (Ty == Type::Int1Ty) 941 Out << (CI->getZExtValue() ? '1' : '0'); 942 else if (Ty == Type::Int32Ty) 943 Out << CI->getZExtValu...

...> types, based on their nesting properties, then emit them in nesting > order. Because all recursive types have to go through a pointer in > C, we should get a dag of types, which is easy to emit. A DAG traversal is already performed, but only for struct types. It is implemented in CWriter::printContainedStructs (lib/Target/CBackend/ CBackend.cpp:1722). The bug is in the calling function, printModuleTypes, which prints typedefs for all named types before performing the dependency- sensitive traversal. For array typedefs, this ordering is incorrect; the element type must be def...

...wrote: > with the small patch attached below the whole llvm toolchain (llvm & > llvm-gcc) will compile and run under AMD64 Linux in native 64-bit LP64 > mode. Sounds great! I'll add it to the list of supported platforms. > This means that compilation, bytecode management and CWriter output > all work as expected. Of course there is no JIT, and the bytecode > interpreter is still very much untested - more patches may follow. The bytecode interpreter is untested on many platforms -- part of the reason is that it's very, very slow to run on reasonable programs. If you...

Markus F.X.J. Oberhumer wrote: > Hello folks, > > with the small patch attached below the whole llvm toolchain (llvm & llvm-gcc) > will compile and run under AMD64 Linux in native 64-bit LP64 mode. > > This means that compilation, bytecode management and CWriter output all work > as expected. Of course there is no JIT, and the bytecode interpreter is still > very much untested - more patches may follow. I just applied your X86-64 patches to llvm-gcc. I've run them on a few programs on Linux/i386, and everything seems to work. Thanks, Markus...

On Fri, 3 Sep 2004, Paolo Invernizzi wrote: > I can confirm that both are compiled properly: Ok. > for (BasicBlock::iterator I = H->begin; isa<PHINode>(I); I++) { > PHINode *PN = cast<PHINode(I); > .... > } > > I'll make a patch for whatever solution do you prefer (this problem is > a showstopper for more than a dozen files...) I prefer this

On Mon, 15 Jan 2007, Nick Lewycky wrote: > Eric van Riet Paap wrote: >> *testme.cbe.c:106: error: array type has incomplete element type* > > The problem code boils down to: > > /* Structure forward decls */ > struct l_structtype_s; > > /* Typedefs */ > typedef struct l_structtype_s l_fixarray_array3[3]; > > which is illegal C, but perfectly valid C++,