search for: cgcall

...--------------------------------- > > Then LLVM compiles 'func' to have 2 calls to g, and g is no longer > marked as 'readonly' See http://goo.gl/YW0n3V > > You mean clang does. > Because it is clang that is turning off the attributes, deliberately > (CGCall.cpp) > > > So it doesn't seem possible to me to mark an SRET function as > readonly. > To me this seems like a problem. > > > > I agree with this one that we should be able to CSE sret'd functions. > > > One way to fix this could be to cha...

Hi all, I have identified what seems to be a limitation of LLVM with regard to marking 'sret functions' as pure/readonly. For some context - I have some JITed code produced by LLVM, and that code calls back into the host application occasionally. Since my language is purely functional, no functions have side-effects. Therefore I would like to be able to cache the value of identical

...of fast-math flags, although the vectorizer seems to ignore these intrinsics. Beyond this specific case, it would be nice to be sure when is it ever necessary to set these function attributes, e.g. https://github.com/llvm/llvm-project/blob/8205a814a691bfa62fed911b58b0a306ab5efe31/clang/lib/CodeGen/CGCall.cpp#L1743-L1750 What would be a way to control the vectorization for `min` without having to rely on that function attribute? And furthermore, could LLVM optimizations conceivably depend only on instruction flags, and not ever on function attributes? What would be necessary to achieve this? Thank...

...rget object. 5. Fix ARMAsmPrinter::emitAttributes to compute the value of TargetOptions::UnsafeFPMath based on the function attributes of all the functions in the module being compiled (see the link below). http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-December/079904.html 6. Move the code in CGCall.cpp that sets the function attributes to BackendUtil.cpp. clang should set the function attributes regardless of whether it is compiling from source code or from an IR file (e.g., clang foo1.ll -o foo1.s -ffast-math), but currently this happens only if it’s compiling from source. Any comments and...

...the vectorizer > seems to ignore these intrinsics. > > Beyond this specific case, it would be nice to be sure when is it ever > necessary to set these function attributes, e.g. > > https://github.com/llvm/llvm-project/blob/8205a814a691bfa62fed911b58b0a306ab5efe31/clang/lib/CodeGen/CGCall.cpp#L1743-L1750 > > What would be a way to control the vectorization for `min` without having > to rely on that function attribute? And furthermore, could LLVM > optimizations conceivably depend only on instruction flags, and not ever on > function attributes? What would be necessary...

...e intrinsics. >>> >>> Beyond this specific case, it would be nice to be sure when is it ever >>> necessary to set these function attributes, e.g. >>> >>> https://github.com/llvm/llvm-project/blob/8205a814a691bfa62fed911b58b0a306ab5efe31/clang/lib/CodeGen/CGCall.cpp#L1743-L1750 >>> >>> What would be a way to control the vectorization for `min` without >>> having to rely on that function attribute? And furthermore, could LLVM >>> optimizations conceivably depend only on instruction flags, and not ever on >>> func...

Hi Chris, Thanks for the reply. Right now, I disabled the doesNotReturn() check in the code for emitting calls in clang (CGCall) and also disabled running simplifycfg/prune-eh passes that introduce UnreachableInst after exit(). The main issue is that the particular transform pass that I am using in our backend does not yet support multiple loop exits and common case where this issue arises is when there are exit() calls in...

