similar to: [LLVMdev] create function

Great, Monday works fine for me. We will discuss details once I will be in SF. Regards -- Jakub Staszak On Oct 5, 2010, at 11:56 PM, Mark Lacey wrote: > Hi Jakub, > > I live and work in SF. I might be interested in a quick beer or two in the early evening on the 11th. It's the only night I'm available from Friday through Tuesday. I work near the Financial District, so if you

On 12/12/11 10:25 AM, neda 8664 wrote: > > Thank you for your reply > > Yes, I change them, so what should I do for another loops? I don't really know what you should do since I don't know what your code does. All I know is that it's changing the function's control-flow graph. If you're not modifying the structure of the loops in the function, then you can

I am changing structure of loops, I used std::vector<> but i get same error, I can’t use FunctionPass :( On Mon, Dec 12, 2011 at 8:03 PM, John Criswell <criswell at illinois.edu>wrote: > On 12/12/11 10:25 AM, neda 8664 wrote: > > Thank you for your reply > Yes, I change them, so what should I do for another loops? > > > I don't really know what you should

Thank you for your reply Yes, I change them, so what should I do for another loops? On Mon, Dec 12, 2011 at 7:54 PM, neda 8664 <neda8664 at gmail.com> wrote: > Thank you for your reply > > Yes, I change them, so what should I do for another loops? > > On Mon, Dec 12, 2011 at 7:42 PM, John Criswell <criswell at illinois.edu>wrote: > >> On 12/12/11 9:59 AM,

LLVM has no facility for dealing with threads explicitly. If you're implementing a research tool to automatically pipeline software, LLVM could be of use because it is also a JIT with a good API. On Fri, Jan 28, 2011 at 8:35 AM, neda 8664 <neda8664 at gmail.com> wrote: > I want automatically parallelize sequential program in thread level to run > on multi-core > processors

On Fri, Aug 21, 2009 at 5:47 PM, Jakub Staszak<kuba at gcc.gnu.org> wrote: > > On Aug 21, 2009, at 10:27 PM, Eli Friedman wrote: > >> On Fri, Aug 21, 2009 at 5:05 PM, Jakub Staszak<kuba at gcc.gnu.org> wrote: >>> >>> On Aug 21, 2009, at 10:02 PM, Eli Friedman wrote: >>> >>>> On Fri, Aug 21, 2009 at 4:53 PM, Jakub Staszak<kuba at

Hello, This simple patch fixes PR9112: Index: lib/Analysis/ValueTracking.cpp =================================================================== --- lib/Analysis/ValueTracking.cpp (revision 125281) +++ lib/Analysis/ValueTracking.cpp (working copy) @@ -593,6 +593,8 @@ // Otherwise take the unions of the known bit sets of the operands, // taking conservative care to avoid

On Fri, Aug 21, 2009 at 5:05 PM, Jakub Staszak<kuba at gcc.gnu.org> wrote: > > On Aug 21, 2009, at 10:02 PM, Eli Friedman wrote: > >> On Fri, Aug 21, 2009 at 4:53 PM, Jakub Staszak<kuba at gcc.gnu.org> wrote: >>> >>> On Aug 21, 2009, at 8:46 PM, Eli Friedman wrote: >>> >>>> On Fri, Aug 21, 2009 at 3:29 PM, Jakub Staszak<kuba at

On Aug 21, 2009, at 10:27 PM, Eli Friedman wrote: > On Fri, Aug 21, 2009 at 5:05 PM, Jakub Staszak<kuba at gcc.gnu.org> > wrote: >> >> On Aug 21, 2009, at 10:02 PM, Eli Friedman wrote: >> >>> On Fri, Aug 21, 2009 at 4:53 PM, Jakub Staszak<kuba at gcc.gnu.org> >>> wrote: >>>> >>>> On Aug 21, 2009, at 8:46 PM, Eli

Hello, Fixed patch attached. Can anyone test it? Regards -- Jakub Staszak -------------- next part -------------- A non-text attachment was scrubbed... Name: pr5373.patch Type: application/octet-stream Size: 5846 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100811/8c0c364b/attachment.obj> -------------- next part -------------- On Aug 6, 2010, at

On Aug 21, 2009, at 10:02 PM, Eli Friedman wrote: > On Fri, Aug 21, 2009 at 4:53 PM, Jakub Staszak<kuba at gcc.gnu.org> > wrote: >> >> On Aug 21, 2009, at 8:46 PM, Eli Friedman wrote: >> >>> On Fri, Aug 21, 2009 at 3:29 PM, Jakub Staszak<kuba at gcc.gnu.org> >>> wrote: >>>> >>>> On Aug 21, 2009, at 7:31 PM, Eli

On Aug 21, 2009, at 8:46 PM, Eli Friedman wrote: > On Fri, Aug 21, 2009 at 3:29 PM, Jakub Staszak<kuba at gcc.gnu.org> > wrote: >> >> On Aug 21, 2009, at 7:31 PM, Eli Friedman wrote: >> >>> On Fri, Aug 21, 2009 at 2:06 PM, Jakub Staszak<kuba at gcc.gnu.org> >>> wrote: >>>> >>>> Hello, >>>>

On Fri, Aug 21, 2009 at 4:53 PM, Jakub Staszak<kuba at gcc.gnu.org> wrote: > > On Aug 21, 2009, at 8:46 PM, Eli Friedman wrote: > >> On Fri, Aug 21, 2009 at 3:29 PM, Jakub Staszak<kuba at gcc.gnu.org> wrote: >>> >>> On Aug 21, 2009, at 7:31 PM, Eli Friedman wrote: >>> >>>> On Fri, Aug 21, 2009 at 2:06 PM, Jakub Staszak<kuba at

Hello, Simply removing that "return true" causes the code to search blocks outside of loops for side effects. That's not what the code is supposed to do. Dan On Nov 27, 2009, at 3:01 AM, Jakub Staszak wrote: > Hi, > > Because of this "return true" not every block was visited and only one ExitBB was found (instead of two). Thus, loop was optimized as a trivial

Hello, Yeah, sorry, you are right. My new idea is that only one ExitBB is found because Header ("for.body") is already marked as visited. I'm pretty sure that someone had a good reason to do this that way, but I can't find it out :) Dan, can you look at this patch? Thanks -Jakub -------------- next part -------------- A non-text attachment was scrubbed... Name:

On Aug 6, 2010, at 11:47 AM, Dale Johannesen wrote: > The last bit here > > + if (LoopExitBB) { > + // It is possible that for both successors isTrivialLoopExitBlock() > + // returns different exit blocks. It means that the loop isn't trivial, > + // just quit then. > + if (LoopExitBB != LoopExitBB2) > + return false; > +

The last bit here + if (LoopExitBB) { + // It is possible that for both successors isTrivialLoopExitBlock() + // returns different exit blocks. It means that the loop isn't trivial, + // just quit then. + if (LoopExitBB != LoopExitBB2) + return false; + } else if (Val) { + // if LoopExitBB == LoopExitBB2 pick the first one (true). +

Hi, Because of this "return true" not every block was visited and only one ExitBB was found (instead of two). Thus, loop was optimized as a trivial one, which was wrong. -Jakub On Nov 24, 2009, at 2:28 PM, Dan Gohman wrote: > Hello, > > I haven't studied this in detail, but at a first look this makes the > code inconsistent with the associated comments. Why

On Aug 21, 2009, at 7:31 PM, Eli Friedman wrote: > On Fri, Aug 21, 2009 at 2:06 PM, Jakub Staszak<kuba at gcc.gnu.org> > wrote: >> Hello, >> >> This patch fixes PR4174. Two test-cases included: original one from >> bugzilla >> and a little bit complicated made be myself. > > I think you want isSafeToSpeculativelyExecute rather than >

Looks good. Pl. apply. Thanks, - Devang On Mon, Aug 24, 2009 at 2:29 PM, Jakub Staszak<kuba at gcc.gnu.org> wrote: > Hello, > > This (quite big :-)) patch fixes PR3913. > > Regards > -- > Jakub Staszak > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu >