similar to: [LLVMdev] readnone

Nick Lewycky wrote: > I was sure that I remember "opt -functionattrs" being taught to do this, > but I just tried it out and it doesn't. This is a missed optz'n > opportunity, testcase: > > @x = constant i32 0 > define void @foo() { > load i32* @x > ret void > } > > is only marked readonly when it should be readnone. Could

Thanks for the answer Nick. Now you got me on a chase through FunctionAttrs.cpp trying to find out what analysis passes "... which answers no to everything", means. :-) Garrison On Sep 10, 2011, at 13:52, Nick Lewycky wrote: > Nick Lewycky wrote: >> I was sure that I remember "opt -functionattrs" being taught to do this, >> but I just tried it out and it

Garrison Venn wrote: > If a function accesses a global constant array of constants--in my case > a constant array of function pointers, and does NOT reference this > array via a function argument (it instead directly references this global), > is this enough to disallow the application of the readnone attribute to the > function in question? A function is readnone if it doesn't

I've worked around this issue in my test case by simply calling my personality function on program to ensure it's JIT'ed before any unwind happens. -- James 2010/1/22 Garrison Venn <gvenn.cfe.dev at gmail.com> > No, there is no magic. :-) > > To me though, the tools are magic, because I have no clue what they are > doing without looking at them and using them. >

I think so. It also fails the same way on LLVM trunk from last week. The full backtrace is below. It appears that frame #3 is a compilation of __l_personality() and frame #14 is a compilation of f(). The compilation of __l_personality appears to have been triggered by the need to output DWARF information for f(). -- James #0 0x00007ffff6ed84b5 in *__GI_raise (sig=<value optimised out>) at

On Sun, Jan 10, 2010 at 12:38 PM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > Won't passing llvm::Function* around vs strings (function names), also work, at code generation time, > without the need for a module A dec to module B impl. mapping? > > Garrison Nope. You cannot place a call instruction into one module whose callee is a Function from another module. You

Interesting. Was this the reason you were getting the recursive compilation error in JIT::runJITOnFunctionUnlocked(...) (isAlreadyCodeGenerating)? Do you have the time to try your test with 2.7? Garrison On Jan 22, 2010, at 17:37, James Williams wrote: > I've worked around this issue in my test case by simply calling my personality function on program to ensure it's JIT'ed

Hi James, Just wanted to update you. As you implied the problem here is that the personality function has to be jitted before the code that contains the corresponding llvm.eh.selector intrinsic instruction is jitted. I verified this by creating a generated version of the personality function which unless I jitted first, gave me the same error when running the code. Since you are using tools

No problem I'll drop this from our discussion as it really is only germane to my learning path and imagination. :-) I do at this time still have this concern of allowing a user (developer) the right to turn this "cross module linkage" off, but I'm still in the process of understanding your previous comments on this. Thanks again for the help and time by the way. Garrison PS:

On Sat, Jul 23, 2011 at 2:36 AM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > Hi Bill, > > Thanks for working on this. > > Is there a reference for the function attribute uwtable, or is it to be defined as > part of this effort? It already exists; there's some limited documentation in the LLVM source, but Rafael apparently forgot to add it to LangRef... -Eli

Hi Eli So I found this in Attributes.h: const Attributes UWTable = 1<<30; ///< Function must be in a unwind ///table What does this mean? In particular what does it mean not to add this as a function attribute to a function? I'm obviously going down the wrong road in my interpretation, as I

[sidenote: Please try to avoid extraneous whitespace and line wrapping changes in your patches. It makes it harder to see what you're actually changing] On Fri, Feb 26, 2010 at 4:57 AM, Garrison Venn <gvenn.cfe.dev at gmail.com>wrote: > Hi Olivier, > > On Feb 25, 2010, at 14:10, Olivier Meurant wrote: > > Hi Garrison, > > I finally come back from holidays and take

Hi, I'm investigating a bug which I have so far been able to narrow down to the following small testcase: ======== test.c =========== int *get_pntr(int *p) { return p; } __attribute__((noinline)) void store(int *p) { int *p2 = get_pntr(p); *p2 = 10; } int test() { int i; store(&i); return i; } ----------------------------- If this is compiled in two steps as

Hi Jeffrey, On Feb 26, 2010, at 16:02, Jeffrey Yasskin wrote: > [sidenote: Please try to avoid extraneous whitespace and line wrapping changes in your patches. It makes it harder to see what you're actually changing] Sorry just saw some preexisting code was not in 80 columns. > > On Fri, Feb 26, 2010 at 4:57 AM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > Hi

No, there is no magic. :-) To me though, the tools are magic, because I have no clue what they are doing without looking at them and using them. As their function is not germane to my current endeavors, I hope to learn about them from this list, and most likely from your postings. I know it is a common approach, but to me I think bitcode generation to JIT runtime is a a cool feature of LLVM.

2010/1/11 Garrison Venn <gvenn.cfe.dev at gmail.com> > I have not tried this, but a linkage type of PrivateLinkage would not add > to the symbol table according > to the doc. > > LLVMSetLinkage(g, LLVMPrivateLinkage); > Thanks - I hadn't thought of that. > > Garrison > > On Jan 11, 2010, at 14:03, James Williams wrote: > > 2010/1/11 Eli Friedman

Sorry to keep this thread alive, but I'm learning so ... There is more. The doc for GlobalValue::LinkageTypes or the C API LLVMLinkage is not as clear as the lang ref manual. See: http://llvm.org/docs/LangRef.html#linkage. I'm pointing this out because something like LinkerPrivateLinkage (LLVMLinkerPrivateLinkage), or another one, might be more appropriate to your throw away use case (if

LLVM today does not clearly specify if a function specified to not write to memory (i.e. readonly or readnone) is allowed to throw exceptions. LangRef is ambiguous on this issue. The normative statement is "[readnone/readonly functions] cannot unwind exceptions by calling the C++ exception throwing methods" which does not decide an answer for non C++ languages. It used to say (h/t

If the powers at be want this, I could easily transform the source to the LLVM coding standards, and add the necessary portable UNIX support--someone else would have to add non-UNIX support although the System library probably helps with this. However I'm guessing the LLVM release flux of the exception system, along with a lack of universal platform, dwarf JIT support might be a hinderance in

Several people on this list have reported issues with the linker regarding a named StructType instance with the same name in two different modules being resolved into two StructTypes with different names due to StructType:: setName(…) collision behavior. Looking at BitcodeReader::ParseTypeTableBody(…), I don't see use of LLVMContextImpl::NamedStructTypes or of Module::getTypeByName(…). Nor do