> I really dislike that all the files and classes in the MC library > start with MC. This is c++, not c :( Same here. > > - Michael Spencer Cheers, Rafael

I have some needs in the Mips compiler to have some special calling conventions; for now just used internally by the compiler. In the ir there is the general "cc <n>". Is there a way to register a calling convention with target independent code so that if those attribute is attached to the function ir , that the corresponding calling convention will be used when generating

Hi, I think it's an awesome idea to make sure all names are logical. It is an essential feature of a good API to have logical naming :) > I really dislike that all the files and classes in the MC library > start with MC. This is c++, not c :( On a similar note, all the classes in clang/CodeGen are prefixed with CG or even CodeGen, could those be renamed as well? And speaking of the

...tin.c" > > Command 0 Result: -2147483645 > Command 0 Output: > > > Command 0 Stderr: > Assertion failed: !retAI.getIndirectAlign() && "Align unused on indirect > return. > ", file > D:\src\llvm_release_build_3.7.1-rc1\llvm\tools\clang\lib\CodeGen\CGCall. > cpp, line 1283 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151117/e5efc793/attachment.html>

...ke that all the files and classes in the MC library >> start with MC. This is c++, not c :( > > On a similar note, all the classes in clang/CodeGen are prefixed with > CG or even CodeGen, could those be renamed as well? Yes. For example, CodeGenFunction would become IRGenFunction. CGCall.cpp would become... probably either GenCall.cpp or IRGenCall.cpp, with my preference being the shortest that's still unambiguous throughout the project, which I think means Gen*. > And speaking of the clang codegenerator, I as a llvm newbie was > confused by the ModuleBuilder.h/.cpp. The...

...llvm::Type::getInt64Ty(getVMContext())); I was hoping this could be used to implement extension for ABI purposes, but it doesn't look like this will work (with the current infrastructure). If the type specified in the classify*Type method is larger than the actual parameter/return value type, CGCall.cpp will in fact create extend operations, but those will always be zero-extends: /// CoerceIntOrPtrToIntOrPtr - Convert a value Val to the specific Ty where both /// are either integers or pointers. This does a truncation of the value if it /// is too large or a zero extension if it is too small....

...:emitAttributes to compute the value of > TargetOptions::UnsafeFPMath based on the function attributes of all > the functions in the module being compiled (see the link below). > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-December/079904.html > > > 6. Move the code in CGCall.cpp that sets the function attributes to > BackendUtil.cpp. clang should set the function attributes regardless > of whether it is compiling from source code or from an IR file > (e.g., clang foo1.ll -o foo1.s -ffast-math), but currently this > happens only if it’s compiling from source...

...MathTag=0x0) at > /u/geoff/llvmrepo/llvm-project/llvm/include/llvm/IR/IRBuilder.h:2356 > #8 0x00007fb7117124eb in > clang::CodeGen::CodeGenFunction::EmitRuntimeCall (this=0x7fffd4fda9d0, > callee=..., args=..., > name=...) at > /u/geoff/llvmrepo/llvm-project/clang/lib/CodeGen/CGCall.cpp:4051 > #9 0x00007fb7118b601f in > clang::CodeGen::CGOpenMPRuntime::emitForStaticFinish (this=0x4614460, > CGF=..., Loc=..., > DKind=llvm::omp::OMPD_for) at > /u/geoff/llvmrepo/llvm-project/clang/lib/CodeGen/CGOpenMPRuntime.cpp:2875 > #10 0x00007fb71197c294 in > > cl...

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

So, I'm not really sure if this is the right approach. I'd like some folks from the LLVM side of things to chime in. In general, I'm not certain we want to continue growing our dependence on the signext and zeroext attributes on return types, or whether we want to do the extension in the frontend instead. Most of the targets in Clang currently eagerly zext or sext the return value to

.../u/geoff/llvmrepo/llvm-project/llvm/include/llvm/IR/IRBuilder.h:2356 >> #8 0x00007fb7117124eb in >> clang::CodeGen::CodeGenFunction::EmitRuntimeCall (this=0x7fffd4fda9d0, >> callee=..., args=..., >> name=...) at >> /u/geoff/llvmrepo/llvm-project/clang/lib/CodeGen/CGCall.cpp:4051 >> #9 0x00007fb7118b601f in >> clang::CodeGen::CGOpenMPRuntime::emitForStaticFinish (this=0x4614460, >> CGF=..., Loc=..., >> DKind=llvm::omp::OMPD_for) at >> /u/geoff/llvmrepo/llvm-project/clang/lib/CodeGen/CGOpenMPRuntime.cpp:2875 >> #10 0x00007fb7...

...hing is probably to > split each target's code out of TargetInfo.cpp; I'd suggest that the > structure of CodeGen could mirror <llvm>/lib/Target/ so we'd have > directories for ARM, PowerPC, X86 etc. What do you think? > > Note that there's also functionality in CGCall.cpp (and a few other > files) which would need to be separated out to be usable for other > frontends. > > > Write your library as a wrapper around that logic so that simple cases > can be handled without burdening other frontends with the subtleties of > Clang's AST data s...

On Tue, 30 Jun 2015 at 06:02 Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Stephen Cross" <scross at scross.co.uk> > > To: "Reid Kleckner" <rnk at google.com> > > Cc: "Clang Developers List" <cfe-dev at cs.uiuc.edu>, "LLVM Developers > Mailing List" <llvmdev at