similar to: [LLVMdev] Dragonegg-2.8 released

Hi Mingliang LIU, > I suggest add the id attribute for each <h2> tag in www/index.html. Thus we can > refer to the "Getting it" section in the dragonegg homepage page (the only web > page) by simply the given URL: > http://dragonegg.llvm.org#GettingIt this already works: http://dragonegg.llvm.org/#gettingrelease But maybe could be done better or more consistently?

Hi Duncan, Got it. So, it looks like in [case] it is really sufficient to have -O1 for GCC to remove loads (not really remove, but rather pull outside of loops, which is sufficient). And in this case - GCC -O1 does not help. Still, is the [case] sufficient for you to track the missing GCC's info and make it accessible to LLVM? Meanwhile, I think we will use GCC -O1, however, I guess, it

Hi Dmitry, On 15/01/13 22:22, Dmitry Mikushin wrote: > Hi Duncan, > > You mean - what happens if DragonEgg is invoked with GCC optimization? I tried > -O3 and -fplugin-arg-dragonegg-llvm-ir-optimize=1, but nothing changed. no, I meant if you run gcc with optimization and don't use dragonegg at all. If I understand right, your problem is that the LLVM optimizers don't remove

Hi Duncan, You mean - what happens if DragonEgg is invoked with GCC optimization? I tried -O3 and -fplugin-arg-dragonegg-llvm-ir-optimize=1, but nothing changed. - D. 2013/1/8 Duncan Sands <baldrick at free.fr> > On 04/01/13 15:58, Duncan Sands wrote: > >> PS: Another possibility is to do link-time optimization, since at that >> point the >> optimizers are capable

Hi, I suggest add the id attribute for each <h2> tag in www/index.html. Thus we can refer to the "Getting it" section in the dragonegg homepage page (the only web page) by simply the given URL: http://dragonegg.llvm.org#GettingIt Regards. On Wed, Dec 19, 2012 at 6:32 AM, Dmitry Mikushin <dmitry at kernelgen.org>wrote: > Hi Tom, > > DragonEgg depends on GCC's

Actually this kind of opportunities, as outlined bellow, was one of my contrived motivating example for fast-math. But last year we don't see such opportunities in real applications we care about. t1 = x1/y ... t2 = x2/y. I think it is better to be taken care by GVN/PRE -- blindly convert x/y => x *1/y is not necessarily beneficial. Or maybe we can blindly perform such

Hi Jack, On 30/08/13 15:56, Jack Howarth wrote: > On Thu, Aug 29, 2013 at 07:40:46PM +0200, Duncan Sands wrote: >> Hi Jack, >> >> On 29/08/13 18:35, Jack Howarth wrote: >>> Duncan, >>> Is there a long term plan for handling the conflicting c++ libraries in building >>> dragonegg? In particular, as vendors switch their clang++ system compilers

On Wed, Apr 04, 2012 at 05:00:05PM +0200, Duncan Sands wrote: > Hi Jack, > >> Duncan, any idea how to work around that for passing -bb-vectorize-req-chain-depth=3? > > it is being rejected by GCC's plugin options parser. I just implemented a hack > in dragonegg in which colons will be morphed into equals signs. So you should > now be able to pass

Hi ether, > i install mpc-0.8.2 in /home/ether/local/, and gcc-4.5 is configure with: > $HOME/sources/gcc-4.5/configure --enable-plugin --enable-lto > --prefix=$HOME/local/gcc-4.5/ --enable-languages=c,c++ > --disable-bootstrap --disable-multilib --with-mpc=$HOME/local > --with-libelf=$HOME/local because GCC headers include mpc.h, when dragonegg uses GCC headers then it needs to

On Wed, Oct 06, 2010 at 02:26:35PM +0200, Duncan Sands wrote: > Hi Jack, > > > I am finding that llvm 2.8 rc3 with dragonegg svn built against current > > gcc-4_5-branch doesn't appear to allow gfortran to use -ffast-math. Attempting > > to compile code using the dragonegg plugin under gcc 4.5.2 with that option produces the error... > > > > f951:

