search for: codegening

Displaying 20 results from an estimated 6906 matches for "codegening".

Did you mean: codegen'ing
2018 Jan 24
2
[PATCH] D41675: Remove alignment argument from memcpy/memmove/memset in favour of alignment attributes (Step 1)
Hello, Is there a script to update those test cases? I see mention of a sed script in the commit message but when I try it (see attached) on sed I get the following error: sed: file script line 2: invalid reference \3 on `s' command's RHS Did I lose something in a copy-paste? Is it not really a sed script? How do I run it? On Fri, Jan 19, 2018 at 9:15 AM, Daniel Neilson via
2018 Jan 24
0
[PATCH] D41675: Remove alignment argument from memcpy/memmove/memset in favour of alignment attributes (Step 1)
Hi Alexandre, The script uses extended-sed syntax, so you need to run sed with the -E option. For example, when preparing the patch I created a file ( script.sed ) containing all of the lines that I copied into the commit message. Then, I ran this bash one-liner from the test directory: for f in $(find . -name '*.ll'); do sed -E -i ‘.sedbak' -f script.sed $f; done When I was happy
2018 Jan 25
2
[PATCH] D41675: Remove alignment argument from memcpy/memmove/memset in favour of alignment attributes (Step 1)
Thanks, that worked like a charm except for the following: llvm generate: call void @llvm.memcpy.p3i8.p1i8.i64(i8 addrspace(3)* align 1 bitcast ([512 x float] addrspace(3)* @a_scratchpad to i8 addrspace(3)*), i8 addrspace(1)* align 1 %0, i64 2048, i1 false) And we expected: call void @llvm.memcpy.p3i8.p1i8.i64(i8 addrspace(3)* bitcast ([512 x float] addrspace(3)* [[SPM0]] to i8
2018 Jan 25
3
[PATCH] D41675: Remove alignment argument from memcpy/memmove/memset in favour of alignment attributes (Step 1)
Yes, all that is correct. My question is more a long term question: why do the .ll printer specify the alignment if it is equivalent to the default one? That is, it seems the sed script expect the printer to not specify it (this would match the load/store behavior), but the ll-printer does specify it, which either means the printer is not ideal on this case and I should fix it, or in this case
2018 Jan 25
0
[PATCH] D41675: Remove alignment argument from memcpy/memmove/memset in favour of alignment attributes (Step 1)
Hi Alexandre, Before the change you would have been expecting one of the following, correct? a) call void @llvm.memcpy.p3i8.p1i8.i64(i8 addrspace(3)* bitcast ([512 x float] addrspace(3)* [[SPM0]] to i8 addrspace(3)*), i8 addrspace(1)* [[APTR]], i64 2048, i32 0, i1 false) b) call void @llvm.memcpy.p3i8.p1i8.i64(i8 addrspace(3)* bitcast ([512 x float] addrspace(3)* [[SPM0]] to i8 addrspace(3)*), i8
2018 Jan 25
0
[PATCH] D41675: Remove alignment argument from memcpy/memmove/memset in favour of alignment attributes (Step 1)
Good question. AFAIK, the IR-printer doesn’t understand the semantics of parameter attributes. In this case, it only knows that there is an attribute on the parameter that is integer valued (with value 1) and that has the name “align”, so it prints it out. If we don’t want it printing out ‘align 1’ then it’s up to us to not set the alignment parameter attribute to a value if that value would be 1.
2020 Aug 10
2
Orc JIT v2 breaks OpenMP in 11.x branch?
Hi Geoff, Nothing in that backtrace leaps out at me. Based on the stack trace and description my first guess would be a clang misconfiguration rather than a JIT bug. How is that clang invocation being made? Is it from inside a callback from ORC, or is it before you add your module to the JIT? -- Lang. On Mon, Aug 3, 2020 at 5:41 AM Geoff Levner <glevner at gmail.com> wrote: > Here,
2020 Aug 03
2
Orc JIT v2 breaks OpenMP in 11.x branch?
Greetings, Lang and other JITters, Last week I moved our Orc v2-based app from top-of-tree to the new 11.x branch, and it no longer handles C++ code containing OpenMP directives correctly. More specifically, if I JIT compile a function containing OpenMP parallel/for pragmas, using a release version of LLVM, the code compiles and seems to work, but if I try to write the module's bitcode to
2020 Aug 10
2
[EXTERNAL] Re: Orc JIT v2 breaks OpenMP in 11.x branch?
Hi, That patch was from an ongoing effort to consolidate OpenMP generation in clang. If memory serves the implementation there is still a little incomplete. It's supposed to use types from OMPConstants rather than ones it defined itself and the methods used to create the functions shouldn't need to be static. However attempting this caused a lot of errors so there might be an underlying
2011 Mar 14
0
[LLVMdev] LLVM 2.9 RC1 Pre-release Tarballs
On 2011-03-09 02:51, Bill Wendling wrote: > There are LLVM 2.9 RC1 pre-release tarballs source available. You can find them here: > llvm 2.9rc1 test on Dualcore ARM running Ubuntu Natty gunzip llvm-2.9rc1.src.tar.gz tar zxvf llvm-2.9rc1.src.tar cd llvm-2.9-build ../llvm-2.9rc1/configure --enable-shared time make clean ;time make CXXFLAGS=-marm CFLAGS=-marm xranby at
2020 Aug 10
2
[EXTERNAL] Re: Orc JIT v2 breaks OpenMP in 11.x branch?
Thanks, Joseph and Johannes. I have not merged in anything, I am using the code from the repository as is. What is this -debug-only option, and to whom would I pass it? I am running our own JIT application, which uses clang to compile modules on the fly via clang::CompilerInstance::ExecuteAction(). Working on the assumption that there is a mismatch in the declared type of an OpenMP runtime
2011 Dec 13
5
[LLVMdev] make check-all failing 18 tests with --enable-optimized
As part of our automated testing, I'm running make check-all to watch for failures. One of my builds uses the --enable-optimized option to configure. When I build the latest trunk, I'm now seeing 18 failing tests: Clang :: Preprocessor/macro_paste_c_block_comment.c LLVM :: CodeGen/ARM/2011-05-04-MultipleLandingPadSuccs.ll LLVM :: CodeGen/ARM/2011-11-14-EarlyClobber.ll LLVM
2020 Aug 10
2
[EXTERNAL] Re: Orc JIT v2 breaks OpenMP in 11.x branch?
Yep, it happens three times, then crashes afterwards, since I removed the assert... arg 0: expected %struct.ident_t* got %struct.ident_t.21* value @0 = private unnamed_addr global %struct.ident_t.21 { i32 0, i32 514, i32 0, i32 0, i8* getelementptr inbounds ([23 x i8], [23 x i8]* @.str, i32 0, i32 0) }, align 8 arg 0: expected %struct.ident_t* got %struct.ident_t.21* value @1 = private
2020 Aug 10
2
[EXTERNAL] Re: Orc JIT v2 breaks OpenMP in 11.x branch?
Yeah, I remember encountering that error before when getting it to pass the libomp test suite. If you have a struct named "ident_t" somewhere the compiler will rename it because of the conflict with the runtime declaration. This should be solved by casting the usage to the function type found in the definition (i.e. bitcasting a struct.ident_t.21 to struct.ident_t) which solved the
2008 Jun 11
0
[LLVMdev] some warning from VS2005 (requested by gabor)
Hi, Some random sample of VS warning: Lot of 64 bits conversions: AsmPrinter.cpp ..\..\lib\CodeGen\AsmPrinter.cpp(277) : warning C4244: 'initializing' : conversion from 'uint64_t' to 'unsigned int', possible loss of data ..\..\lib\CodeGen\AsmPrinter.cpp(614) : warning C4244: 'argument' : conversion from 'uint64_t' to 'int', possible loss of data
2010 Feb 07
3
[LLVMdev] Help with Mac OS X 10.6.2 build
Greetings, I am having trouble getting the Kaleidoscope example to build from tutorial #3 on Mac OS X 10.6.2. I didn't have too much trouble getting llvm-2.6 and llvm-gcc-frontend to build. Thanks for the help. Here are the steps I followed: Environment variables for build export LLVMOBJDIR=/opt/llvm export TARGETOPTIONS='--with-arch=nocona --with-tune=generic' export
2013 Feb 08
2
[LLVMdev] assert when mixing static and non-static members with an external AST source
So, when performing expression evaluation, lldb trips over an assert in clang/lib/AST/RecordLayoutBuilder because ExternalFieldOffsets doesn't contain a FieldDecl that updateExternalFieldOffset expected. I found that the assert occurs when both static and non-static member variables are present. For instance, with the following, the lldb command 'expr my_test.length()' does not
2011 Mar 09
5
[LLVMdev] LLVM 2.9 RC1 Pre-release Tarballs
There are LLVM 2.9 RC1 pre-release tarballs source available. You can find them here: http://llvm.org/pre-releases/2.9/ Please download them, build them, and compile things to your heart's content. And most importantly file a bunch of bug reports. :-) Share and enjoy! -bw
2011 Dec 15
2
[LLVMdev] llvm/clang test failures on powerpc-darwin8
Hi, I've bootstrapped llvm/clang from svn-trunk on powerpc-darwin8 (g++-4.0.1), and have the following test results to share. Summary below, full log at: http://www.csl.cornell.edu/~fang/sw/llvm/r146586-powerpc-darwin8-results.txt The only edits required were those I posted to llvm-commits yesterday (re: "some missing clang libs"). And I also edited LitConfig.py to point to
2013 Feb 15
0
[LLVMdev] assert when mixing static and non-static members with an external AST source
FYI, this turned out to be an error of omission in LLDB in SymbolFileDWARF, because the case of a non-defining external (i.e. a static member variable) wasn't being handled with a variable lookup to dig up the location. I'll put a patch together for lldb-commits, - Ashok From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Thirumurthi, Ashok