search for: release_390

I've got a i7 with 12 logical cores and 16GB of RAM I successfully built RELEASE_390/final but for the last 100 or so files I'd to use "ninja -j2" so as not to keep from swapping in the best case and and in the worst case the build kills itself without completing because apparently its run out of memory. For the first 3200 files or so it was doing just fine with &quo...

...clang/llvm release 3.9.0. For this I'm using the steps as explained on > 'http://apt.llvm.org/building-pkgs.php'. Up until now I have done: > > $ debcheckout svn://anonscm.debian.org/svn/pkg-llvm/llvm-toolchain/ > $ cd llvm-toolchain/branches > $ sh 3.9/debian/orig-tar.sh RELEASE_390 final > > Now, as is explained, I would have to run 'unpack.sh', however, this > script assumes the version name to be an SVN-version-based name (which > is not the case for '3.9'). So I had to modify unpack.sh for this. Now > for one of the last steps of unpack.sh, t...

...ing Debian packages for clang/llvm release 3.9.0. For this I'm using the steps as explained on 'http://apt.llvm.org/building-pkgs.php'. Up until now I have done: $ debcheckout svn://anonscm.debian.org/svn/pkg-llvm/llvm-toolchain/ $ cd llvm-toolchain/branches $ sh 3.9/debian/orig-tar.sh RELEASE_390 final Now, as is explained, I would have to run 'unpack.sh', however, this script assumes the version name to be an SVN-version-based name (which is not the case for '3.9'). So I had to modify unpack.sh for this. Now for one of the last steps of unpack.sh, there is the line: cp...

...d0: > .size foo, .Lfunc_end0-foo > .cfi_endproc > > .type b, at object # @b > .comm b,1024,16 > .type c, at object # @c > .comm c,1024,16 > .type a, at object # @a > .comm a,1024,16 > > .ident "clang version 3.9.0 (tags/RELEASE_390/final)" > .section ".note.GNU-stack","", at progbits > > in the generated code although there is use of vmov... instructions but no > zmm register? only xmm registers. > > > Can you please specify where i am wrong. i have tried it several times by >...

Hello, I'm making a compiler utilizing LLVM. Because I want the compiler to support 128bit floating-point operations, I added the code for 128bit floating-point operations and tested these operations in i686, x86_64, SPARCv8 and SPARCv9 machines. Generated codes by LLVM operated normally when using x86_64, SPARCv8 and SPARCv9 machines, but generated codes in a x86 machine produce wrong

I think it’s generally true that whenever branches can reliably be predicted branching is faster than a cmov that involves speculative execution, and I would guess that your assessment regarding looping on input values is probably correct. I believe the code that actually creates most of the transformation you’re interested in here is in SelectionDAGLegalize::ExpandNode() in LegalizeDAG.cpp. The

....9.0. For this I'm using the steps as explained on >> 'http://apt.llvm.org/building-pkgs.php'. Up until now I have done: >> >> $ debcheckout svn://anonscm.debian.org/svn/pkg-llvm/llvm-toolchain/ >> $ cd llvm-toolchain/branches >> $ sh 3.9/debian/orig-tar.sh RELEASE_390 final >> >> Now, as is explained, I would have to run 'unpack.sh', however, this >> script assumes the version name to be an SVN-version-based name (which >> is not the case for '3.9'). So I had to modify unpack.sh for this. Now >> for one of the last s...