hi Duncan, i install mpc-0.8.2 in /home/ether/local/, and gcc-4.5 is configure with: $HOME/sources/gcc-4.5/configure --enable-plugin --enable-lto --prefix=$HOME/local/gcc-4.5/ --enable-languages=c,c++ --disable-bootstrap --disable-multilib --with-mpc=$HOME/local --with-libelf=$HOME/local On Sat, Apr 9, 2011 at 12:00 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi ether, how did you

On Thu, Aug 29, 2013 at 07:40:46PM +0200, Duncan Sands wrote: > Hi Jack, > > On 29/08/13 18:35, Jack Howarth wrote: >> Duncan, >> Is there a long term plan for handling the conflicting c++ libraries in building >> dragonegg? In particular, as vendors switch their clang++ system compilers to default >> to -stdlib=libc++, the resulting builds of llvm against

Hi Pawel, can you please pull this dragonegg patch into 3.2. I am the code owner for dragonegg. Thanks a lot, Duncan. On 28/11/12 13:44, Duncan Sands wrote: > Author: baldrick > Date: Wed Nov 28 06:44:50 2012 > New Revision: 168787 > > URL: http://llvm.org/viewvc/llvm-project?rev=168787&view=rev > Log: > Add support for GCC's vector copysign builtins, fixing

I have downloaded and compiled the latest versions of LLVM and DragonEgg from SVN, but I still seem to get this same problem. I am using 64-bit Linux OS maybe the fix was only for 32-bit OS'es? ________________________________________ From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] On Behalf Of Duncan Sands [baldrick at free.fr] Sent: Wednesday, February 16, 2011 5:14 PM

Hi Jack, > I am finding that llvm 2.8 rc3 with dragonegg svn built against current > gcc-4_5-branch doesn't appear to allow gfortran to use -ffast-math. Attempting > to compile code using the dragonegg plugin under gcc 4.5.2 with that option produces the error... > > f951: Unknown command line argument '--enable-finite-only-fp-math'. Try: 'f951 -help' >

Thanks, Duncan, makes sense! I suppose you meant something like this: Function* callee = dyn_cast<Function>( call->getCalledValue()->stripPointerCasts()); if (!callee) continue; - D. 2012/7/17 Duncan Sands <baldrick at free.fr> > Hi Dmitry, it would be neater to use stripPointerCasts. > > Ciao, Duncan.

Hi Dmitry, it would be neater to use stripPointerCasts. Ciao, Duncan. > OK, at our end the following workaround seems to be sufficient: > > // Check if function is called (needs -instcombine pass). > Function* callee = call->getCalledFunction(); > if (!callee) > { >

Hi Jan, > if I compile with dragonegg and -march=native I get this message: > 'bdver1' is not a recognized processor for this target (ignoring processor) this is coming directly from LLVM which doesn't know about bulldozer yet. > Is there any plan to support this cpu ? I don't know. Hopefully someone who knows something about this will comment. Ciao, Duncan. >

Jack, Can you please file a bug report and attach the BC files for the major loops that we miss ? Thanks, Nadav On Jun 2, 2013, at 1:27, Duncan Sands <duncan.sands at gmail.com> wrote: > Hi Jack, thanks for splitting out what the effects of LLVM's / GCC's vectorizers > is. > > On 01/06/13 21:34, Jack Howarth wrote: >> On Sat, Jun 01, 2013 at 06:45:48AM +0200,

Hi Marcus, > With GCC, it is possible to compile GIMPLE from an object file back to > assembly. With Dragonegg, it seems to be a NOP. (See below for a > comparison.) > > This appears it could be a nice way to mix the strengths of GCC and > LLVM. If it worked.. Should it? I didn't have time to work on LTO with dragonegg yet, but it's on my list of things to do. What