similar to: [LLVMdev] Forward references to a function

Michael, Yes, while stepping through this VS2010 `std::swap` code, `_Move` did nothing, e.g. //////////////////////////////////////////////////// void swap(_Ty& _Left, _Ty& _Right) { // exchange values stored at _Left and _Right _Ty _Tmp = _Move(_Left); _Left = _Move(_Right); _Right = _Move(_Tmp); } //////////////////////////////////////////////////// was equivalent to:

Hi, All I want to implement DSWP Which is used for parallelization of loops. For this purpose, the loop was replaced with a new basic block in main function. And new functions were created and basic blocks of Loop assigned to them.I have checked blocks and branches for Succ and Pred relation and I have not found any problems. However I get the following error: * **opt:

On Mon, Oct 4, 2010 at 9:52 PM, Bob Floyd <bobfloyd at comcast.net> wrote: > When using MS VS2010 there is an issue with std: > > > > `SuccIterator` implements a partial assignment operator: > > > > inline const _Self &operator=(const _Self &I) { > >     assert(Term == I.Term &&"Cannot assign iterators to two different >

When using MS VS2010 there is an issue with std: `SuccIterator` implements a partial assignment operator: inline const _Self &operator=(const _Self &I) { assert(Term == I.Term &&"Cannot assign iterators to two different blocks!"); idx = I.idx; return *this; } For copy construction, MS VS2010 std reserves the right, and sometimes calls, a

Hi Bob, was this issue resolved? Ciao, Duncan. > When using MS VS2010 there is an issue with std: > > `SuccIterator` implements a partial assignment operator: > > inline const _Self &operator=(const _Self &I) { > > assert(Term == I.Term &&"Cannot assign iterators to two different blocks!"); > > idx = I.idx; > > return *this; > > }

>> Also note that the documentation is unintentionally misleading. It's very confusing for http://llvm.org/docs/tutorial/LangImpl4.html to show "Last modified: $Date: 2007-10-17 11:05:13 -0700 (Wed, 17 Oct 2007) $" at the bottom, as if nothing had changed since then, when the code it displays is actually less than a week old... I guess the source code snippets are updated

A possible patch implementing this is at http://codereview.appspot.com/144074 (http://codereview.appspot.com/download/issue144074_1.diff). I do NOT think we should accept this patch: It changes a lot of APIs and makes users specify the choice in many places, while I think most users really just want one choice for their whole app. There's a good argument to be made that users may want to

On 3 févr. 2010, at 17:54, Eli Friedman wrote: > On Wed, Feb 3, 2010 at 8:34 AM, Christophe de Dinechin > <christophe at taodyne.com> wrote: >> What guarantees does LLVM try to provide regarding source code compatibility? > > None. And this is a good thing because... ? Christophe

I tried to reduce the test case in https://bugs.llvm.org/show_bug.cgi?id=42706. Here it is crashing opt: $ ~/llvm-debug/bin/opt -use-gpu-divergence-analysis -divergence stripped.ll WARNING: You're attempting to print out a bitcode file. This is inadvisable as it may cause display problems. If you REALLY want to taste LLVM bitcode first-hand, you can force output with the `-f' option.

What guarantees does LLVM try to provide regarding source code compatibility? Case in point: rev 94686 (http://llvm.org/viewvc/llvm-project?view=rev&revision=94686) breaks any code that creates a JIT. For example, we used to construct a FunctionPassManager with a ModuleProvider, it's now to be done with a Module. I cannot ship source code for my own project that is compatible with both

On Wed, Feb 3, 2010 at 8:34 AM, Christophe de Dinechin <christophe at taodyne.com> wrote: > What guarantees does LLVM try to provide regarding source code compatibility? None. > Also note that the documentation is unintentionally misleading. It's very confusing for http://llvm.org/docs/tutorial/LangImpl4.html to show "Last modified: $Date: 2007-10-17 11:05:13 -0700 (Wed, 17

On Wed, Feb 3, 2010 at 9:34 AM, Christophe de Dinechin <christophe at taodyne.com> wrote: > >>> Also note that the documentation is unintentionally misleading. It's very confusing for http://llvm.org/docs/tutorial/LangImpl4.html to show "Last modified: $Date: 2007-10-17 11:05:13 -0700 (Wed, 17 Oct 2007) $" at the bottom, as if nothing had changed since then, when

Óscar Fuentes <ofv at wanadoo.es> writes: >>> If I activate the Inliner pass: >>> >>>    Builder.Inliner = createFunctionInliningPass(Threshold); >>> >>> this is the result: >>> >>> LLVM ERROR: Program used external function 'llvm.lifetime.start' which could not be resolved! >>> >>> It happens on almost

In thinking about this we could use a Mutex::tryacquire(...) (non-recursive), around JIT::runJITOnFunctionUnlocked(...)'s while loop, and use your JITEmitter:: getLazyFunctionStub(...) suggestion in place of forceEmitFunctionStub(...). Is the lock attempt too heavy, even if it is implemented with atomics? I'll implement this when I have time. Garrison On Feb 17, 2010, at 15:42, Garrison

On Wed, Oct 28, 2009 at 9:50 AM, Chris Lattner <clattner at apple.com> wrote: > > On Oct 28, 2009, at 9:41 AM, Jeffrey Yasskin wrote: > >> In r85295, in response to the discussion at http://llvm.org/PR5184 >> (Lazy JIT ain't thread-safe), I changed the default JIT from lazy to >> non-lazy. It has since come to my attention that this may have been >> the

Hi James, > want to send us your testcase code? Then we can give it a whirl. > > > Test code is at http://giantblob.com/ehtest.tar.gz > > Thanks for the help. I apologize in advance if it turns out I'm doing > something stupid! I hope you realise that by running llvm-ld without -native you are actually executing your program from the JIT. I did a native

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

Jeffrey Yasskin wrote: > Try batch compiling with the large code model. (llc -code-model=large) > If that also causes tail calls to break, then I did something wrong in > fixing far calls in the JIT. Jeffrey, I took a closer look at this now, and all the TCO-related weirdness I see in the Pure interpreter is indeed related to your commit in r88984 ("Make X86-64 in the Large model

Hi Duncan, On 7 janv. 2011, at 01:00, Duncan Sands wrote: > LTO is for doing optimizations that are only valid when the module contains > everything that is needed to build the final executable. So adding a flag to > say "not everything is there after all" makes no sense to me. And indeed, everything is there when I call LTO. The flag is not "not everything is there

2010/1/22 Duncan Sands <baldrick at free.fr> > Hi James, > > > want to send us your testcase code? Then we can give it a whirl. >> >> >> Test code is at http://giantblob.com/ehtest.tar.gz >> >> Thanks for the help. I apologize in advance if it turns out I'm doing >> something stupid! >> > > I hope you realise that by